AI Writes 3x More Code — But Ships Only 30% More. The Hidden Cost Is Developer Burnout

AI coding tools are very good at generating code and surprisingly bad at producing finished software. A new CEPR analysis published June 20 puts numbers on the gap, and the result is something most developers already feel by Friday afternoon: writing code got easier, shipping it didn’t, and the extra weight landed on whoever has to review it.

What happened

The CEPR (VoxEU) column “Writing code versus shipping code” tracked more than 100,000 GitHub developers across three successive generations of AI coding tools. Combined across all three, commit-level output roughly triples and raw code volume rises by even more. Yet the same developers work on only about 50% more projects and ship only about 30% more releases.

The reason, the authors argue, is that the human bottlenecks didn’t move. Reviewing, integrating, testing, and releasing code still take human judgment, and that’s exactly where the AI-driven gains evaporate.

A widely cited randomized controlled trial from METR points the same way. It followed 16 experienced developers working in codebases they knew well. Using AI tools (Cursor Pro with Claude 3.5/3.7 Sonnet) left them 19% slower, even though those same developers expected a 24% speedup and walked away believing they’d been about 20% faster. They reviewed nearly every line and rewrote substantial parts of more than half the suggestions they accepted.

Survey data shows the same strain. A Harness survey found 67% of engineering leaders now spend more time debugging AI-generated code than they used to, and 68% report spending more time fixing security issues that code introduced.

Why it matters

For most of software history, writing code was the constraint. AI loosened it and exposed something a little uncomfortable: the hard part was always the rest of the job. Reading the system, making sure it actually works, deciding what’s safe to ship. AI doesn’t remove that work. It just hands you more code to do it on.

The result is a subtler kind of fatigue. You’re no longer the author wrestling a blank file; you’re the reviewer scanning a firehose of plausible-looking output for the one hallucinated edge case that takes down prod. That’s vigilance work, and vigilance is exhausting in a way that flow is not.

What this means for developers

If your output tripled but your energy didn’t, you’re not failing. You’re absorbing a structural shift. A few habits make it more sustainable:

Treat review attention as a budget, because you only get so much sharp focus a day. Don’t rubber-stamp AI output at 4 p.m. Do the hard verification when you’re freshest and let the model scaffold low-stakes work later.
Cut down the context-switching. The same studies blame a lot of the churn on constant toggling between writing, prompting, and reviewing. Batch AI-assisted work into blocks instead of flipping modes all day.
Defend your deep work. Reviewing output is shallow, reactive attention; the design and systems thinking only you can do needs AI-free blocks on the calendar.
Track how you feel, not just what you shipped. “Shipped a lot” and “felt good doing it” are different numbers. After AI-heavy days, check the second one. That’s where burnout shows up first.

Output at the commit level roughly triples, but the same developers ship only about 30% more releases. — CEPR, “Writing code versus shipping code,” June 2026

The bottom line

AI made the easy part easier and the hard part more relentless. The developers who last won’t be the ones who generate the most code. They’ll be the ones who guard their review attention, their focus blocks, and their recovery as carefully as they guard the codebase. Productivity that costs you your energy isn’t really productivity. It’s a loan, and you pay it back later.