What Makes a Good Code Review—And What Most Teams Get Wrong

Code review is one of the most universally practiced and most variably executed practices in software development. Almost every engineering team does it; the quality of how it’s done differs enormously. Some teams run reviews that catch bugs, spread knowledge, and improve the design of the codebase over time. Others run reviews that are rubber stamps, or worse, adversarial friction points that slow development without producing commensurate value. The difference between these outcomes is not primarily about the sophistication of the tools or the seniority of the team — it’s about what reviewers think they’re trying to accomplish and how they approach the task.

What Code Review Is Actually For

Clarity about the purpose of code review shapes how it’s done. The purposes are multiple and not always aligned:

Bug detection — finding logic errors, edge cases, off-by-one mistakes, and null dereferences before they reach production — is the purpose most people think of first. It’s legitimate but is often the least efficiently served purpose of code review. Automated testing catches many bugs more reliably and earlier than human review; automated static analysis catches entire categories of defects (type errors, security vulnerabilities, common API misuse) more consistently than reviewers who read code at different attention levels on different days. Code review for bug detection is valuable but should not be the primary purpose, because it’s the easiest to automate and the most inconsistently delivered by humans.

Design and architecture feedback — evaluating whether the approach is sound, whether the abstraction is appropriate, whether the interface design creates good or bad coupling — is better delivered by code review than by automated tools, and it’s higher-leverage than catching individual bugs. A reviewer who notices that a new service is implementing functionality already handled by an existing service, or that a proposed abstraction will become awkward as the codebase evolves, produces value that no linter can match.

Knowledge sharing — both spreading awareness of changes to parts of the codebase that reviewers work in, and giving authors exposure to feedback that helps them grow — is one of the most underappreciated values of code review. A review that improves the author’s understanding of a codebase convention or technique provides lasting value beyond the specific change under review.

The Size Problem

The most common code review failure is large pull requests. A PR with 800 lines of change across 20 files produces low-quality review for structural reasons: reviewers can’t hold the full context in mind, the effort required discourages thorough reading, and the scope prevents meaningful design feedback (it’s difficult to suggest architectural changes when an 800-line implementation is already complete). Research consistently shows that review thoroughness decreases rapidly as diff size increases — beyond 400 lines, defect detection rates decline substantially.

Small, focused PRs — single logical changes, under 200–300 lines of diff as a rough guideline — produce dramatically better reviews. They’re easier to review thoroughly, easier to reason about in isolation, easier to revert if problems emerge, and easier to review quickly (which reduces the bottleneck that large PRs create when they sit waiting for review). The discipline to break large changes into small PRs requires up-front design thinking, but it’s one of the highest-leverage practices available to engineering teams looking to improve code review quality and development velocity simultaneously.

Teams that struggle with large PRs often do so because the technical architecture encourages them — tightly coupled systems where a change to one part requires changes to many others. Improving code review quality in these environments may require addressing the underlying architecture rather than just the review culture.

The Comment Quality Problem

Code review comments vary from highly valuable to actively counterproductive, and the difference often comes down to specificity and constructiveness. “This doesn’t look right” without explanation leaves the author without useful information. “Consider using X instead of Y because Z” provides a specific suggestion with a rationale that the author can evaluate and learn from.

The distinction between blocking comments (things that must change before merge) and non-blocking comments (suggestions, questions, observations) matters for the author’s ability to act on feedback efficiently. Teams that don’t distinguish these force authors to decipher which comments require action and which are optional, which creates communication overhead and author-reviewer friction. Explicit comment labeling — “blocking:”, “nit:”, “question:”, “suggestion:” — makes the required actions clear and reduces the cognitive load on authors.

The tone of code review comments affects the team’s review culture. Comments that focus on the code rather than the person (“this function does X but should do Y” versus “you wrote this wrong”), that explain reasoning rather than just stating conclusions, and that acknowledge good work alongside improvement suggestions create a culture where review is useful rather than adversarial. High psychological safety in review culture correlates with more honest discussion of tradeoffs, more willingness to ask questions, and better design outcomes than cultures where review is primarily a gatekeeping mechanism.

The Automation Complement

Code review is most effective when automated tools handle the things they’re better at and human reviewers focus on what humans are better at. Linters, formatters, type checkers, and static analysis running in CI before review catches style issues, obvious bugs, and type errors automatically — freeing reviewers from commenting on style (“use semicolons”, “this line is too long”) and letting them focus on the semantics and design. A review on a PR that already has automated checks passing and consistent formatting applied is faster and more focused than a review that mixes substantive concerns with mechanical style corrections.

Automated test coverage requirements (failing CI if test coverage drops below a threshold) catch missing tests without requiring reviewers to audit test completeness on every PR. Dependency vulnerability scanning catches security issues in new dependencies without requiring reviewers to manually check CVEs. Each automated gate removes a category of review comment and focuses human reviewer attention where it’s most valuable.

What Good Review Actually Looks Like

Good code review looks like: a clearly scoped PR with a description that explains what changed and why; automated checks passing; a reviewer who reads the change with the question “does this do what it’s trying to do correctly, is the design sound, and will it create problems later?” rather than “can I find something wrong with this?”; specific, labeled, constructive comments that distinguish blocking issues from suggestions; timely review (PRs waiting days for review are a development velocity problem as significant as writing slow tests); and approval that’s genuine rather than rubber-stamped. This is achievable in any team that agrees on it as a standard, and the gap between teams that achieve it and those that don’t is primarily cultural and process-based rather than technical.