Review anti-patterns and scaling review across an org

At a company that had grown from 30 to 200 engineers, one staff engineer owned the payments service in CODEOWNERS, so every PR touching it required his approval. He had 40-odd reviews queued daily; the team learned that the way to ship was to make him comfortable, so they kept diffs small and boring — and he, drowning, started skimming and stamping. A migration that changed the settlement currency rounding slipped through with a “LGTM, nice tests.” The tests were nice. They asserted the old behavior. Two days later finance flagged a six-figure discrepancy across one settlement batch. The review process hadn’t failed because the reviewer was bad — it failed because one human had been made the wall the whole org queued behind, and a wall under that much load stops reading.

The anti-patterns are all the same failure: review stops being about design

This arc has built one claim across four lessons: review exists for the undecidable — design, intent, correctness, knowledge transfer — and everything mechanical belongs in a gate. Every anti-pattern is a way that claim quietly inverts. Rubber-stamping — “LGTM” in eleven seconds without reading — is review-as-ritual, and it correlates directly with the large PRs from the size lesson: a 1,600-line diff exceeds working memory, so the only honest options are a free 90-minute block nobody has or a stamp, and under deadline the stamp wins. Bikeshedding (Parkinson’s law of triviality: people argue hardest about the bike-shed color because everyone has an opinion on paint, nobody on the reactor) is the opposite surface, same rot: ten comments about naming and import order while the design sails through unexamined — which is exactly the class the previous lesson said to automate away, freeing the human for the reactor instead of the shed.

Then the people-shaped ones. Power-tripping / non-actionable feedback — “this whole approach is wrong” with no alternative, or comments that score points rather than improve code — ties straight back to the giving-review lesson: a comment that states neither its severity nor its fix is a guess the author must decode, and a reviewer who uses review to assert dominance teaches everyone to ship to the reviewer’s taste rather than to the system’s needs. Underneath all of them sits the deepest one: review-as-gatekeeping versus review-as-knowledge-sharing. If review’s purpose is “a senior decides who’s allowed to merge,” it concentrates power, breeds the bottleneck, and makes every comment a verdict. If its purpose is “two engineers build shared understanding of this change,” it distributes knowledge, grows reviewers, and makes comments collaborative. Same activity, opposite cultures — and the gatekeeping framing is what produces almost every other anti-pattern.

Scaling: route, time-box, balance — don’t add a gate, add throughput

A practice that works at 20 engineers breaks at 200 not because people get worse but because the queue changes shape. The first lever is routing: CODEOWNERS (or equivalent) maps paths to the people who actually own them, so a PR is auto-assigned to a competent reviewer instead of waiting for someone to notice it. The trap inside routing is the one in the Hook — make a single person own a hot path and you’ve built a bottleneck by construction. The fix is to spread ownership: list a team, not a person; use round-robin or load-balanced assignment so the same staff engineer doesn’t accumulate 40 reviews a day while juniors who could handle the routine 80% sit idle and never grow into reviewers. Most day-to-day PRs — bug fixes, features inside established patterns, test additions — need a competent reviewer, not the senior; reserve the bottleneck-prone expert for the architecturally significant and security-sensitive minority, and pair a junior with them on those so review skill propagates instead of concentrating.

The second lever is time-boxing pickup. Google’s guidance is to respond to a review within one business day, and the size lesson showed why the response, not the reviewing, is the dominant cost: a PR in review is blocked work. An SLA on first response (say, within 4 hours during local hours) plus a review-buddy rotation that guarantees someone is watching the queue keeps pickup latency bounded — but note the sharp edge: an SLA on completion of a large diff just pressures the reviewer to skim, trading the latency win for a rubber stamp. SLAs work on pickup, not on quality. Make load visible — a dashboard of who has how many pending reviews — and the org can rebalance before anyone drowns, which is the cheap prevention for the Hook’s failure.

When async review isn’t the right shape at all: pairing and post-commit

For some work the right move isn’t a faster async review — it’s a different shape of review. Pair or mob programming is continuous review with zero async latency: the navigator reviews each line as it’s typed, so there’s no PR to queue, no pickup wait, and feedback bandwidth is orders of magnitude higher than comments left hours later. It’s the strongest substitute for review on genuinely hard or high-risk work — gnarly design, a critical migration, onboarding someone into a complex subsystem — because the design conversation happens before the code exists rather than after. The cost is two people’s time on one task and that it’s exhausting to sustain all day, so teams pair on the hard 20% and async-review the routine rest; pairing also doesn’t auto-produce the written audit trail an async PR leaves, which some compliance regimes require.

Post-commit (ship-then-review) review removes pickup latency from the merge path entirely: the author merges to trunk and reviewers comment afterward, with concerns addressed in follow-ups. This trades pre-merge gating for velocity, and it is only safe on a high-trust base with a strong automated floor — exhaustive CI, good tests, fast rollback, feature flags. The reason it can work is that the gate that actually protects trunk in a mature trunk-based shop is the test suite, not the human; Facebook’s predictive test selection, for instance, catches over 99.9% of regressions while running a third of the tests, which is the kind of automated confidence that makes post-commit review a reasonable risk for low-stakes changes among trusted committers. It is not a license to skip thinking — it relocates the human review to after a machine-verified merge, and it is the wrong default for security-sensitive code, untrusted contributors, or any change the test suite can’t meaningfully cover. Choose the shape by stakes and trust, not by habit.