MJD argues bluntly that reviews aren't primarily a bug-detection mechanism, gatekeeping ritual, or compliance checkbox. Their real function is to ensure the code isn't understood by only one person — if the reviewer can't confidently modify the code afterward, the review failed regardless of nits left.
Frames MJD's post as landing hard because of timing — it followed a week of discourse about AI-generated PRs where reviewers admit skimming diffs they don't understand because 'the tests pass.' Argues the bug-detection framing produces perverse incentives: shallow nit-hunting, rubber-stamped architectural PRs, and the death of review-as-mentorship.
Engineers at companies where review is enforced as a quality gate pushed back, insisting bug-detection is a genuine and measurable output of the process. They argue that defects surfaced in review are a concrete metric leadership can and should track, and that treating review as purely a knowledge-transfer exercise underweights its role in preventing production incidents.
Engineers whose teams have functioning review cultures described the process exactly the way MJD does — as the primary mechanism by which a codebase stops being one person's private garden. They emphasized the corollary that most style guides skip: a review where the reviewer still couldn't modify the code themselves is a failed review, no matter how thorough the nit-picking.
Mark Jason Dominus — the Perl-book author better known online as mjd — posted a short piece on Mathstodon that hit 204 on Hacker News: many people misunderstand the purpose of code review. The claim is deliberately blunt. Reviews aren't primarily a bug-detection mechanism, they aren't a gatekeeping ritual, and they aren't a compliance checkbox for SOC 2 auditors. They exist to spread understanding of the code across more than one human head.
The HN thread produced the usual split: engineers whose companies treat review as a quality gate insisted bugs-caught is a real metric; engineers at teams where review works well described it the way mjd does — as the primary mechanism by which a codebase stops being one person's private garden. Several commenters pointed at the corollary that gets skipped in most style guides: if the reviewer finishes and still couldn't confidently modify the code themselves, the review failed, no matter how many nits they left.
The post itself is not new territory for anyone who has read Karl Wiegers or the Google engineering practices doc. What made it land is timing. It followed a week of discourse about AI-generated PRs where reviewers admit to skimming diffs they don't understand because "the tests pass." Mjd's framing lands a knife on that: if the tests-pass reviewer never internalized the change, the review produced zero of its actual output.
The bug-detection framing sounds harmless. It isn't. When leadership measures review by defects surfaced per PR, four predictable things happen. Reviewers gravitate to shallow changes where nits are easy to find. Deep architectural PRs get rubber-stamped because engaging seriously produces fewer visible comments than a bikeshedding sweep on a config file. Authors learn to split diffs into cosmetic warm-ups plus buried substance. And the review-as-mentorship channel closes, because mentorship generates zero "defects caught."
Steve McConnell's numbers from Code Complete are still the industry's best public data: formal inspection catches 60-90% of defects, but the same inspections catch effectively zero of the defects that matter most — architectural mistakes discovered three sprints later. The bugs a reviewer catches in a 400-line diff are almost always the cheap ones. The expensive bug is that the diff shouldn't exist in that shape at all, and spotting *that* requires the reviewer to already understand the surrounding system — which is exactly the capability the review is supposed to build.
Google's internal readability process, described publicly by their engineering-practices team, encodes mjd's framing almost verbatim: reviews exist to propagate norms and context, and the reviewer's job is to end the review understanding the change well enough to maintain it. A senior engineer at Stripe put it more sharply in the HN thread: "If I approve your PR and then you get hit by a bus, and I can't ship the next version of what you built, I did not actually review your code." That's the operational definition. It has nothing to do with bug counts.
The measurement problem compounds: bug-catching is legible to managers and knowledge-distribution isn't, so the legible metric wins even when everyone privately admits it's the wrong one. This is Goodhart's Law wearing an engineering-practices costume. Once "comments per PR" or "defects per review" show up on a dashboard, reviewers optimize for the dashboard and the actual purpose — shared context — silently degrades.
Three concrete moves are worth making this quarter, especially if your team has grown past the point where any single person still holds the whole system in their head.
First, rewrite your review checklist to include one question at the top: "Could you, the reviewer, modify this code next week without asking the author?" If the answer is no, the review is not done — regardless of how clean the diff looks. That single question forces engagement with the change instead of surface-level checking. It also naturally shortens PRs, because a reviewer who has to actually understand 800 lines of new logic will push back on the size before they push back on the naming.
Second, kill any metric that counts defects-caught or comments-per-PR at the reviewer level. Keep aggregate defect-escape data — it's useful for the team retrospective, not for individual performance. If leadership needs a review metric, use *review coverage of critical paths*: which files in the last quarter had reviews performed by at least two engineers who could now independently modify them? That number tells you whether your bus factor is going up or down. Comment count tells you nothing.
Third, treat AI-generated PRs as the stress test they are. When the author is Claude or Copilot, the human on the approve button is the *only* place shared understanding can accrue. A rubber-stamped AI PR is a diff that exists in the codebase and in zero human heads. That's a category of technical debt that didn't exist five years ago, and none of the standard review tooling surfaces it. Some teams are starting to require the human approver to write the PR description themselves — a small ritual that forces the reviewer to actually read.
Expect this framing to get louder as AI-assisted PRs scale. The bug-detection framing was already weak; it becomes actively dangerous when the author is a model that will happily produce 2,000 lines nobody understands. The teams that survive that transition well will be the ones who already treat review as a context-propagation mechanism, because they'll notice immediately when the propagation stops happening. The teams still counting comments-per-PR will discover, eighteen months from now, that they have a codebase full of code no human on the team can confidently change — and they'll blame the AI instead of the metric.
What I find to be maybe the single most important part of code review is knowledge transfer.Our entire small team thumbs up a PR before it's merged unless there's a big rush on it, and this gives everyone on the team a rough idea of the state of the codebase at any given time. There's
My attitude has always been that code review is best thought of as the gate where code goes from being owned by the author to being owned by the team or project. The code I'm reviewing is not your code, it is code that is about to become our code.Maintainability is a major factor in that, of co
This just makes reviewers and authors lazier.The purpose of code review is multi-faceted. Hard to maintain? Yes. Might have bugs? Yes. Can be done simpler/cleaner? Yes. Is in line with project code style? Yes. Get someone else to also understand the code? Yes. Onboard junior team member? Yes. S
I formed (and am advocating) a theory that code reviews are three dimensional space exercising trust, need for control and awareness propagation.E.g. LGTM could be categorized as high trust, low control, high awareness.I'm still in process of forming it on writing mostly because I get hooked up
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Code review doesn't have a single purpose. Finding code that is hard to maintain is one of those, and and an important one, but certainly not the only one, and I'm not sure it is even the most important one. Other purposes include:- a safety check to ensure that if a developer (or AI) goes