Why we’ve stopped noticing the real improvement opportunity
Since AI arrived, many people have mentioned that the bottleneck has shifted from coding to code review. This isn’t quite right, as coding wasn’t the bottleneck in the first place, and it’s not code review now. The reason we think either of these things is constraining the flow of value is that mossy hill we all stare past when we look at the mountains.
Here’s a simple test. For the application or service you work on, how many changes have passed code review but haven’t yet been deployed and enabled for users? If the answer is none or one, accept my apologies: in your specific case, I’m wrong. But I rarely get that answer. It’s usually more than one and that tells you the bottleneck is elsewhere.
Number of changes per deployment batch (Source: Octopus Deploy)
We’re conducting original research in this area right now, and half of all teams have between 2 and 10 changes sitting in a batch, and a quarter have 11–50. Overall, more than 90% of teams ship in batches rather than one change at a time.
This number reveals an industry-wide visibility gap. People believe Claude Code, Cursor, and GitHub Copilot have shifted the bottleneck from coding to code review, but that ignores everything that happens after the review and that’s not a personal failing, it’s an industry-wide misperception.
We’ve grown so used to working in batches that the practice looks like it belongs. It’s overgrown with moss, indistinguishable from the surrounding hills. When you search for ways to speed up software delivery, you won’t see it, because it doesn’t look like a problem. It looks just as things have always been.
What happens when AI floods a batch
Writing code is a small part of a longer value stream that starts with an opportunity and ends when a user gets the value they need. The impact across this whole value stream is lumpy. AI will help more in some areas than others, and the end-to-end benefit depends on you noticing the areas where work accumulates.
GitLab’s 2026 AI Accountability Report found 85% of respondents agree AI has shifted the bottleneck from writing code to reviewing it. Yet we can see from deployment batches that 92% of these people are likely wrong, because if there’s accumulation after the code review, it means code review isn’t the bottleneck. It also means speeding up the reviews will make the real bottleneck worse.
This isn’t to say increased coding speed doesn’t put pressure on code review. Faros AI’s research across 10,000 developers found that teams with high AI adoption merge 98% more pull requests, but review time for those changes grows 91%, and average pull request size grows 154%. Cursor’s own study, run with a University of Chicago economist, found companies merge 39% more pull requests once its coding agent becomes the default.
However, approving changes faster is a strategy that only works if the change then flows smoothly to production. In the majority of cases, it simply moves into the queue of changes awaiting some other handling, like testing and deployment. If you up the rate and size of changes passing through the review stage, pressure is simply transferred to the real bottleneck.
Code review looks like a constraint only because it has a visible queue, while the downstream queues are hidden by their general acceptance across the industry. The job of your pipeline is to get changes to production, where they can be used, not to gather them in a “pending deployment” queue.
And while all those unreleased changes are building up, risk accumulates with it.
Batches are signposts
Ask the batch-size question, and you’ll find what’s really constraining your value stream: a manual verification step, a cumbersome change approval or release train process, or no easy way to deploy changes. Not coding. Not code review.
It’s likely you were working in batches before you started your AI initiative. The introduction of AI will increase the size of your batches and that can cause problems. Increasing code review throughput doesn’t solve the problem, it simply moves changes to the bottleneck faster.
Using the true constraint to set the pace of your whole value stream will help you invest in solving the right problem. If your retrospectives keep failing to produce noticeable improvements, you’re likely missing the batch problem. It’s why some AI initiatives pay off while others flop.
The studies miss it, too
The research into the impact of AI is useful, but like many studies on this topic, it stops at the point code gets merged. It looks at pull requests opened, pull requests merged, hours spent reviewing. None of it asks how long changes wait after the review, or how many are bundled together before anyone sees them in production. Without that number, you can’t find the real constraint.
Having invested in AI to speed up coding, you’ll be tempted to fix code review next, or give up on code reviews altogether. If you’re shipping in batches, neither will make much difference to how quickly you remove risk or deliver value to the people using the software.
The reason your organization resists fixing the batch problem is the real problem you need to solve.