Code Review Isn't About Finding Bugs: A Team Process Myth-Busting FAQ

Is Code Review Really About Finding Bugs?

Here's the contrarian truth: code review is not primarily about finding bugs. At Google, a peer-reviewed study of over 9 million changes found that the four key expectations of code review are education, maintaining norms, gatekeeping, and accident prevention—with bug detection falling to the bottom of the list (Modern Code Review: A Case Study at Google). That's a hard pill for many teams to swallow, but it changes everything about how you structure your review process. If you're optimizing for bug-catching, you're optimizing for the wrong thing.

Why Do We Keep Treating Code Review as a Bug Hunt?

Because it's the easiest thing to measure. We can count bugs found in review, but we can't easily count the knowledge shared or the norms reinforced. So we fall back on what's quantifiable. But the research at Google shows that the primary purpose of code review is to ensure the overall code health of the codebase improves over time (Google Engineering Practices - Standard of Code Review). That's a subtle shift: it's not about perfect code, but better code. When you stop chasing every nit and start focusing on the trajectory, your reviews become more productive and less exhausting.

Should We Automate Everything We Can?

Yes—and no. Automation should handle the mechanical checks: style, formatting, obvious security patterns, and dependency vulnerabilities. Use linters like ESLint for JavaScript, Bandit for Python, and gosec for Go to catch common issues before a human ever looks (Bandit; gosec; ESLint). But the human review should focus on design, logic, and architecture. Google's own guidance is clear: linters and static analysis should handle the boring stuff so reviewers can think about the big picture (Google Engineering Practices - Code Review). The mistake is trying to automate away the human judgment that makes review valuable in the first place.

Does a Code Review Have to Be Formal?

No. Modern code review is informal, tool-based, and asynchronous—a far cry from the heavyweight Fagan inspection of the 1970s, which had defined stages like planning, overview, and an inspection meeting (Modern Code Review: A Case Study at Google). You don't need a moderator or a formal meeting. What you need is a reliable process that fits your team's workflow. Tools like Gerrit, GitHub Pull Requests, or GitLab Merge Requests all support this informal style (Gerrit). The formality is a distraction from the real goal: improving code health.

How Small Should Pull Requests Be?

Smaller than you think. Google's guidance suggests that 100 lines is usually a reasonable size, and 1000 lines is usually too large (Google Engineering Practices - Small CLs). But the real data is even more striking: at Google, the median change size is about 24 lines, with over 35% of changes modifying only one file (Modern Code Review: A Case Study at Google). That's not an accident. Small changes are reviewed more quickly, more thoroughly, are less likely to introduce bugs, and are easier to merge and roll back. If you're regularly reviewing 500-line PRs, you're making your team slower and more error-prone. Split them up by concern, even if it means more PRs.

What Should Reviewers Actually Look For?

Start with design. Google's review checklist puts overall design first, before functionality, complexity, tests, naming, and comments (Google Engineering Practices - What to Look For). That's counterintuitive to many reviewers who jump straight to line-level nitpicks. But design is where the biggest issues hide. A change can be functionally correct but architecturally unsound, and that's what will bite you later. So ask: does this change fit into the system's architecture? Is there a simpler way? Then move on to functionality, complexity, and tests—but keep design at the front of your mind.

How Fast Should Reviews Happen?

Fast—but not manic. Google sets a maximum of one business day to respond to a review request, meaning first thing the next morning (Google Engineering Practices - Speed of Code Reviews). And they've found that quick individual responses matter more than the overall turnaround time, because that's what reduces developer frustration. The data backs this up: at Google, the median time to first feedback for small changes is under an hour, and the overall median review latency is under four hours (Modern Code Review: A Case Study at Google). If your reviews routinely take days, you're not just slowing delivery—you're demoralizing your team.

Can We Approve a Review with Unresolved Comments?

Absolutely. Google's 'LGTM with comments' technique lets a reviewer approve a change while leaving non-blocking comments, as long as you're confident the author will address them or they're truly minor—like sorting imports or fixing a typo (Google Engineering Practices - Speed of Code Reviews). This is a game-changer for team velocity. You don't need to block a merge on a style nit. Approve, leave the comment, and move on. The key is trust: if you trust your team to follow up, you can keep the pipeline moving without sacrificing quality.

Quick tip: When a reviewer says they don't understand your code, don't just explain it in the review thread—fix the code itself or add a comment, because future readers won't see your explanation (Google Engineering Practices - Handling Reviewer Comments).

Is Branch Protection Enough to Enforce Reviews?

Branch protection is a useful tool, but it's not a substitute for a healthy review culture. On GitHub, you can require a specific number of approving reviews and even require reviews from code owners (GitHub Docs - About Protected Branches). GitLab Premium lets you enforce required approvals, and you can even require security team approval for potential vulnerabilities (GitLab Docs - Merge Request Approvals). These are great guardrails, but they only enforce the mechanics. The real quality comes from having reviewers who understand the difference between blocking issues and nits, and who use the review to educate and maintain norms. A protected branch with a rubber-stamp review is worse than no review at all.

Sources

• Modern Code Review: A Case Study at Google - https://www.papercache.org/papers/mlsys/system/2026/03/25/modern-code-review-a-case-study-at-google
• Google Engineering Practices - Code Review - https://google.github.io/eng-practices/review/
• Google Engineering Practices - Speed of Code Reviews - https://google.github.io/eng-practices/review/reviewer/speed.html
• Google Engineering Practices - Small CLs - https://google.github.io/eng-practices/review/developer/small-cls.html
• GitHub Docs - About Protected Branches - https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• GitLab Docs - Merge Request Approvals - https://docs.gitlab.com/user/project/merge_requests/approvals/