The rubber stamp leaves no artifact
A careful forty-minute review and a ninety-second scroll produce identical records in your system. No amount of analysis of approval data can separate them, which means the fix is not another metric. It is changing what a review emits.
Two reviews happened last Tuesday. In the first, someone spent forty minutes on a change to the payment retry logic, traced two call paths, checked the behaviour against the acceptance criteria, and satisfied themselves it was right. In the second, someone opened a 600-line diff, scrolled to the bottom, and approved it.
Your system of record contains the same thing for both: an approval, an identity, a timestamp.
My position: this is the central problem with review as a control, it is not a measurement problem, and every attempt to solve it by analysing approval data is doomed by construction. If the two cases are byte-identical in your data, no statistic computed over that data can distinguish them. The only move available is to change what a review emits.
Why the metrics cannot rescue this
Teams reach for proxies, and each proxy fails in the same way.
Time between opening and approving looks promising until you notice a tab left open during lunch produces an excellent number and a fast, genuinely competent read produces a poor one. It measures elapsed time, not attention, and once anyone knows it is measured it measures patience.
Approvals per change counts signatures. Two signatures on a large diff are usually worth less than one, because each signer assumes the other looked properly.
Review coverage counts the presence of an approval, which is one click.
The rate of merges with zero review is the one metric in this family that genuinely cannot be satisfied without something happening, and it deserves its reputation. But notice what it is: a floor. It tells you about the changes where nobody even clicked. Everything above that floor, which is the large majority of your changes, is exactly where the two Tuesday reviews are indistinguishable.
What an approval records
- That a click occurred
- Which account clicked
- When
- Nothing about what was understood
- Identical for both Tuesday reviews
What only reading can produce
- A question about a specific behaviour in this change
- A named case the change does not handle
- A verdict against a stated criterion, with the reason
- A test that fails before the change and passes after
- Impossible to generate from the diff without looking at it
Volume did not create this, it removed the cover
None of this is new. Reviewer effectiveness has always collapsed past a few hundred lines, most defects found in review have always been found early, and a good share of approvals on large diffs have always been rubber stamps. The industry has known this for years and kept the ritual, because at low volume the ritual was cheap and the alternative was unclear.
What changed is the ratio. LinearB’s 2026 benchmarks put agentic pull requests at 5.3 times longer pickup time, median review duration up 441.5 percent, and merges with zero review up 31.3 percent. Under that load the gap between “we review every change” and what happens on a Thursday afternoon gets too wide to keep a straight face about.
There is a second-order effect that makes it worse, and it is the one that changes how I think about the fix. Trust in AI output fell from around 40 percent to 29 percent in the 2025 Stack Overflow survey. Reviewers are more sceptical than they were and are approving more changes than they were, which means the approval is drifting from an expression of confidence to an expression of throughput. A signal that no longer tracks belief is not a weak signal, it is a different signal wearing the same name.
Make review emit something
The fix is unglamorous. Require every review of a change in your top risk classes to produce an artifact that reading produces and clicking does not.
Four things qualify, and they are not equally good.
That last item deserves the emphasis. Under volume, partial review is the realistic outcome and pretending otherwise is how gates rot. A reviewer who states the boundary of what they read has given you something genuinely valuable: the unreviewed portion of a change becomes visible rather than assumed away, and it can be routed to somebody else or accepted deliberately.
Two things this must not become
It must not become a comment quota. Requiring a comment per review produces comments about formatting, and now the noise is in the record too. What you want is the artifact on the small number of change classes where it is worth the cost, not everywhere.
And it must not become an approval theatre with more steps. If a reviewer can satisfy the requirement by pasting a generic sentence, you have added friction and gained nothing. The test for any artifact you require is the one from the figure: could this have been produced without opening the diff? If yes, it is a click with extra typing.
Where this breaks down
Artifacts can be faked, and generation makes faking easy. A model can read a diff and produce a plausible, specific-sounding question about it in seconds. Everything in my right-hand column that used to be forgeable only with effort is now forgeable cheaply, which is a serious hole in the position and I do not have a clean patch for it.
Rubber stamps are sometimes correct. A reviewer who knows the author, knows the area, and skims a change they can predict is often making an efficient and accurate judgement. Treating every fast approval as a failure would slow down a large amount of review that is working fine.
The requirement will make reviewers avoid the risky changes. If deep review carries a documentation burden and shallow review does not, a rational reviewer under load picks up the changes that carry the lighter obligation. I may be adding a tax to exactly the reviews I want more of.
Zero-review rate may be enough. The counter-argument is that the floor is the only thing worth policing, that everything above it is unmeasurable in principle, and that adding requirements is process for its own sake. I think the artifact requirement changes what is possible rather than merely what is measured, but that is a claim about incentives, and I have not tested it.
And this puts more in the record about individuals. A named verdict, attributable, retained. That is exactly what you want for governance and it changes how it feels to review, particularly for people earlier in their careers. It should be introduced as evidence of the work, never as a performance signal, and if it is used as the second thing it will produce careful, defensive, useless artifacts.
The takeaway
Review is failing as a control because the record it produces is identical whether or not anyone read anything, and no analysis of that record can recover the difference.
Stop trying to measure approvals harder. On the small set of changes where being wrong is expensive, require review to emit something a click cannot produce: a verdict against a criterion, a specific question, a test, or an honest statement of what went unread.
If you take one thing into next week: introduce the boundary statement. One line per review naming what was and was not looked at. It costs nothing, it is the only honest thing a reviewer can say under load, and it converts your largest silent risk into a visible one.