The Bottleneck Moved to Code Review. Your Metrics Didn't.

Why is my team shipping more code and finishing less work?

Because the work did not disappear. It moved downstream and stopped being counted.

Under high AI adoption, Faros measured the median time a pull request spends in review up 441.5%, average pull request size up 51.3%, and files edited per pull request up 59.7%.¹ More code arrives, in bigger pieces, at the same number of reviewers. The queue is the new constraint, and a queue is invisible to any metric that only counts what came out of it.

The uncomfortable part is that this looks like success from the top. Commits rise. Pull requests merged rise. An engineering leader reading an activity dashboard sees a team accelerating, right up until delivery stalls and nobody can say where.

What actually happens to a pull request under heavy AI use?

Four things, in order, and each one makes the next worse.

It gets bigger. Average pull request size up 51.3%, files touched up 59.7%. A reviewer is no longer reading a change; they are auditing a diff.

It waits longer. Median time in review up 441.5%. Average time in review up 199.6%. Median time to a first review up 156.6%.¹ The wait is not the read. Most of that number is a pull request sitting untouched.

It costs more to review. Review comments per pull request up 25%, and average comment length up 22.7%.¹ Reviewers are not skimming these. They are working harder per pull request, on more pull requests.

So some of it stops being reviewed. Pull requests merged with no review at all, human or agentic, up 31.3%.¹ That is not a policy decision anyone made. It is what a queue does when arrival rate exceeds service rate.

And the code arriving is not neutral. CodeRabbit's analysis of 470 open-source pull requests found AI-generated code produced 1.7x more issues than human-written code, with logic and correctness errors up 75%.² These are the failure modes that survive a fast read and die in production.

Why don't DORA's four keys catch this?

They do catch it. They just cannot locate it.

Lead time for changes includes review wait, so a review queue backing up will show up as lead time rising. That is the four keys working correctly. The problem is what happens next: you know the system got slower, and you have no idea which part.

The four keys are outcome metrics. They are deliberately few, deliberately end-to-end, and that is their strength — they resist gaming in a way component metrics do not. But an outcome metric tells you the patient has a fever. It does not tell you where the infection is.

Worse, two of the four can look healthier while this is happening. Deployment frequency can rise on the back of all that extra merged code. Change failure rate is a ratio, so a flood of small safe changes can mask a rising absolute number of incidents. A team can post improving numbers on half the four keys while its review queue quietly becomes the most expensive thing it owns.

What should you measure instead?

Four intermediate signals. None of them are new; what changed is that they stopped being secondary.

Pull request size. The single best leading indicator, because it drives everything downstream: review time, review quality, and the odds of a merge-without-review. Track the distribution, not the mean. A 4,000-line pull request is not four 1,000-line pull requests.

Review wait time, separated from review duration. These are different failures with different fixes. Long wait means you have a reviewer capacity or routing problem. Long duration means the changes are too big or too unfamiliar. A single "review time" number blends them and points nowhere.

Work in progress. Faros measured the average time a task spends in progress up 225.2%.¹ Rising WIP is the queue made visible: the same backlog, counted at the other end.

Bugs per pull request, not bugs per developer. Faros measured bugs per pull request up 54%.¹ Per-developer normalisation hides the mechanism, because the developer count did not change — the pull request count did.

What ties these together: every one of them is a measure of flow, not of output. Output went up. That was never the question.

Is the answer to review less?

No, and this is where the argument usually goes wrong.

The reflex is to reduce review: auto-approve small changes, trust the model, add an AI reviewer and move on. Faros measured AI-reviewed pull requests at 25% in 2026, up from effectively zero in 2025.¹ That may well be part of the answer, but note what it does to your measurement: an AI review clears the queue without clearing the risk, and it makes "reviewed" a much weaker word than it was last year.

The other reflex is to slow generation down, which no one will actually do.

The useful move is narrower: make the units smaller. Almost every number in this post is downstream of pull request size. Smaller changes wait less, review faster, hide fewer logic errors, and fail less expensively when they do fail. That is not a new insight. It is the oldest advice in code review. But it was a preference before and it is a constraint now.

Frequently Asked Questions

Is this an argument against using AI to write code?

No. The throughput gain is real and measurable. The argument is that throughput was never the number that mattered, and that measuring only the part that got faster will lead you to invest in making it faster still.

Our lead time looks fine. Are we safe?

Possibly, but check whether your merged-without-review rate has moved. A flat lead time with a rising unreviewed-merge rate means the queue is clearing by skipping the step, not by keeping up.

Do we need new tooling to measure this?

Not necessarily. Pull request size, review wait, and bug counts are all available from your source control provider. The gap is usually not data collection — it is that nobody is looking at these next to each other, over time, per team.

How is this different from DORA?

It is not a replacement. The four keys tell you whether delivery is healthy. These signals tell you where it stopped being healthy. Use both; they answer different questions.

What is the first thing to look at on Monday?

The distribution of pull request size over the last quarter, split before and after your AI adoption inflected. If the tail got heavier, everything in this post applies to you.

Sources