Dominus argues the true measurable output of code review is the number of team members who could confidently modify the code without asking the original author. This reframing explains why LGTM culture is corrosive even when nothing ships broken, and why teams that skip review during crunch see mysterious velocity collapse months later when the original author leaves.
By submitting mjd's post to HN where it climbed to 286 points, Wright surfaced the argument that the most valuable review comments — 'why did you pick this approach over X?' — are exactly the ones optimized-for-defects tooling would flag as noise. The submission's traction indicates broad agreement among senior engineers that knowledge propagation is the real deliverable.
The editorial argues that CodeRabbit, Graphite Diamond, Copilot PR review, Codacy, and Sourcery all lead their marketing with defect-detection metrics — 'catches 3x more issues,' '40% fewer incidents.' If knowledge transfer is the true purpose of review, the entire AI code review category is competing on a proxy that senior engineers abandoned years ago, making it a bug-catching product masquerading as a review product.
The editorial extends mjd's logic to conclude that shared context and propagated judgment about why code looks the way it does cannot be produced by a model that won't be on the team next week. Since AI reviewers have no continuity with the codebase or its maintainers, they structurally cannot deliver the knowledge-transfer output that makes review worthwhile in the first place.
Mark Jason Dominus's mathstodon post ('Many people misunderstand the purpose of code review') hit 286 on Hacker News and drew a long comment thread from staff engineers at companies you've heard of. His argument, in one sentence: code review is not primarily a bug-catching mechanism. It's a knowledge-transfer mechanism. The measurable output is not 'defects prevented' but 'number of people who could confidently modify this code next week without asking the author.'
This reframing lands because it explains a set of observations that the bug-catching model doesn't. It explains why LGTM culture is corrosive even when nothing ships broken. It explains why teams that skip review during crunch don't see an immediate defect spike but do see mysterious velocity collapse three months later, when the original author leaves. And it explains why the review comments that feel most valuable — 'why did you pick this approach over X?' — are exactly the ones a bug-catching tool would flag as noise.
The uncomfortable corollary, which mjd doesn't say but the HN thread does, is that every AI code review tool on the market is optimized against the metric he argues is broken.
Look at what CodeRabbit, Graphite Diamond, GitHub Copilot's PR review, Codacy, and Sourcery actually do. They read the diff, flag potential bugs, suggest style fixes, and sometimes propose refactors. That is a bug-catching product. Their marketing pages lead with defect-detection metrics — 'catches 3x more issues than manual review,' 'reduces production incidents by 40%.' Fine numbers. Wrong game.
If mjd is right, the entire category is measuring itself against a proxy that senior engineers stopped believing in a decade ago. The output that matters — shared context, propagated judgment about why the code looks the way it does — cannot be produced by a model that will not be on the team next week. A reviewer who won't touch the code again learns nothing. A reviewer who can't be asked 'why did we do it this way' six months from now transfers no knowledge. Both of those describe every LLM-based reviewer shipped in 2025 and 2026.
The HN thread has several practitioners making this concrete. One staff engineer at a fintech: 'We added CodeRabbit last quarter. PR turnaround dropped from 18 hours to 6. Six months in, three of our newer engineers now write PRs that pass CodeRabbit clean on the first try and I still have no idea if they understand the domain.' Another: 'The number of times I've reviewed code and thought, oh, this is why we don't do it that way — and then written a comment that taught the author a small piece of the system's history — that's the whole point. A model doesn't have the history.'
The counterargument in the thread is honest: some code review is bug-catching, especially for junior engineers pushing to unfamiliar parts of the codebase. And the AI tools genuinely are good at the null-check, off-by-one, missing-await tier of defect. Fair. But that's the tier that better linters, better types, and better tests should have caught upstream — it's the tier where the work is cheapest to automate and least valuable to a senior team.
The question is what happens to review quality when the AI tool takes the load off human reviewers. Two paths. Path one: humans review less because the tool 'already reviewed it,' knowledge transfer collapses, team fractures into people-who-know and people-who-shipped. Path two: humans review the same amount but focused on the higher-order things — architecture, naming, why-not-X — because the tool cleared the low tier. The data from teams using these tools for a year suggests path one is the default and path two requires deliberate management.
The practical answer isn't 'rip out AI review.' It's 'stop counting it as review.' Treat CodeRabbit and Copilot Review as a superset of your linter: they run pre-review, they catch a class of dumb mistakes cheaper than a human would, they save a round-trip. The PR still needs a human on it — a human who is expected to be on the team six months from now, who will be able to modify the code, and whose review comments will teach the author something the AI cannot.
Concrete moves: (1) Do not count AI approval as one of the required approvals on protected branches. Most teams that adopted these tools quietly did this and it corrodes review culture. (2) Measure review quality by the mjd metric — pick a file changed six months ago, ask a reviewer of that PR to modify it without help, see what happens. Ugly but honest. (3) If you're a lead, watch for the pattern where junior engineers stop asking 'why' in review comments because the AI never asks 'why' and they've been trained by example.
The tools that will matter next are the ones that make the knowledge-transfer job easier for humans, not the ones that automate the bug-hunting job away from them. That's a different product — annotation of unfamiliar code, surfacing of relevant past discussions, a 'why is this here' explainer pointed at git blame plus the linked issue plus the design doc. Some of the newer entrants (Greptile, Sourcegraph's Cody in review mode) are edging in that direction. Watch that space, not the defect-detection leaderboard.
The honest read is that most teams will keep using AI code review as bug-catching, keep quietly counting it as approval, and keep wondering in a year why their newer engineers can ship PRs but can't debug production. Mjd's post won't change that at scale. What it might change is how you, personally, evaluate whether your team's review process is actually working — and whether the metric you're currently optimizing measures a thing you actually want.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.