Code Review: The Arguments on Both Sides

The disagreement is not about whether code should be looked at. It is about whether a second person must approve before code merges, and that single policy choice reshapes how a team works.

The Case For Blocking Review

A required approval is the only control that is impossible to skip when someone is in a hurry, which is exactly when defects get introduced. It creates an audit trail that satisfies SOC 2 and similar frameworks essentially for free. It spreads knowledge of unfamiliar parts of the codebase to people who would otherwise never open those files. And it gives junior engineers a structured, written channel for feedback that pairing does not preserve.

There is also a bus-factor argument: if only one person has read a service's code, the review requirement is what forces a second reader to exist.

The Case Against

Review adds queue time, and queue time is usually the largest single component of cycle time. A change that takes two hours to write and waits nineteen hours for a reviewer has spent 90 percent of its life doing nothing. Waiting also encourages batching — if a review costs a day, people bundle more into each pull request, and larger pull requests get worse review, which is a reinforcing loop in the wrong direction.

Reviewer attention also decays sharply with size. Reviewing 100 lines is a careful read; reviewing 1,000 is skimming for style issues and approving. A rubber-stamp approval is worse than no policy, because it produces the appearance of a control without the substance.

What the Size Data Says

The most consistent finding across published review research and internal engineering studies is that defect detection falls off sharply past a few hundred changed lines, and that review sessions longer than about an hour find much less per line than short ones. Whatever the precise numbers in your context, the direction is not controversial: small, frequent reviews find more per unit of effort than large infrequent ones. This makes pull request size the variable most worth managing, well ahead of the approval policy itself.

The Middle Positions

• Risk-tiered review. Blocking approval for auth, payments, migrations and infrastructure; non-blocking for copy changes, test additions and internal tooling. Encode it with CODEOWNERS so it is automatic rather than a matter of judgement.
• Ship-and-review. Merge behind a feature flag, review after. Keeps flow, keeps the second reader. Requires real flag discipline or you accumulate dead flags.
• Pairing counts as review. Two people wrote it together, so the second-reader requirement is already met. This is standard in extreme-programming teams and satisfies most auditors if the commit trailer records both authors.

Delete the Comments a Machine Should Make

Formatting, import order, unused variables, missing null checks and known-bad patterns should be caught by a formatter, a linter and a type checker in CI — never by a human in a comment thread. Every automated check you add removes a category of review comment permanently and moves the conversation toward design, naming and edge cases, which is the only part a human is uniquely good at. Teams that complain review is slow are very often reviewing things a tool should have rejected before the pull request opened.

How to Tell Which Side You Should Be On

Measure two things for a month: median time from "review requested" to "first comment", and median lines changed per pull request. If the first is under four hours and the second is under 200, blocking review is nearly free and you should keep it. If reviews wait a day and pull requests are a thousand lines, the policy is not producing quality — it is producing delay plus the illusion of quality, and you should fix the size and latency before arguing about the policy.