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.

What an LGTM should commit you to

(Our guide to what LGTM means covers the abbreviation itself, its origin, and its variants.) An LGTM should mean more than “I saw the diff.” A useful LGTM says: I understand the change, I checked the risky paths, and I am comfortable sharing ownership after merge. When teams use LGTM as a social shortcut instead, approval turns into a rubber stamp: fast, polite, and almost empty.

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 our 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.

Deadlines show the culture you actually have

Every team has two review processes: the one in the onboarding doc and the one that runs the week before a release. With slack in the schedule almost any process looks healthy. The bad week is the one your codebase lives under, and two things go first. Approvals speed up because reviewers stop reading. Then the re-review goes: the author pushes fixes after a round of comments, and the reviewer approves the notification instead of the new commits. Those commits were written in a hurry to satisfy feedback, so the riskiest code in the PR is the code nobody reads. Nobody decided to lower the bar. Each person made one reasonable trade, and together they added up to no review.

The norms that survive a crunch are the explicit ones you can measure. A review SLA is the main one. Google’s engineering practices tell reviewers to respond within one business day at the slowest. Once latency is a number the team can see, waiting for a real review stops being a reason to skip it, because the review reliably arrives tomorrow morning (our piece on review SLAs covers how to pick one). The same goes for comments. A labeled nit can be deferred honestly under pressure. An unlabeled one turns into an argument, and Conventional Comments exists to make that label explicit.

Leadership sets the ceiling

People follow the worst review behavior that goes visibly unpunished one level above them, not the documented standard. A staff engineer who merges a large change with “urgent, merging on green” teaches more in an afternoon than the wiki does in a year. It works the other way too. A tech lead who says “I haven’t reviewed this properly, give me until tomorrow” in a release week, on a feature the director is watching, gives everyone below them permission to be honest. If you lead a team, your review habits in the bad week are the policy, whatever the doc says. Teams with a good culture still cut corners under pressure. The difference is that they say so in the PR, and they go back afterward to review what they skipped.

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.