Rubber-Stamp Reviews: Spotting Approval Theater

TL;DR: A rubber-stamp review is an approval nobody read their way to, and it's worse than no review, because it launders unread code as reviewed. Your speed metrics can't see it; they reward it. The tell is in reading-rate math (Cisco's data shows defect detection collapses above ~500 LOC/hour) and in approvals that never carry a single comment. The fix isn't shaming the fast approver; it's fixing the system that made stamping rational: oversized PRs, overloaded reviewers, and a required-review rule treated as a compliance checkbox.

Your branch protection says every PR needs an approval. Every PR gets one. Review coverage reads 100%, pickup time looks great, and the dashboard is a sea of green. And some meaningful share of those approvals took ninety seconds on an 800-line diff, carried zero comments, and checked precisely nothing. That's approval theater: the process ran, the review didn't. Here's how to see it in your own data, and why the person clicking approve is almost never the actual problem.

What is a rubber-stamp review?

An approval given to unblock a merge rather than to check a change. The reviewer may have skimmed the diff, opened it and scrolled, or not opened it at all. The defining feature is that the approval doesn't represent reading.

Understand what that costs by remembering what review actually delivers. It's not primarily bug-catching: Mäntylä and Lassenius found 75% of defects caught in review are evolvability defects (clarity, structure, maintainability), and Microsoft's research found the measured outcomes of review lean toward knowledge transfer and team awareness, not defect counts. A rubber stamp skips all of it: nobody checked the structure, and - the quiet, compounding cost - nobody learned the code. The change ships with a bus factor of one and a certificate saying otherwise.

That certificate is why a rubber stamp beats an honest self-merge to the bottom. A self-merge is at least visible in the data as unreviewed code. A stamped PR is unreviewed code wearing a reviewed badge. It poisons the one metric that was supposed to catch it.

Spotting approval theater in PR data

Three signals, strongest in combination:

1. Reading-rate math. Lines changed ÷ time-to-approve. The Cisco study behind SmartBear's guidelines found defect detection drops sharply above ~500 LOC per hour of review, and that reviews done well catch 70-90% of defects. A 900-line PR approved eleven minutes after opening is a 4,900-LOC/hour "review." Whatever happened there, it wasn't inspection.
2. The comment-free approval streak. Any single silent approval is fine. Dozens of consecutive approvals on substantive changes with no comment, no question, no suggestion means the review conversation has flatlined. Healthy review produces feedback; theater produces ticks.
3. Speed invariant to size. The honest version of fast review exists: at Google, small changes get first feedback in under an hour, and a median of one approver reviews essentially every change. Fast on small is the system working. Fast regardless of size is the tell: when the 30-line fix and the 1,200-line refactor both clear in five minutes, the reviewer's calendar decided the outcome, not the diff.

Track these alongside your existing review metrics, or the speed numbers will happily improve while the reading disappears, a textbook case of a metric getting gamed by the system it's supposed to measure.

Why do reviews get rubber-stamped?

Roast the system, because the system built this. Nobody joins a team planning to approve code unread. They arrive there down one of four ramps:

• The PRs are unreviewable. Past a certain size, skimming is the only physically available option: the same Cisco research caps effective review at 200-400 lines at a time. A team that routinely ships giant PRs has already chosen rubber stamps; it just hasn't admitted it.
• One reviewer carries the queue. When most reviews route to one senior - the classic review-load concentration - their honest options are "become the bottleneck" or "stamp and survive." They're not the villain; they're the overloaded component. The always-instant approver in your data is a load symptom.
• Review is nobody's scheduled work. If review time isn't budgeted, it happens in the gaps, and gaps produce gap-quality reading. Reviews done between meetings get meeting-remnant attention.
• The rule became a checkbox. Required-review settings without a shared belief in the practice produce compliance, and compliance's whole skill set is minimizing effort per checkbox. That belief gap is a culture problem, and no branch-protection setting fixes culture.

The fix, without a witch hunt

The door, in four moves:

1. Make depth visible next to speed. Put comment rate and reading-rate outliers on the same dashboard as pickup time. What gets measured alone gets gamed; what gets measured in tension stays honest.
2. Shrink the PRs. Small changes are the single highest-leverage fix: the precondition for real reading, and what makes honest fast approvals possible. Small PRs turn the rubber stamp's best excuse into no excuse.
3. Spread the load. If one person's approval latency is your whole review story, rebalance before you critique. A rebalanced review rotation gives every reviewer the slack to actually read - especially on a small team, where one overloaded reviewer is the entire safety net.
4. Legalize the honest fast lane. Some changes deserve a thirty-second approval: lockfile bumps, generated code, one-line reverts. Define that class explicitly. When trivial changes have a sanctioned fast path, a fast approval on everything else goes back to meaning something.

The point was never slow ceremony. It's that an approval is a signature: it should mean a second person read this and stands behind it. Restore that meaning, and every green tick on your board goes back to being what your dashboard already claims it is - evidence.