Code Review's Real Job Isn't Bugs — It's Catching Unmaintainable Code

Mark Jason Dominus (mjd) argues that engineering teams misunderstand what code review is for. The common assumption is that reviews exist to catch bugs, but his contention is that their primary value lies elsewhere: surfacing code that will be difficult to maintain over time. Defects tend to be caught by tests, type checkers, and CI; a human reviewer’s scarce attention is better spent on the things automation can’t judge.

The distinction matters because it reframes what a reviewer should look for. Instead of hunting for logic errors, the reviewer’s job becomes assessing readability, naming, structure, coupling, and whether the next engineer to touch the code will understand it. Maintainability is inherently a judgment call about future human comprehension — exactly the kind of problem a machine struggles with and a peer is well suited to.

As a short, opinionated claim rather than a full essay, the post functions mainly as a provocation, and it drew discussion on Hacker News for that reason. Its practical implication is that teams optimizing reviews purely for bug-catching may be measuring the wrong thing and underusing their most expensive review resource: another engineer’s judgment about long-term cost.