AI hasn’t shifted the bottleneck from coding to code review

There's a comfortable story going around dev teams right now: AI tools like Claude Code, Cursor, and Copilot write code so fast that the bottleneck moved downstream, into code review. GitLab's 2026 AI Accountability Report backs this up on the surface, with 85% of respondents agreeing that reviewing has become the new choke point. The problem is the story is wrong, and it's wrong in a way that's easy to miss because it looks so plausible.

Here's the tell. Ask how many changes at your company have cleared code review but haven't actually been deployed yet. If that number is zero or one, fine, you're an outlier. But for the vast majority of teams, it isn't. Research from Octopus Deploy shows half of teams sit on 2 to 10 unreleased changes at any given time, and a quarter carry 11 to 50. Over 90% of organizations ship in batches rather than one change at a time. That backlog is the actual bottleneck, and it's been there long before anyone typed a prompt into an AI coding assistant.

What AI does is make this hidden problem worse, not better. Faros AI studied 10,000 developers and found that teams with heavy AI adoption merge 98% more pull requests, but review time balloons by 91% and average PR size grows 154%. Cursor's own research, done with a University of Chicago economist, found a 39% jump in merged pull requests once its agent becomes the default workflow. Speeding up review sounds like progress. But if the pipeline after review — testing, approval gates, manual verification, release trains — hasn't gotten faster too, all that extra throughput just piles up in a queue nobody's watching, waiting for deployment.

The reason nobody notices is cultural, not technical. Batching has been standard practice for so long that it's stopped registering as a problem. It blends into the landscape of how software has always shipped, so when teams go looking for delivery speedups, this queue never even shows up on the list. Meanwhile, every unreleased change sitting in that queue is also accumulating risk, quietly, while everyone congratulates themselves on faster reviews.

Even the studies measuring AI's impact stop too early. They track open PRs, merge counts, review hours — everything up to the merge button, then nothing after. Nobody's asking how long merged code waits before it reaches actual users, or how many changes get bundled before deployment. Without that number, teams end up optimizing the wrong stage entirely, either pouring more resources into review tooling or abandoning review discipline altogether, when neither move touches the real constraint sitting downstream.