95% of developers use AI tools. 72% reject vibe coding. 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. Research from multiple institutions found that AI co-authored code has 1.7x more major issues and 2.74x more security vulnerabilities. Open-source maintainers started closing their gates: cURL shut down its bug bounty, Ghostty banned AI-generated contributions, tldraw auto-closes all external PRs.
Something interesting is happening. AI tool adoption is at an all-time high — 95% of developers use them weekly — while trust in AI-generated code is at a low. 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 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 findings are consistent across studies:
These numbers come from analyzing actual production code, 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 receiving a wave of AI-generated vulnerability reports that were plausible-sounding but wrong. The maintainers were spending more time evaluating bogus reports than fixing real bugs. Daniel Stenberg, cURL's creator, described receiving reports that were "fluent, confident, and completely made up."
Ghostty, the terminal emulator, banned AI-generated code contributions entirely. Their 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 has over 45,000 GitHub stars. 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. A Hashnode survey found that only 15% of developers practice vibe coding professionally — letting AI generate code they don't fully review or understand. 72% reject the practice entirely. The remaining 13% use it only 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:
This is why we built AI into yaw as a tool you control — BYOK, no telemetry, no account required. The AI is there when you want it. It doesn't make decisions for you. That's the model that survives the backlash.
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.
Interested in AI tools and developer workflows? Token Limit News is our weekly newsletter.