·
Nearly every developer uses AI tools. 72% say vibe coding has no place in their professional work. The data is starting to explain why.
Vibe coding - the practice of letting AI generate code you don't fully understand, accepting it as long as it seems to work - entered the mainstream vocabulary in early 2025. By early 2026, the backlash arrived. Not from Luddites. From the data.
A METR study found that experienced developers were actually 19% slower when using AI coding tools, despite believing they were 20% faster. CodeRabbit's analysis of 470 open-source pull requests found that AI co-authored code has 1.7x more issues overall and up to 2.74x more security vulnerabilities of specific classes. Open-source maintainers started closing their gates: cURL shut down its bug bounty, Ghostty went zero-tolerance on AI-generated contributions, tldraw auto-closes all external PRs.
Something interesting is happening. AI tool adoption is at an all-time high - Hashnode's State of Vibe Coding 2026 puts daily AI-tool use at 92% of US developers - while trust in AI-generated code is at a low: only 33% trust its accuracy, down from 43% in 2024. These two things aren't contradictory. They're the beginning of a more honest conversation about what AI tools actually do well and where they fail.
The study that changed the conversation came from METR, which measured experienced open-source developers working on their own repositories - codebases they knew intimately. The developers used Cursor Pro with Claude 3.5 and 3.7 Sonnet on real tasks from their own issue trackers.
The result: tasks took 19% longer with AI assistance compared to without it. But here's the twist - before seeing the data, the same developers predicted they were 20% faster. A nearly 40-percentage-point gap between perceived and actual productivity.
Why? The researchers identified several patterns. Developers spent significant time reviewing, debugging, and correcting AI-generated code. They accepted suggestions that were close but not quite right, then spent cycles fixing subtle issues. The AI tools were most helpful for boilerplate and least helpful for code that required deep understanding of the specific codebase - which is exactly the code that experienced developers write most of the time.
This doesn't mean AI tools are useless. It means the productivity gains are more nuanced than "just let the AI write it."
Separate from the speed question, researchers have been measuring the quality of AI-assisted code in production. The headline numbers come from CodeRabbit's State of AI vs Human Code Generation report, which compared 320 AI-assisted pull requests against 150 human-only ones across open-source GitHub repositories:
These numbers come from analyzing real pull requests, not toy benchmarks. The pattern is clear: AI tools generate code that looks correct, passes a quick visual review, and introduces subtle bugs that surface later. Security vulnerabilities are particularly concerning because they require adversarial thinking to catch - exactly the kind of reasoning that current AI models struggle with.
None of this is surprising if you've spent time with AI coding tools. They're excellent at producing syntactically correct code that implements the obvious interpretation of your prompt. They're poor at understanding implicit constraints, security boundaries, edge cases in your specific system, and the reasons behind existing architectural decisions.
The most visible backlash has come from open-source maintainers who are drowning in AI-generated contributions:
cURL shut down its bug bounty program after a wave of AI-generated vulnerability reports that were plausible-sounding but wrong. By 2025, AI-generated reports made up roughly a fifth of submissions while genuine vulnerabilities fell to about 5%, and the maintainers were spending more time evaluating bogus reports than fixing real bugs. Daniel Stenberg, cURL's creator, said ending the program was an attempt to "remove the incentive for people to submit crap and non-well researched reports."
Ghostty, the terminal emulator, went zero-tolerance. After first requiring disclosure of any AI tooling in contributions, Mitchell Hashimoto tightened the policy: AI-assisted PRs are allowed only for accepted issues, drive-by AI PRs are closed without question, and repeat offenders are banned. The rationale: reviewing AI-generated PRs takes as long as writing the code from scratch, because the reviewer has to verify every assumption the AI made - and the AI doesn't flag which assumptions it's unsure about.
tldraw, the whiteboard app, started auto-closing all external pull requests. The volume of low-quality, AI-generated PRs made the signal-to-noise ratio untenable. Maintainers couldn't distinguish between thoughtful contributions and "I asked Claude to fix this issue" drive-bys.
These aren't fringe projects. cURL is in every Linux distribution, every Apple device, every Windows installation. Ghostty is one of the most popular terminal emulators on GitHub. When maintainers of foundational software say AI-generated contributions are a net negative, the developer community notices.
Bloomberg ran a piece headlined "AI Coding Agents Are Fueling a Productivity Panic in Tech." Fortune published "In the Age of Vibe Coding, Trust Is the Real Bottleneck." The narrative has shifted from "AI will replace developers" to "AI is creating new categories of risk."
Meanwhile, the surveys paint a picture of an industry that uses AI tools extensively but doesn't trust the output blindly. In Stack Overflow's 2025 Developer Survey, nearly 72% of developers said vibe coding - letting AI generate code they don't fully review or understand - is not part of their professional work, and another 5% were emphatic about never touching it. The minority who do practice it mostly describe reserving it for throwaway prototypes and experiments.
Staff+ engineers lead AI adoption, which is often cited as evidence that AI tools are valuable. But it's worth noting how senior engineers use them: for boilerplate generation, documentation, test scaffolding, and exploring unfamiliar APIs. They use AI as a starting point, not a finish line. They review and rewrite. That's the opposite of vibe coding.
The backlash isn't against AI tools. It's against a specific way of using them. The distinction matters:
AI-assisted coding: You understand the problem. You understand the codebase. You use AI to generate a first draft, a boilerplate, or to explore an approach. You review the output critically, understand every line, and modify it to fit your system's constraints. The AI saves you typing, not thinking.
Vibe coding: You describe what you want. The AI generates code. You run it. If it works, you ship it. If it doesn't, you paste the error back and let the AI try again. You don't fully understand what the code does or why it works. The AI saves you thinking, not just typing.
The first approach produces better code than working without AI. The second approach produces the 1.7x major issues, the 2.74x vulnerabilities, and the 19% slowdown. The METR study's subjects were likely somewhere in between - experienced developers who understood their codebases but still fell into the trap of accepting "close enough" suggestions.
In February 2026, every major AI coding tool shipped multi-agent capabilities. Claude Code got Agent Teams. Codex CLI got the Agents SDK. Windsurf shipped five parallel agents. Grok Build launched with eight. The sales pitch: AI agents working on different parts of your codebase simultaneously.
Multi-agent coding amplifies both the benefits and the risks. When it works, you get parallel progress on independent tasks. When it doesn't, you get multiple agents making assumptions about each other's work, introducing subtle conflicts that no individual agent can see. The review burden doesn't just double - it compounds, because you need to verify not just each agent's output but how they interact.
For teams that already struggle to review single-agent output carefully, multi-agent coding is going to make the quality problems worse, not better.
Here's where we land: AI coding tools are useful. Vibe coding is not. The data supports using AI deliberately, not abdicating judgment to it.
A few specifics:
The tools that survive the backlash share a pattern: BYOK, no usage tracking, no account required, opt-in by default. The AI is there when you want it - it doesn't make decisions for you. That's the model we chose when building yaw, and it's what we'd look for in any AI tool going forward.
The vibe coding backlash isn't a rejection of AI. It's a correction. The pendulum swung too far toward "let the AI handle it," and it's swinging back toward "use the AI, but understand your code." That's a healthier place to be.
Published by Yaw Labs.