The Vibes Are Real. The Data Is Not Great.
In February 2025, Andrej Karpathy posted a description of a new way of writing software: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. I 'Accept All' always, I don't read the diffs anymore." The term went viral. Collins English Dictionary named it Word of the Year for 2025. [1]
By 2026, 84% of developers use AI coding tools, up from 76% the year before. But only 29% trust the code those tools produce — an 11-point drop from 40% in 2024. 46% actively distrust AI output. The adoption curve went up. The trust curve went down. [2]
That divergence is the story of vibe coding in 2026: nearly universal adoption of a practice that most practitioners do not fully trust.
The Productivity Paradox
The most carefully designed study on AI-assisted coding productivity came from METR, which ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks in repositories averaging over one million lines of code. The developers forecasted that AI tools would make them 24% faster. They self-assessed a 20% speed improvement after using the tools. Objective measurement showed they were 19% slower. [3]
The three-way gap — predicted faster, felt faster, measured slower — is consistent with research on cognitive offloading. A preregistered study with 1,237 participants found that people significantly underestimate AI-assisted completion times while reporting lower subjective effort. The bias is specific to AI: it does not appear when participants imagine help from another human. [4]
The implication is uncomfortable: the productivity gains that make vibe coding feel transformative may be, in some contexts, an illusion. METR itself now labels their result as "historical," noting it may not reflect current tools. But the cognitive offloading pattern — feeling productive while producing lower-quality output — appears robust.
The Quality Gap
In December 2025, CodeRabbit published an analysis of 470 open-source GitHub pull requests comparing AI-co-authored code against human-written code. AI-authored changes averaged 10.83 issues per pull request versus 6.45 for human-written code — roughly 1.7 times more major issues. Security vulnerabilities were 2.74 times higher. Readability issues were 3 times higher. Performance inefficiencies involving excessive I/O were approximately 8 times more common. [5]
GitClear's analysis of 623 million code changes between 2023 and 2026 shows structural degradation in codebases using AI tools: copy-paste patterns up 41%, code block duplication up 81%, error-masking constructs up 47%, cross-file function calls (a measure of code reuse) down 35%, and refactoring line moves down 70%. [6]
The pattern is consistent: AI-assisted code is more duplicated, less reusable, and harder to maintain than the code it replaces.
The Security Problem
Veracode tested over 100 LLMs across 80 coding tasks in Java, Python, C#, and JavaScript. 45% of AI-generated code introduced OWASP Top 10 vulnerabilities. 86% of samples failed to defend against cross-site scripting. 88% were vulnerable to log injection. Security pass rates have remained essentially flat at 45–55% since 2023, even as syntax pass rates climbed from 50% to 95%. AI-assisted developers produce commits at 3–4 times the rate but introduce security findings at 10 times the rate. [7]
In April 2026, the ACM Technology Policy Council issued a formal warning: vibe coding "often skips over core engineering practices that ensure systems are secure, reliable, and maintainable." The ACM noted that AI systems generate code "without enforcing specifications or systematically validating outputs" and recommended rigorous testing, output auditing, and human oversight. [8]
The Open Source Burden
The volume problem extends beyond individual codebases. AI coding agents enable a single developer to produce five or more pull requests per day, flooding open-source maintainers who review on a volunteer basis. The curl project shut down its six-year HackerOne bug bounty program in January 2026 after AI-generated submissions overwhelmed the security queue — fewer than 5% of reports in 2025 were legitimate. The Jazzband Python collective shut down entirely, citing the volume of AI-generated spam PRs as a primary driver. [9]
Where Vibe Coding Works
The data is not uniformly negative. In specific contexts, the speed of AI-assisted development creates genuine value:
Prototyping and MVPs — Tasks that used to take weeks can be completed in hours. API integration and boilerplate code see time savings up to 81%.
Internal tools and scripts — Low-stakes utilities that benefit from speed without carrying the full burden of long-term maintainability.
Learning and exploration — Senior developers use vibe coding to rapidly explore unfamiliar frameworks and prototype API integrations before committing to an architecture.
The common thread: these are contexts where the cost of a defect is low and the value of speed is high. For critical infrastructure, healthcare systems, or financial applications, the quality and security gaps documented above make unreviewed AI-generated code a liability.
The Discipline Gap
72% of developers say they do not vibe code as part of professional work. Only 12% say they do. But the same survey shows that 66% cite their biggest frustration as AI producing solutions that are "almost right, but not quite" — a signal that many developers are accepting AI suggestions without fully reviewing them, even if they would not describe it as vibe coding. [2]
The gap between what vibe coding is and what professional AI-assisted development should be is not a tooling problem. It is a discipline problem. The tools are here. What is missing is the engineering practice around them: test-first workflows that catch errors before they ship, safety guardrails that prevent irreversible actions, and review practices that treat AI output with the same scrutiny as a junior developer's pull request.
Karpathy was right that vibe coding is "not too bad for throwaway weekend projects." He was also right to call it out as distinct from professional software engineering. The industry adopted the practice. It has not yet adopted the distinction.