Code Review Isn't a Bug Hunter—It's a Maintainability Checkpoint

The traditional vision of code review—catching bugs through careful peer inspection—is a myth that sets engineering teams up for failure. Experts argue that the process has been fundamentally misunderstood for years, and the gap between expectation and reality is costing teams in production incidents and wasted effort.

What code review actually does (and doesn't)#

Senior software engineer Mark Dominus points out a critical flaw in how many organizations operate: they never clearly define what a successful code review should deliver. When junior developers are simply told to "find bugs," they're being set up for disappointment. In a Mastodon post, Dominus argues that "anyone who depends on code review to find bugs is living in a fool's paradise," since subtle runtime defects—race conditions, edge cases under load, obscure state transitions—simply cannot be reliably detected by reading code.

Mikhail Golikov, a QA engineer at a high-load e-commerce platform, calls this approach "theatre." A developer skimming a pull request can spot messy naming conventions or architectural inconsistencies, but they cannot see whether a discount calculation goes negative under concurrent traffic or whether the system fails silently when resources saturate.

The actual purpose of code review#

Rather than hunting for bugs, code review's genuine value lies in assessing maintainability and readability. The goal should be straightforward: Can another engineer understand this code six months from now? Will it be painful to modify?

Dominus proposes a more honest framework. Instead of vague directives, team leads should set explicit expectations: "Spend two hours reviewing this. Write down anything you don't understand. If you don't finish, mark where you stopped." This reframes the review outcome. If a reviewer runs out of time, that's valuable information—it signals the changeset is too large or complex. The solution is to break the work into smaller, reviewable pieces.

Golikov emphasizes the division of labor clearly: "Review is for the question 'will I hate maintaining this in six months' and 'does it actually work' when a test is run against real inputs, not for a human skimming a pull request at 5 pm." Tests catch bugs. Code review catches code quality. Production catches everything else.

Rethinking review in the age of AI#

As AI-generated code enters the workflow, the role of code review is shifting again. Judah Taub, managing partner at Hetz Ventures, predicts that engineers will increasingly review AI-generated reviews rather than code directly. The engineer's focus will migrate further from syntax and logic toward validating high-level architecture, business intent, and design decisions.