You've probably heard it: AI coding assistants have boosted developer productivity so much that code review is now the bottleneck. GitLab's research suggests this shift. Your team might be discussing how to speed up reviews or add more reviewers to handle the load.
But you're solving the wrong problem.
The real bottleneck is downstream, often invisible to most teams: the accumulation of changes waiting in deployment batches. While everyone focuses on review speed, your value stream is clogged with merged code not reaching production. Let's debunk the myths that keep you focused on the wrong metrics.
Myth 1: AI Has Moved the Bottleneck to Code Review
Reality: AI has increased pressure on code review, but that's not your constraint.
Faros AI found that teams with high AI adoption merge 98% more pull requests, and review time increases by 91%. It sounds like a bottleneck, right? More work piling up at a single stage.
But that's not how bottlenecks work in your value stream. A bottleneck is the stage that limits your overall throughput. If code is reviewed and merged but then sits in batches waiting for deployment, the constraint is downstream. You're just seeing symptoms upstream.
Think of it this way: if your deployment pipeline can only handle releases twice a week, it doesn't matter how fast you review code. The merged changes will accumulate until the next deployment window. Speeding up review just means more changes sitting in your staging environment.
Myth 2: Deployment Is Fast Once Code Is Merged
Reality: Half of all teams have 2-10 changes sitting in deployment batches, and a quarter have 11-50.
These numbers from Octopus Deploy reveal the hidden inventory in your pipeline. Every change in a batch represents completed work not delivering value. It's like finished goods sitting in a warehouse instead of reaching customers.
Your deployment batch size directly impacts your lead time and risk profile. A batch of 20 changes is harder to test, roll back, and troubleshoot when something breaks. But because most teams don't measure batch size or time-in-batch, they don't see this constraint.
Ask yourself: how many merged PRs are waiting in your main branch right now? How long have they been there? If you don't know, you can't optimize it.
Myth 3: We Have Visibility Into Our Entire Pipeline
Reality: Most teams track coding and review metrics but lose visibility after merge.
You probably have dashboards showing PR creation time, review duration, and time to merge. Your CI runs are logged. Your test coverage is tracked. But what about the time from merge to production deployment?
This visibility gap is why the deployment batch problem persists. Your tooling makes it easy to see developer and reviewer activity. It's harder to measure the dwell time of changes in your deployment queue, especially if you batch releases manually or tie them to sprint boundaries.
The metrics you don't measure are the ones you can't improve. If your deployment process isn't instrumented, you're flying blind through the most critical part of your value stream.
Myth 4: Smaller Batches Would Slow Us Down
Reality: Smaller batches reduce risk and speed up your feedback loops.
Teams resist reducing batch sizes because they assume each deployment has fixed overhead. If it takes 30 minutes to deploy, surely deploying 20 changes at once is more efficient than deploying them individually?
But that calculation ignores the cost of large batches. When a batch of 20 changes causes a production issue, you're troubleshooting 20 potential culprits. Your mean time to recovery increases. Your team's cognitive load increases. Your rollback decisions get harder.
Smaller batches mean faster feedback. When a deployment fails, you know exactly which change caused it. Your test cycles are shorter. Your rollbacks are simpler. You can actually move faster by deploying more frequently with less in each batch.
This is why continuous deployment exists. The teams practicing it aren't doing more work, they're eliminating the waste of batching.
Myth 5: AI Will Eventually Solve This Problem Too
Reality: AI can help, but only if you fix your deployment process first.
Some teams assume AI will eventually automate deployment decisions, optimizing batch sizes and release timing. Maybe it will. But automating a broken process just gives you broken results faster.
AI coding assistants have already shown you this pattern. They increased your coding velocity, which exposed the code review constraint, which exposed the deployment batch constraint. Adding AI to deployment without addressing batch accumulation will just shift the bottleneck again, probably to your monitoring and incident response.
The solution isn't more automation. It's designing your pipeline to handle the increased flow that AI enables.
What to Do Instead
Start by measuring what you're not currently tracking:
Instrument your post-merge pipeline. Track time from merge to deployment. Measure your batch sizes. Calculate the age of the oldest change in each deployment. You need visibility before you can optimize.
Set batch size limits. If you're regularly deploying batches of 10+ changes, you're increasing risk and obscuring the source of issues. Set a target maximum, 5 changes is reasonable for most teams, and work toward it.
Decouple deployment from release. Use feature flags to separate code deployment from feature activation. This lets you deploy continuously while controlling when users see changes. Your batch size drops to 1, but your release risk doesn't increase.
Automate your deployment pipeline. If manual steps are forcing you to batch changes, remove them. Your deployment process should be as automated as your CI pipeline.
Track lead time, not velocity. Measure the time from commit to production. This metric captures your entire value stream, including the hidden batches. Velocity metrics like PRs merged per week can increase while lead time stays flat, that's your signal that you're optimizing the wrong stage.
The bottleneck isn't where the work piles up. It's where the flow stops. AI has increased your flow at the beginning of your pipeline. Now you need to widen the constraint at the end.
