The AI Code Review Bottleneck: Why Faster Code Is Not Faster Delivery

The AI code review bottleneck is the point where faster code generation meets a review queue that has not grown. When authors produce more code, delivery speeds up only if reviewers can absorb it, and Emma Bostian argues in a recent article that in many teams they cannot.

Bostian argues the constraint has moved from writing code to reviewing it

Bostian’s claim is that AI makes writing code faster, and that the cost lands on code review. When a team mandates AI use, she argues, it adds code without adding value, and reviewers carry the strain. She names three risks that reach review: security vulnerabilities, codebase bloat, and edge-case bugs. She summarizes the pattern as "Fast code, slow reviews."

Her remedy is to keep authors responsible for what they submit. She recommends that authors understand and test AI-generated work before asking for review, that teams define entry criteria for review, and that they measure review time, rework, and maintainability alongside output. She also cites Harvard Business Review research on "workslop" to show what polished but hollow work costs the colleague who receives it.

A review queue slows down whenever changes arrive faster than reviewers can clear them

A review queue has an arrival rate, which is how many changes authors submit, and a service rate, which is how many reviewers can finish. If AI raises the arrival rate and the service rate stays where it was, the wait for each change grows. That is arithmetic, and it holds whether or not any individual change is poor. A team can see its commit count rise, its author satisfaction rise, and its time to production stay flat or worsen, because the extra time is spent waiting in a queue that dashboards of output do not show.

This is why Bostian’s advice to measure the whole delivery system matters. Output counts the left side of the queue. Delivery is the right side, and it only moves as fast as the slowest stage.

DORA’s research points to the same pattern across whole organizations

The DevOps Research and Assessment program at Google Cloud reports on this at a larger scale. Its 2024 report page states that AI adoption "negatively impacts software delivery stability and throughput" and that fundamentals such as small batch sizes and robust testing remain crucial. Its 2025 report page describes AI’s primary role as an amplifier that magnifies an organization’s existing strengths and weaknesses. I read the two together as consistent with Bostian’s argument: a team with a thin review process gets a thinner process at higher volume. The DORA pages I read do not attribute the 2024 finding to code review specifically, so that link is my inference and not a finding of the report.

Review itself is a long-studied practice. A 2018 study by Sadowski and colleagues, Modern Code Review: A Case Study at Google, analyzed review logs for 9 million reviewed changes alongside interviews and a survey, which shows how much institutional weight review carries at scale. A practice that central cannot absorb unlimited volume without a change in how work arrives.

Entry criteria work when the author has to show evidence before a reviewer reads a line

Bostian suggests entry criteria such as the author being able to explain the change, tests passing, and security and privacy concerns being met. I would add two mechanics that make them bite. First, the author attaches the evidence to the change: a plain-language account of what changed and why, the tests that ran, and the security and privacy checks that apply. Second, the reviewer is allowed to return a change at the door without reading the code when that evidence is missing. This moves the cost of an incomplete change back to the person who created it, which is where Bostian says accountability belongs.

Three measurements show whether the gate is working: how long changes wait before a first review, how often changes are returned at entry, and how much rework follows a merge. A rising return rate at entry with falling rework later means the gate is moving effort to the author at a profit. A rising return rate with no change in rework suggests the criteria are checking the wrong things.

The boundary conditions are real. Any gate adds friction, and a team under deadline pressure may start approving criteria without checking them. Any metric can be gamed once it is tied to performance, so these three numbers should inform a team’s own retrospectives and stay out of individual evaluation. An author can paste an AI-written explanation they do not understand, so the explanation requirement works best when a reviewer can ask one follow-up question in conversation. On a very small team, the author and reviewer may be the same two people, and a gate adds little. There is also a counter-case I cannot resolve: AI-assisted review tools may raise reviewer capacity enough to close the gap. I have not found a primary study that measures this, so I treat it as an open question and not as a settled remedy.

Why This Matters for Engineering Leadership

Leaders who mandate or celebrate AI usage are pushing the arrival rate of the review queue up, whether they intend to or not. The decision they own is the service rate and the quality of what arrives. From an AI governance view, a review is the point where an organization says a named person understood and accepted a change. If that point becomes a rubber stamp under volume, accountability for production code has no owner. Leaders can protect it with a short list of entry criteria, a visible queue metric, and a clear statement that authors own what they submit.

FAQ