VIBE: AI-Assisted Coding Workflow
- VIBE coding is a human–AI collaborative workflow where developers use natural language prompts to guide AI-generated code and validate changes.
- It involves iterative cycles of prompting, rapid inspection, and manual intervention to ensure code quality and contextual alignment.
- Empirical studies reveal that while AI boosts code generation throughput for novices, experienced oversight remains crucial for efficient reviews and integration.
In recent software engineering literature, VIBE usually denotes vibe coding: a human–AI development workflow in which a developer directs and supervises an AI coding agent through natural-language prompts, the agent generates code, and the human validates and adjusts the result for integration into a real project. In this usage, the term refers to human developers working with agentic tools such as GitHub Copilot, Codex, Claude Code, Cursor, and Devin, rather than to fully autonomous bots, and it is increasingly treated as a hallmark of “Software 3.0” because it shifts programming effort from direct line-by-line authoring toward orchestration, verification, and integration (Asdaque et al., 27 Feb 2026).
1. Definition, scope, and distinguishing features
Vibe coding is defined narrowly in the software-engineering work considered here. A vibe coder is a non-bot GitHub user who submits AI-based pull requests and uses AI coding agents as collaborators, not as autonomous replacements. This distinction matters because accounts whose names contain "bot" or match known agent identifiers are explicitly filtered out of empirical analyses; the phenomenon under study is therefore human–AI collaboration, not bot-generated software maintenance (Asdaque et al., 27 Feb 2026).
The defining workflow has three stages. First, a human specifies intent in natural language. Second, an AI agent generates code or code changes. Third, the human validates, corrects, and integrates the output. This differs from earlier autocomplete-centric assistance because the agent now operates across files and across larger units of implementation. Compared with traditional development, the principal acceleration lies in code generation throughput; the principal new bottlenecks lie in verification, contextual alignment, and review.
Empirical observation of extended public programming sessions further refines this definition. Vibe coding, as practiced by experienced developers, is not simply “accept all” automation. It is better characterized as a recurrent loop of prompting, rapid inspection, application testing, and selective manual intervention. That literature also frames vibe coding as an early case of “material disengagement,” in which practitioners manipulate the codebase more through AI-mediated orchestration than through direct authorship, while still retaining strategic oversight (Sarkar et al., 29 Jun 2025).
2. Workflow, prompting, debugging, and expertise
Observed vibe-coding sessions follow iterative goal-satisfaction cycles. Developers formulate a subgoal, prompt the model, inspect the resulting diff or generated files, run the application or tests, and then either refine the prompt or edit manually. Prompting is heterogeneous: vague outcome-oriented requests coexist with highly specific technical constraints, pasted error messages, documentation links, and code snippets. This mixed prompting style reflects the fact that the model is being steered at several abstraction levels at once (Sarkar et al., 29 Jun 2025).
Debugging remains a hybrid practice rather than a delegated one. Developers often use the AI as a first-pass repair mechanism by pasting stack traces or browser-console errors, but they also rely on conventional debugging instruments such as devtools, logs, network traces, and direct source inspection. The practical competence required by vibe coding therefore shifts rather than disappears. Expertise is redistributed toward context management, rapid evaluation of generated code, decomposition of goals into tractable subproblems, and judgment about when to remain in AI-driven mode and when to switch to manual manipulation (Sarkar et al., 29 Jun 2025).
Trust is similarly dynamic. The public “vibe coding” label can suggest blanket acceptance of model output, yet the empirical record points to contextual trust calibrated through repeated verification. Developers often accept large changes quickly when they match an anticipated pattern, but they also reject or re-scope outputs that appear architecturally misaligned, over-engineered, or unsupported by the surrounding system. A plausible implication is that vibe coding scales best when the developer has enough prior knowledge to perform high-bandwidth plausibility checks without rereading every line in detail.
3. Large-scale evidence on contribution scope and review burden
A large GitHub study provides the clearest quantitative evidence on how vibe coding behaves in open-source pull-request workflows. Using the AIDev dataset, the study examines 22,953 pull requests from 1,719 vibe coders in repositories with more than 100 stars, and splits authors into lower-experience and higher-experience groups using total GitHub commits normalized by account age. Across all pull requests, lower-experience vibe coders submit materially larger changes but generate substantially more downstream review overhead (Asdaque et al., 27 Feb 2026).
| Dimension | Lower-experience vs. higher-experience | Implication |
|---|---|---|
| Commits per PR | more | Larger change magnitude |
| Files changed per PR | more | Broader PR scope |
| Review comments per PR | more | Higher reviewer burden |
| Acceptance rate | lower | Lower merge success |
| Resolution time | longer | Slower integration |
These differences persist across categories rather than being confined to a single type of work. Lower-experience authors produce more commits in 10 of 11 pull-request categories, and those differences are significant. In feature work, for example, higher-experience authors average 1.58 commits per PR, whereas lower-experience authors average 4.20. For files changed, lower-experience authors exceed higher-experience authors in 9 of 11 categories, with significance in 5 of 11; in style-related pull requests the means are 24.29 versus 70.35 files changed. Acceptance rates are lower in 10 of 11 categories; for documentation pull requests, the study reports 93.06% acceptance for higher-experience authors versus 75.39% for lower-experience authors. Resolution times are significantly longer in 10 of 11 categories; for chore pull requests, the means are 0.61 days versus 2.83 days. Review-comment volume is significantly higher in 6 of 11 categories; for chores, the means are 0.13 versus 0.86 review comments per PR (Asdaque et al., 27 Feb 2026).
The statistical analysis uses Mann–Whitney U tests for distributional comparisons, Chi-square tests for merge outcomes, and Benjamini–Hochberg correction for multiple comparisons. Within the limits of the dataset, the central empirical pattern is consistent: AI assistance increases code-generation capacity for novices, but it does not erase experience differences in mergeability, contextual fit, or review efficiency.
4. Structural sources of friction
The same study combines quantitative findings with qualitative inspection of the highest-review-volume feature pull requests and identifies two recurring friction patterns. The first is infrastructure mismatch. AI-generated code may be syntactically valid while remaining poorly aligned with the actual build, runtime, or CI environment. In roboflow/inference pull request #1350, repeated execution timeouts in CI led to a long sequence of commits adjusting timeout parameters, suggesting a trial-and-error debugging process conducted through the pipeline itself rather than through a stable local understanding of the environment (Asdaque et al., 27 Feb 2026).
The second is integration friction. AI-generated logic often lacks repository-specific architectural, privacy, or interoperability context. In getsentry/sentry pull request #94889, a user-feedback feature generated substantial review activity because the implementation conflicted with existing privacy schemas and integration conventions. The point is not that the code was nonsensical; rather, it was contextually misaligned, and the reviewer had to supply the missing system knowledge during review (Asdaque et al., 27 Feb 2026).
These cases support the study’s broader interpretation that low-experience vibe coders often emphasize rapid code production while shifting verification work to maintainers. In that sense, vibe coding can become fast generation, slow integration. The cost removed from the authoring side reappears as reviewer cognition, review latency, and reduced acceptance probability. This also clarifies why larger pull requests and heavier review comments co-occur: greater AI-mediated output volume does not necessarily imply greater project-compatible value.
5. Governance, review adaptation, and model-centric alternatives
The managerial implication drawn in the empirical literature is direct: low-experience vibe coders cannot safely replace experienced developers without compensating increases in review capacity. Recommended responses include adding reviewer capacity when onboarding novices, using targeted training on validation of AI-generated code, and designing adaptive review policies such as smaller PR size limits, stronger pre-merge checks, and differentiated review thresholds for AI-heavy changes (Asdaque et al., 27 Feb 2026).
One response in adjacent literature is to move the locus of AI assistance upward, from raw code to software models. Vibe modeling proposes conversational interaction with an LLM tuned for modeling rather than coding, followed by deterministic model-to-code generation through a model-driven engineering stack. In that formulation, the human validates models, not raw generated implementations, and classic generators then produce source code, database schemas, deployment scripts, and related artifacts. The stated aim is to retain the speed of conversational interaction while recovering the determinism, validation, and maintainability advantages of model-driven engineering (Cabot, 30 Jul 2025).
A broader extension of the same idea is vibe-driven model-based engineering, which keeps explicit models at the center even when code generation may involve both rule-based generators and LLMs. This approach treats “vibe modeling” and model-guided vibe coding as complementary paths within a model-centric process, and proposes integration mechanisms such as MCP servers and skills so that agents manipulate modeling tools through explicit interfaces rather than through opaque end-to-end prompting (Cabot, 12 Apr 2026).
Taken together, these proposals suggest that the long-term trajectory of VIBE in software engineering may not be unrestricted natural-language-to-code generation. A plausible direction is a stratified workflow in which conversational AI remains central, but the most safety-critical or coordination-intensive outputs are mediated by typed models, deterministic generators, and stronger process controls.
6. Controversies, limitations, and research trajectory
Several limitations constrain current claims about vibe coding. First, definitions vary. The GitHub pull-request study uses a narrow notion of vibe coding based on agentic pull requests and human supervision, whereas other writing uses the term more broadly for AI-assisted programming. Results established for agentic open-source pull requests therefore do not automatically transfer to lightweight autocomplete use or to fully autonomous agents (Asdaque et al., 27 Feb 2026).
Second, experience measurement is imperfect. The main large-scale study operationalizes experience as GitHub commit history normalized by account age. This is an activity-based proxy rather than a direct measure of competence, and it may misclassify developers with substantial proprietary or offline experience. Third, the dataset is biased toward active GitHub repositories with more than 100 stars and toward repositories identifiable in the AIDev corpus; very small projects, private industrial repositories, and non-GitHub ecosystems are outside scope. Fourth, the observed outcomes are review-phase measures—acceptance, comments, resolution time—rather than direct measures of post-merge defect density or long-term maintainability (Asdaque et al., 27 Feb 2026).
There is also an unresolved productivity debate. The broader literature cited in the empirical work reports widespread perceived productivity gains, yet controlled evidence remains mixed. One cited study found that experienced open-source developers using AI required about 19% more time to complete tasks, while another found that AI-generated pull requests were accepted less often and were structurally simpler; the large-scale GitHub evidence reinforces the point that expertise differences persist under AI assistance rather than being flattened by it (Asdaque et al., 27 Feb 2026).
A more normative controversy concerns whether vibe coding should be allowed to remain primarily conversational. A position paper argues that vibe coding needs vibe reasoning: a verification-oriented “side-car” that autoformalizes specifications, validates code against targets, delivers actionable feedback to the LLM, and allows intuitive developer influence on those specifications. The underlying claim is that many failures arise from accumulated, unreconciled constraints across long conversational sessions, and that formal verification must become an integral companion to AI-mediated software development rather than a later audit stage (Mitchell et al., 31 Oct 2025).
The current research trajectory therefore points in two complementary directions. One is better sociotechnical governance of raw vibe coding: smaller reviewable units, explicit reviewer provisioning, stronger verification, and better training. The other is partial re-embedding of conversational AI inside model-centric and verification-centric workflows. Both directions imply the same general conclusion: VIBE changes the distribution of software-engineering labor, but it does not abolish the need for expertise, nor does it eliminate the organizational cost of ensuring that generated code is correct, coherent, and maintainable.
