A platform's code review process is slow and catches few defects. What should change?

The diagnosis

Reviews are too large and too slow, which are the same problem reinforcing itself. A large change takes a long time to review, so it waits; while it waits it grows; the larger it is, the more superficially it is reviewed.

Beyond a few hundred lines, reviewer effectiveness falls sharply — large reviews receive approval, not review.

What should change

1. Smaller changes, as the primary intervention. A change of a few hundred lines is reviewed meaningfully; a change of two thousand is skimmed. This single change improves both speed and defect detection, and everything else is secondary to it.

2. Review latency as a tracked metric with a target. Time from request to first response. A review waiting a day blocks the author, who starts something else and returns with lost context. Same-day response should be a team commitment.

3. Automate what machines do better. Formatting, linting, static analysis, dependency rules, test coverage, security scanning. Human attention spent on formatting is attention not spent on logic, and machines never tire of it.

4. Be explicit about what review is for. Correctness, design fit, maintainability, and knowledge sharing — not style, which is a tool's job. Ambiguity here produces reviews full of preferences and no design feedback.

5. Separate behaviour-preserving changes. A refactoring commit is reviewable quickly; one mixing restructuring with behaviour change is neither reviewable nor revertible.

What review is genuinely good at

Design fit, missing cases, and knowledge transfer. It is poor at finding subtle bugs — tests and types are better — and poor at catching performance problems, which need measurement.

Recognising this changes what reviewers look for: does this belong here, what happens when this fails, what case is not handled, will the next person understand this — rather than reading for defects line by line.

The cultural dimension

Reviews that only find fault produce defensive authors and superficial reviews. Acknowledging good decisions, asking questions rather than issuing instructions, and distinguishing blocking concerns from suggestions are what make the process one people engage with rather than endure.

And the fastest review is the one that was discussed before the code was written — a design conversation costs minutes and prevents a rewrite.