Review latency improved while review got worse

Somebody in your organisation has a slide showing average time to merge coming down. It is presented as an efficiency win, and it usually arrives in the same quarter that senior engineers start saying, in less formal settings, that they no longer know what is in the codebase.

Both things can be true at once, and the arithmetic that makes them true is worth understanding, because it is the most common way a review dashboard lies to a leadership team.

My position: for any team where the share of unreviewed merges is rising, average review time is not a performance metric. It is a composition metric, and it improves fastest when review is disappearing.

The two populations

Every merged change falls into one of two groups. Someone read it, or nobody did.

The first group has a review duration. The second group has a review duration of zero, or near enough, because there was no review to time.

Your average is a weighted blend of the two. That means it can fall for two completely different reasons: reviewed changes got faster, or the unreviewed share got bigger. The metric cannot distinguish them, and only one of those is good news.

LinearB’s 2026 benchmarks describe both movements happening at once across the industry. Median review duration is up 441.5 percent. Pickup time on agentic pull requests is 5.3 times longer. And pull requests merged with zero review are up 31.3 percent.

Read those together. The population that still gets reviewed is getting dramatically slower, because the changes are larger, generated, and harder to reconstruct. The population that skips review entirely is growing. On any given team’s dashboard, those two movements net out, and where the skipped share grows fast enough, the blended number goes down while the reviewed changes are taking five times as long as they used to.

Last year
  100 merges, 90 reviewed at 4h, 10 unreviewed
  average review time = (90 x 4) / 100 = 3.6h
This year
200 merges, 100 reviewed at 6h, 100 unreviewed
average review time = (100 x 6) / 200 = 3.0h
Headline: average review time down 17%.
Reality:  reviewed changes 50% slower,
unreviewed share up from 10% to 50%.

Why nobody catches it

Three reasons, and they compound.

The metric was designed under an assumption that no longer holds. Time to merge became a standard measure when essentially everything got reviewed, so the unreviewed population was small enough to ignore. Nobody chose to include a zero-heavy population in the average; it grew into the metric while the definition stayed the same.

The direction is the one everyone wants. A number going the right way does not get audited. If average review time had gone up 17 percent, someone would have spent an afternoon on it by Thursday.

And the counter-evidence is qualitative. What senior engineers have is a feeling that they no longer recognise the codebase, and a feeling loses to a chart in every meeting I have ever sat in, regardless of which one is right.

Splitting it changes what you argue about

Once you separate the populations, the conversation changes shape immediately, and in a way that is more useful than it is comfortable.

If reviewed changes are getting slower, that is a capacity and comprehension problem, and it has known responses: smaller changes, better descriptions of intent, routing to people with actual context, and accepting that a generated 900-line diff is not a unit of work a human can absorb.

If the unreviewed share is growing, that is a risk decision your organisation is making implicitly, hundreds of times a week, with nobody’s name on it. It might even be the right decision for low-blast-radius areas. But it should be a decision, with a ceiling, per subsystem, set by someone who would be accountable if it went wrong.

The blended number lets you avoid both conversations. That is its main function, and I do not think that is entirely accidental.

Where this breaks down

Some unreviewed merges are correct, and treating the share as pure risk is wrong. A config bump, a generated migration with an automated check, a documentation change: forcing human review on these wastes attention that should go to the payments module. If your unreviewed share is growing because you got better at classifying low-risk changes, that is a genuine improvement and my framing would call it a decline.

Averages have always mixed populations, so this is not new. The composition effect applies to cycle time, lead time and most of the DORA measures too, and it applied before agents arrived. I am claiming the effect got large, not that it is novel, and someone who has been making this point about delivery metrics for a decade is entitled to be unimpressed.

The strongest objection: maybe review was never the control you think it was. There is a real argument that human review catches far less than we assume, that most defects are caught by tests, staging and production monitoring, and that a falling review rate is the system correctly reallocating a low-yield activity. If that is true, then splitting the metric produces an alarming chart about something that does not matter much. I do not believe it, but the evidence for review’s defect-catching power is thinner than its cultural status implies, and anyone arguing my side should know that.

Trust data is not the same as a quality measurement. Developer trust in AI output fell from around 40 percent to 29 percent in Stack Overflow’s 2025 survey, and it is tempting to reach for that as corroboration. It is not: it measures sentiment, not defects. Reaching for it would be exactly the move I am criticising, which is letting a number that points the way you already believe stand in for the one you actually need.

And splitting the metric changes nothing on its own. A better chart is not a control. If the unreviewed share turns out to be 40 percent and nobody sets a ceiling, you have replaced a comfortable number with an uncomfortable one and shipped the same code. Measurement is the cheap half of this.

The takeaway

Average review time blends a population that is getting slower with a population that contributes a zero, and the second one is growing. A downward trend in that average is at least as likely to be review disappearing as review improving, and the metric is structurally incapable of telling you which.

Report the two populations separately, always. Reviewed duration for reviewed changes. Share of merges with no human review, broken down by subsystem, so the risk lands somewhere specific.

If you take one thing into next week: take your review-time chart and recompute it excluding every merge with no human review event. If the two lines diverge, you have been reading a composition effect as a performance improvement, and now you know which conversation to have.