Rubber-Stamp Code Reviews
Rubber-stamp reviews approve pull requests without real inspection, performing the ceremony of code review while giving none of its value. They let defects through under a false quality signal. Fix it with small PRs, checklists, and a genuine review culture.
What It Is
A rubber-stamp review is a code review in name only. A reviewer approves a pull request — often within seconds, often with a bare "LGTM" — without actually reading or understanding the change. The team performs the ritual of review and records the approval, but none of the benefits of review actually occur: defects go uncaught, design goes unchallenged, and knowledge goes unshared.
It is arguably worse than having no review at all, because it produces a false signal of quality that the team trusts.
Why It Happens
- Time pressure. Reviewers are busy and approving quickly clears their queue.
- Oversized diffs. A 2,000-line pull request is impossible to review meaningfully, so reviewers give up and approve.
- Social dynamics. Pushing back feels confrontational, especially on a senior author's code.
- Process box-ticking. Review exists to satisfy a policy, not because the team values it.
Why It Hurts
Defects, security flaws, and design problems pass straight through the one gate meant to catch them, then reach production. The approval creates a false quality signal: the team believes the code was vetted when it was not. The knowledge-sharing and mentorship that good review provides never happen. Over time, authors stop expecting useful feedback and reviewers stop giving it, and the practice becomes pure theater.
Warning Signs
- Approvals arrive within seconds of a pull request opening.
- Large diffs are routinely approved with no comments.
- Reviews almost never produce questions, suggestions, or change requests.
- Approval is treated as a formality to unblock merging.
Better Alternatives
- Small pull requests. Keep changes small enough to review thoroughly; large diffs guarantee rubber-stamping.
- Review checklists. Give reviewers concrete things to verify so review is more than a glance.
- Pair programming. For complex work, review continuously while building instead of after.
- A genuine review culture. Set the expectation that thoughtful feedback is valued, not friction.
How to Refactor Out of It
Start by shrinking pull requests; small, focused changes make real review feasible. Provide a lightweight checklist covering correctness, tests, security, and clarity so reviewers know what to look for. Set explicit norms that an approval means "I understood and vetted this," and that asking questions is welcome, not hostile. Track review quality, not just speed — a queue cleared in seconds is a warning, not a win. For the riskiest changes, prefer pairing or multiple reviewers. The goal is to restore the substance behind the ceremony.