The zero-review merge is the only number that matters
Most review metrics can be satisfied without anybody reading anything. The rate at which changes reach production entirely unread cannot. It is the one figure I would put on a wall.
I have sat through a lot of engineering reviews where the quality slide is a set of green numbers that mean almost nothing. Review coverage: 98 percent. Median time to first review: four hours. Approvals per pull request: 2.1. Everything looks fine, and everyone in the room knows it does not feel fine.
My position is simple. Almost every review metric in common use can be satisfied without a human understanding a single line of the change. There is one that cannot, and it is the rate of changes merged with zero review. If you can only carry one number out of your review system, carry that one.
Why the other numbers survive collapse
Coverage counts the presence of an approval. An approval is one click. Under load, the click detaches from the reading, and coverage stays at 98 percent all the way down.
Time to first review counts the gap between opening and the first event on the pull request. A reviewer who opens the diff, scrolls, and approves in ninety seconds produces an excellent number. So does a reviewer who spent forty minutes. The metric cannot tell you which happened, and under volume pressure the ninety-second version becomes the norm precisely because the metric rewards it.
Approvals per change counts signatures. Diffusion of responsibility means the second signature is usually worth less than the first, not more, because each signer assumes the other looked.
Every one of these is a proxy for attention that keeps reporting green when attention has left the building. That is not a small flaw. It is the specific failure mode you need the dashboard to catch, and the dashboard is constitutionally unable to catch it.
The one that cannot be faked
A merge with no review at all is a different kind of event. There is no click to misinterpret, no duration to game, no signature to discount. Either a human was in the path or nobody was.
LinearB’s 2026 benchmarks put the change at roughly 31.3 percent growth in pull requests merged with zero review. That is the number I want in front of leadership, because it converts a vague organisational feeling into a fact with a direction. It also lands differently in a room than “review is under strain” does. Strain is negotiable. “A rising share of our production changes are reaching customers unread” is not.
Metrics that survive collapse
- Review coverage: counts clicks
- Time to first review: rewards speed
- Approvals per change: counts signatures
- Comment volume: counts typing
The metric that does not
- Zero-review merge rate
- Binary, not a proxy for attention
- Cannot be improved by skimming faster
- Rising means exactly what it says
The number is not supposed to be zero
Here is where I part company with the reflex. Most people who hear this argument decide the target is zero, announce a policy that nothing merges without review, and are worse off in a quarter.
A zero target does two things. It pushes the unreviewed merges into a category that looks reviewed, because now they need a signature and signatures are cheap. And it spends human attention uniformly across changes whose consequences are wildly different, which means the changes that could actually hurt you get the same three minutes as a dependency bump.
The right posture is that some non-zero rate is a deliberate policy. A documentation typo, a lockfile update, a generated client regenerated from a schema that did not change semantically: these should merge without a human, and saying so out loud is more honest than pretending a rubber stamp added something.
What makes the number valuable is not its level. It is the difference between the level you chose and the level you have. If you decided 15 percent of changes may merge unread, and you are at 34 percent, you have found something. If you never decided, you have found something worse.
What to do with it once you have it
Three things, in order.
Get it at all. Most teams cannot produce this number today. The tracker does not have it, the review tool reports approvals rather than absences, and the merges that skipped review often skipped it through an admin override or an automation account that nobody classifies as a merge path. The difficulty of extraction is itself the finding: a system that cannot tell you what merged unread cannot tell you anything about assurance.
Split it by blast radius. An aggregate rate is a comfort number. The question is not how many changes merged unread, it is which ones. Thirty percent unreviewed across the whole repository is unremarkable if it is all generated code and internal tooling, and alarming if four of them touched authentication.
Declare the intended rate, per path. Then the metric stops being a scold and becomes a control. Deviation is actionable. Compliance is evidence.
Where this breaks down
A single metric invites gaming, and this one is easy to game. Route the unreviewed merges through an automation account that self-approves and the rate drops to zero overnight while nothing changes. Any measure that becomes a target is subject to this, and I do not have a defence beyond insisting that whoever owns the number owns the definition of a merge path too.
Binary presence is a low bar. A change that was read for ninety seconds counts as reviewed and may be no safer than one that was not read at all. I am arguing this metric is the least corruptible, not that it is sufficient. It tells you about absence, not quality. Pair it with rework rate if you want a quality signal.
Some teams genuinely should be near zero, and the nuance is dangerous in their hands. A medical device firmware team does not want a policy conversation about acceptable unreviewed merges. If you are in a regulated context where every change carries an evidentiary obligation, “declare your intended rate” reads as permission to lower a bar you are not allowed to lower. Take the framing, not the tolerance.
It says nothing about the changes that never got made. A team drowning in review does not just merge things unread, it also stops proposing improvements that would need review. That suppression is invisible to this metric and may be the larger cost.
And a rising rate is not always decay. If you deliberately moved low-risk paths out of human review last quarter, the number should rise, and it rising is the intervention working. Without the declared baseline, you will read your own success as a failure.
The takeaway
Review metrics that count clicks, durations and signatures continue reporting health after human attention has withdrawn from the process entirely. That is not an implementation detail, it is what makes them useless in exactly the conditions where you need them.
The zero-review merge rate is the only common review figure that cannot be satisfied by a person who did not read the change. Its value is not in being low. It is in existing at all, being split by consequence, and being compared to a rate you chose on purpose.
If you take one thing into next week: try to produce your own zero-review merge rate for the last ninety days, broken down by whether the change touched an authentication, payment or data-deletion path. If you cannot get that in an afternoon, you have learnt more than the number would have told you.