In February 2025, Andrej Karpathy posted a tweet that gave a name to something millions of developers were already doing: "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He called it vibe coding (opens in new tab).
Within months, it went from a catchy phrase to an entire philosophy. Natural-language prompts replacing manual code authorship. AI generating entire features while the developer watches, tests, and prompts again. The pitch is compelling: why spend hours writing code when you can describe what you want and have it materialize in seconds?
The pitch is also wrong. Not because AI can't generate code. It can, and it's often impressive. The pitch is wrong because it assumes the hard part of software engineering was always writing the code. It wasn't. The hard part was understanding what the code does, knowing when it will break, and being able to fix it when it does. Vibe coding optimizes for the easy part and ignores everything else.
The data is starting to come in. It's not encouraging.
The Productivity Illusion
The surface-level numbers look great. Repositories using AI-assisted workflows show diff sizes per commit increasing 2-3x (opens in new tab) and commit frequency rising 1.4-1.9x. Median task completion time for greenfield features drops by 20-45%. More code, faster. What's not to like?
Look one layer deeper. Teams practicing prompt-driven development accumulate technical debt 3x faster (opens in new tab) than traditionally developed projects. Developers spend 63% more time debugging AI-generated bugs than they would debugging code they wrote themselves. Revert frequency for large AI-generated commits runs about 30% higher than for human-written commits of similar scope. Code review time per PR increases by 25-40% when reviewers didn't author the code or guide the AI that wrote it.
The pattern is consistent across every dataset: speed goes up at the point of creation and goes down everywhere else. Writing code was never the bottleneck. Understanding code is. And vibe coding systematically undermines understanding.
The 40% Problem
In 2021, researchers at NYU tested GitHub Copilot across 89 code generation scenarios. About 40% of the generated code contained security vulnerabilities (opens in new tab).
Five years later, things have improved, but not by as much as you'd hope. A 2026 study tested six current-generation LLMs (opens in new tab) (GPT-5.2, Claude Opus 4.6, DeepSeek V3, Llama 4 Maverick, Gemini 2.5 Pro, and Grok 4) across 534 code samples. The result: 25.1% contained confirmed vulnerabilities. The best model (GPT-5.2) still produced vulnerable code 19.1% of the time. The worst hit 29.2%.
SSRF led with 32 confirmed findings. Injection vulnerabilities followed at 30. Those two categories alone accounted for a third of all findings.
But the most dangerous stat isn't the vulnerability rate. It's what happens to developer confidence. Researchers have consistently found that developers using AI assistants report higher confidence in the security of their code while simultaneously writing less secure code. The tools create a false sense of safety. You feel like everything is fine because the code compiles, the tests pass, and the AI seemed confident. Meanwhile, you just shipped a login form with no rate limiting and a file upload handler that doesn't validate content types.
One in four code samples from the best available AI models contain confirmed vulnerabilities. And the developers producing them think they're writing more secure code than ever.
The Learning Deficit
This is where it gets structural.
In January 2026, Anthropic published a randomized controlled trial (opens in new tab) examining how AI assistance affects skill development. They recruited 52 software engineers, gave them coding tasks using an unfamiliar Python library, and split them into two groups: one with AI assistance, one without.
The AI group scored 17% lower on a comprehension quiz administered minutes after completing the tasks. That's the equivalent of nearly two letter grades. The largest gap was on debugging questions, which is exactly the skill you need most when overseeing AI-generated code.
The qualitative analysis revealed distinct interaction patterns. Engineers who delegated everything to AI, who used it to debug iteratively, or who progressively relied on it more throughout the session all scored below 40% on comprehension. Engineers who asked follow-up questions, requested explanations alongside code, or used AI only for conceptual queries while coding independently scored above 65%.
The implication is stark. The way most people use AI coding tools, the path of least resistance where you prompt, accept, and move on, is the pattern most strongly associated with not understanding what you just built. The engineers who use AI well are the ones who were already doing most of the cognitive work themselves.
Anthropic's own footnote makes the point explicitly: "This setup is different from agentic coding products like Claude Code; we expect that the impacts of such programs on skill development are likely to be more pronounced than the results here."
The tools that promise to do the most are likely to teach the least.
The Open Source Canary
If you want to see what happens when the cost of generating code drops to zero but the cost of reviewing it stays the same, look at open source.
Daniel Stenberg maintains curl, one of the most widely used pieces of software on the planet. Starting in mid-2025, his project was flooded with AI-generated bug bounty submissions (opens in new tab). The reports used professional security terminology, mimicked the structure of legitimate vulnerability disclosures, and were almost entirely worthless. By July 2025, he described the situation as being "effectively being DDoSed." Submissions had surged to eight times normal levels. Roughly 20% were AI-generated junk. Only about 5% of all 2025 submissions represented real vulnerabilities.
Each report took 3-4 team members between 30 minutes and several hours to review. That's volunteer time, taken from a small team maintaining software that runs on billions of devices.
In January 2026, curl shut down its HackerOne bug bounty program entirely (opens in new tab). Not because they fixed all the bugs. Because the signal-to-noise ratio made the program unsustainable.
The Godot game engine faced the same pattern. Maintainers described AI-generated pull requests as "increasingly draining and demoralizing." The Linux Foundation, Fedora, Firefox, Blender, and LLVM have all adopted formal policies on AI-generated contributions. Some projects are migrating off GitHub entirely (opens in new tab), partly because the platform's own AI features encourage the behavior its open-source community is struggling to contain.
This isn't just an open-source problem. It's a preview. Inside companies, the same asymmetry exists: generating code is now nearly free, but reviewing it costs the same as it always did. When everyone can produce pull requests at 3x the old rate but review capacity hasn't changed, the math doesn't work. Something gives, and usually it's review quality.
The 20% AI Can't Handle
Everything above is backed by data. This section is opinion, drawn from building and maintaining distributed systems in production.
AI can scaffold a microservice in ten minutes. It won't decide whether you needed a microservice. AI can write a Kafka consumer. It won't make it idempotent. AI can generate a SQL query. It won't think about the isolation level or whether your read is going to deadlock under concurrent writes. AI can set up an SQS queue. It won't configure the dead letter queue or think about poison messages. AI can implement retry logic. It won't consider the downstream service's circuit breaker.
The 80% that AI handles well is scaffolding, CRUD, boilerplate, standard patterns. That was never the hard part. Nobody ever stayed up until 3am debugging a for loop. They stayed up debugging a race condition that only surfaces under load, or a message ordering issue that appears when one consumer is slower than another, or a transaction isolation bug that corrupts data 0.1% of the time and takes weeks to notice.
That remaining 20% is where engineering actually happens. It's judgment calls about tradeoffs, failure mode analysis, understanding how components interact under conditions the AI has never seen in its training data. It's the part that requires knowing not just what works, but why it works, and under what conditions it stops working.
Vibe coding is optimized for the 80%. The 20% is where it falls apart, and the 20% is the part that determines whether your system works in production or just works in a demo.
The Engineers Who Will Thrive
I'm not anti-AI. I use these tools daily. The issue isn't AI-assisted coding. It's AI-delegated coding: accepting output without understanding it, optimizing for generation speed instead of comprehension, treating the tool as an oracle instead of a first draft.
The Anthropic study found that engineers who asked follow-up questions, who requested explanations, who used AI for conceptual understanding while coding independently, scored just as well as those who didn't use AI at all. The tool wasn't the problem. The interaction pattern was.
The engineers who will thrive aren't the ones who generate the most code. They're the ones who know which generated code to throw away. That skill, the ability to evaluate a solution rather than just produce one, requires exactly the kind of judgment that StackOverflow's comment sections used to build and that vibe coding systematically fails to develop.
We're producing more code than ever. The question is whether we're producing more software, or just more text files that happen to compile.
Data sources: Anthropic Research (opens in new tab), AppSec Santa 2026 Study (opens in new tab), NYU/Stanford Copilot Security Study (opens in new tab), Panto AI Vibe Coding Statistics (opens in new tab), Daniel Stenberg (curl) (opens in new tab), DevClass (opens in new tab).