A rubber stamp code review is an approval granted without genuine evaluation. The reviewer clicks approve without reading the change carefully enough to catch a real problem. The ritual of review happens; the substance does not.
Why capable reviewers rubber stamp
The lazy-reviewer explanation is comforting and wrong. Most rubber stamps are issued by conscientious engineers responding sensibly to a broken situation. SmartBear’s analysis of peer review found that defect detection drops sharply once a review passes roughly 400 lines of code, and that reviewers should move no faster than about 500 lines per hour. Do the arithmetic on a 2,500-line pull request and an honest read costs most of a workday. The reviewer’s calendar does not contain a spare workday. Approving is the only available move that unblocks a teammate, so they take it.
The second force is social. Blocking a change feels confrontational, especially when the author is senior or the deadline is close, and a culture that treats approval as the default turns review into a performance rather than a practice. The third force is incentive: review effort is invisible in most performance conversations, so the rational allocation of a scarce hour goes to work that is seen. None of these people decided to stop reviewing. The system decided for them.
How to detect a rubber stamp code review
The single most useful signal is approval latency measured against diff size. A 3,000-line change approved four minutes after the request was not read; at any credible reading pace that diff needs hours. The second signal is comment density: one review with zero comments means nothing, but a reviewer or a team that produces zero comments across many non-trivial diffs is not evaluating them. Both signals belong in your review metrics as distributions, not as per-person scorecards. The goal is finding a sick process, not shaming an individual.
One caution before you point the detector at anyone: fast approval of a small change is healthy, not suspicious. Google’s study of its Critique review system found that changes there are typically small and reviewed quickly, usually by a single reviewer. Speed only indicts a review when the size of the diff makes the speed impossible. Judge the pair, never the number alone.
Fixes that address causes, not symptoms
Telling people to review harder fails, because effort was never the constraint. The fixes that work remove the conditions that make stamping rational:
- Shrink the unit of review. A change that fits inside one honest sitting gets a real read, because a real read is finally affordable. This is the highest leverage fix and the least glamorous.
- Tier the rigor explicitly. A dependency bump, a copy change, and a payment-path modification do not deserve identical scrutiny. When the team declares lighter tiers openly, low-risk changes get fast approvals that are honest instead of fake, and attention concentrates where mistakes are expensive.
- Normalize honest review statements. An approval that says "reviewed the API surface and error handling, did not run it locally" tells the team exactly what safety net exists. A bare green check pretends to a coverage it may not have. Partial review stated plainly beats total review performed falsely.
A rubber stamp is not a character flaw. It is a signed confession that the review system asked for more attention than anyone had, and the process paid the debt with fiction. Make honest review affordable, and people buy it.
Frequently asked questions
What does rubber stamping mean in code review?
Rubber stamping means approving a pull request without evaluating it enough to catch a real defect. The approval is genuine in the tooling and hollow in substance. It usually shows up as near-instant approvals on large diffs, zero comments on changes that plainly warranted discussion, and reviewers who could not summarize what a change does moments after approving it.
Is rubber stamping always bad?
The speed is not the problem; the dishonesty is. A quick approval on a trivial, low-risk change is proportionate review. The damage comes when a shallow glance gets recorded as a thorough evaluation, because the team then believes a safety check happened that did not. Explicit tiers and honest review statements keep fast approvals from becoming fake ones.
How do I stop my team from rubber stamping reviews?
Attack causes, not reviewers. Cap change size so a real read fits in one sitting, define review tiers so low-risk changes get legitimately lighter treatment, and normalize partial statements like "reviewed the API surface, did not run it". Then track approval latency against diff size at the team level to see whether the pattern is actually improving.
