Code Review Is Not About Bugs: Debunking the Biggest Myth

Imagine you're a developer at a fast-moving company. You've just pushed a pull request that touches 300 lines across five files. You're waiting for a review, and you're secretly hoping the reviewer will spot the subtle off-by-one error you made in the edge case. But when the review comes back, it's full of comments about naming, a missing test, and a suggestion to extract a helper function. The bug is never mentioned. You think, "Why bother with review if they can't even catch my bug?"

Here's the thing: that's exactly how code review is supposed to work. The research is clear — modern code review isn't primarily about finding defects. In a large-scale study at Microsoft, developers reported that while finding defects is the main motivation, the actual outcomes are more about knowledge transfer, team awareness, and alternative solutions (Bacchelli & Bird, ICSE 2013). At Google, the four key expectations of code review are education, maintaining norms, gatekeeping, and accident prevention — and finding bugs is not the primary focus (Modern Code Review: A Case Study at Google). So if you're using review as a bug-hunting tool, you're missing the point.

In this article, we'll bust the biggest myths about code review and show you how to get real value from it. We'll also give you concrete best practices — from keeping changes small to responding quickly — that make review a joy, not a chore.

Myth: The main purpose of code review is to find bugs

As we just saw, that's not what the data says. In fact, Google's own engineering practices state that the primary purpose of code review is to make sure the overall code health of the codebase is improving over time (Google Engineering Practices - Standard of Code Review). That's a much broader goal than catching a single bug. It means review should catch design flaws, over-engineering, missing tests, and unclear comments — things that cause long-term pain.

So if you're a reviewer, don't focus solely on "does it work?" Instead, ask: "Does this change make the codebase easier to understand and modify?" If a change is correct but poorly structured, it's a problem. If it's correct and well-structured, it's good — even if it has a minor bug that tests will catch.

Myth: Larger pull requests are more efficient

We've all been there: you spend a week building a feature, and you submit a 1,000-line PR because you want to get it all in one go. That's a mistake. Research at Google shows that small changes are reviewed more quickly and more thoroughly, and are less likely to introduce bugs (Google Engineering Practices - Small CLs). They're also easier to merge and roll back. The median change size at Google is about 24 lines, and more than 10% of changes modify only one line (Modern Code Review: A Case Study at Google). That's a far cry from our 1,000-line monsters.

How small is small? Google suggests that 100 lines is usually a reasonable size, and 1,000 lines is usually too large (Google Engineering Practices - Small CLs). A 200-line change in one file might be fine, but spread across 50 files it's usually too much. So split your work into logical, reviewable chunks. Aim for under 400 lines of meaningful change, as a rule of thumb (Google Engineering Practices - code review).

Myth: You have to approve or reject — there's no middle ground

On GitHub, you have three review options: Comment, Approve, or Request changes (GitHub Docs - About pull request reviews). But in practice, the most useful review is often "LGTM with comments." Google explicitly recommends this technique: you approve the change while leaving unresolved comments when you're confident the developer will address them later, or when the comments are minor (Google Engineering Practices - Speed of Code Reviews). This keeps the process moving and avoids blocking on trivialities.

This is especially important because speed matters. Google's rule is that reviewers should respond within one business day, and ideally much faster — median time to first feedback at Google is under 1 hour for small changes (Modern Code Review: A Case Study at Google). If you wait until everything is perfect, you'll be the bottleneck. Instead, approve when the change is good enough, and leave a list of nits that don't block the merge.

Myth: More reviewers means more thorough review

You might think that adding more reviewers will catch more issues, but the data says otherwise. At Google, fewer than 25% of changes have more than one reviewer, and the median is just one reviewer (Modern Code Review: A Case Study at Google). And that's fine — because the goal isn't to maximize the number of comments, it's to ensure the change is sound. One engaged reviewer who knows the codebase is more valuable than five who skim it.

If you need specific expertise, use code owners. On GitHub, you can define a CODEOWNERS file that automatically requests reviews from the right people when certain files are touched (GitHub Docs - About code owners). This ensures the right eyes are on the change without adding unnecessary noise.

Myth: Automation can replace human review

Some teams think that if they run enough linters and static analyzers, they can skip human review altogether. That's a dangerous delusion. Tools like ESLint, Bandit, and gosec are great at catching style issues and common security patterns (ESLint Docs; Bandit (PyCQA) Docs; gosec - Go Security Checker). But they can't assess design, architecture, or test quality. Google's advice is to let automation handle the mechanical checks, so humans can focus on logic and architecture (Google Engineering Practices - code review).

Think of it this way: a linter can tell you that you have a SQL injection vulnerability, but it can't tell you that your approach to handling user input is fundamentally flawed. That's your job as a reviewer. So use tools to your advantage, but don't let them become a substitute for reading the code.

Bottom line

The single best move you can make is to stop treating code review as a bug hunt and start treating it as a way to improve code health. That means keeping changes small, responding quickly, approving when it's good enough, and using automation for the mundane. Do that, and you'll find that review becomes a valuable part of your development process — not a bottleneck.

Sources

• Google Engineering Practices - Standard of Code Review - https://google.github.io/eng-practices/review/reviewer/standard.html
• Google Engineering Practices - Small CLs - https://google.github.io/eng-practices/review/developer/small-cls.html
• Google Engineering Practices - Speed of Code Reviews - https://google.github.io/eng-practices/review/reviewer/speed.html
• Modern Code Review: A Case Study at Google (ICSE-SEIP '18) - https://www.papercache.org/papers/mlsys/system/2026/03/25/modern-code-review-a-case-study-at-google
• Modern Code Review: Expectations, Outcomes, and Challenges (Bacchelli & Bird, ICSE 2013) - https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/
• GitHub Docs - About code owners - https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners