A robot zips around a DevOps infinity loop.

Code review isn't your bottleneck, even with AI

How batch size reveals the true constraint in your software delivery flow

Steve Fenton
Steve Fenton

There are lots of reasons to believe AI has shifted the bottleneck from coding to code review. That’s wrong for two reasons, and we can prove it by answering one question.

For the system you currently work on, how many changes have passed code review but haven’t been deployed and enabled for users?

The further this number is from zero, the less likely it is that coding or code review is your constraint.

The difficulty is that, within the software delivery industry, we’ve grown so used to certain practices that they now look like they belong. When you search for ways to improve software delivery capability, you don’t see them. These practices are so deeply embedded that they are overgrown with moss and are indistinguishable from the hills.

When changes are collected in batches after code review, it proves that code review isn’t your bottleneck, and coding wasn’t either.

The desire for fast software delivery

Writing the code is a very small part of a long value stream. A value stream begins with an opportunity to provide something people want and ends when they get it.

Few organizations are building completely unique software. If the primary factor were speed, they would use something off-the-shelf that’s “good enough”. As someone has decided to spend vast sums of money creating something bespoke, you need to understand those other needs. What is it that makes it valuable enough to spend so much money on it?

To answer this question, you build the software, make sure it’s releasable, and get it into the hands of the people who need to use it. Only then can you see if you’re building the right thing.

The two errors

Since AI arrived, many people have proclaimed 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 (error 1), and it’s not code review now (error 2). 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.

Chart showing 92% of teams have deployment batch sizes of more than 1 change.

Number of changes per deployment batch

Just 8% of teams deploy changes independently, while 92% deploy in batches. Only 8% are correct when they say the bottleneck moved from coding to code review. For the vast majority, this isn’t true.

Batches are signposts

When you ask this batch size question, you peel back the moss and uncover what’s beneath. This is how you find the true constraint in your value stream. You might have manual verification steps, a cumbersome change approval board meeting, or no easy way to deploy changes to development, test, and production. These are the things holding you back. Not coding and not code review.

You were likely working in batches before your AI initiative, and AI will certainly result in larger change size and larger batches if you don’t pay attention to your constraints. Speeding up the coding stage only adds pressure to the real bottleneck.

Using the constraint to set the pace of your value stream will lead you to invest improvement efforts where they matter most. If you find your retrospectives fail to provide noticeable improvements, it’s likely because you’re missing that mossy mound. It’s the reason some AI initiatives fail to deliver a return on investment, while others succeed.

But… the data

Some studies, like GitLab’s 2026 AI Accountability Report, also say that bottlenecks have shifted from coding to code review, but they also overlook the mossy mound. Where they haven’t captured the size or number of changes that haven’t reached production users, they can’t observe the true bottleneck.

Having invested in AI to increase coding speed, you’ll now be tempted to invest in solving the code review problem, or to abandon it. If you’re working in batches, you’ll discover this makes little difference to your ability to deliver valuable software.

The reasons your organization is resisting solving the batch problem are the real problems you need to fix.

Look for the accumulation of changes throughout your process. Identify the true constraint, and apply the five focusing steps to manage it; and that includes making all other stages march at the pace of the constraint.

Happy deployments!

Steve Fenton

Steve Fenton is a Principal DevEx Researcher at Octopus Deploy and a 8-time Microsoft MVP with more than two decades of experience in software delivery.

Related posts