LGTM culture: when code review becomes theatre

A 416-comment Hacker News thread titled “The Theatre of Pull Requests and Code Review” hit a nerve last year, and the nerve is real: on many teams, review has quietly become a ritual. The approval arrives in ninety seconds, or (the other face of the same problem) the reviewer feels obligated to find something and leaves three comments about naming. Both are performances. Neither is review.

Why rational people rubber-stamp

Nobody decides to stop reviewing. The drift has mechanics. By the time a PR is up, the author has invested days; the feature is on a board with a date; the change is, as one engineer put it in a long-running debate about post-commit review, already a done deal: the reviewer isn’t in the hot path of the decision anymore, so pushing back feels like obstruction rather than contribution. Add a diff too large to genuinely evaluate (we’ve written about why size kills review), and approval becomes the only move that doesn’t make you the bottleneck. The stamp is rational. That’s what makes it dangerous.

The obligation nitpick is the same failure

The reviewer who can’t evaluate the logic but must demonstrate diligence reaches for what’s evaluable at a glance: names, formatting, comment style. The author gets busywork, the actual risk sails through untouched, and everyone involved can point at the thread as proof review happened. As a commenter on the Theatre thread put it, logic-and-architecture comments are the valuable ones, but nit comments are easier to write, so they win by default. (We go deeper on this in an upcoming piece on nitpicks.)

What approval should mean

The fix starts with making the stakes explicit. An approval is a statement: “I understand this change well enough to co-own it in production.” Not “I looked at it,” not “I trust the author.” Teams that adopt that definition (out loud, in their review norms) make rubber-stamping feel like what it is: signing a document you didn’t read.

• Let reviewers say what they actually did. “Reviewed the migration deeply, skimmed the call sites” is honest and useful; silent approval hides the gap.
• Make small PRs the norm so genuine evaluation is possible in the time people actually have. Theatre thrives on impossibility.
• Move review earlier. Feedback before the change is “a done deal” (on the design, or via pre-PR review of generated code) puts the reviewer back in the hot path, where pushing back is cheap.
• Kill the diligence-signaling channel. Auto-format, lint in CI, and label nits as non-blocking. When style can’t be the performance, attention goes to logic.

The surface matters more than teams admit

Here’s the uncomfortable observation from building a review tool: a lot of rubber-stamping is fatigue with the act of reviewing, not indifference to quality. When finding the three files that matter takes ten minutes of scrolling, the stamp wins. When triage is instant and the diff keeps your place, genuinely reading the change stops being heroic. That’s the bet behind Pyor (ours, free for individuals): make real review cheap enough that theatre loses its main excuse.