Speed Up Code Review by Making It Smaller Than You Think

Who This Is For

If your team treats code review as a formality—a hurdle to jump before merging—you're doing it wrong. This is for engineering leads and senior devs who want to turn review from a bottleneck into a lever for team velocity and code health. I'm going to walk you through a process that makes review faster, less painful, and more effective. And it starts with a counterintuitive rule: stop reviewing big changes.

The Contrarian Start: Small Is Not Just Better, It's the Only Way

Everyone says "keep PRs small," but few actually enforce it. I'm here to say: if your pull request is over 100 lines, you've already failed. Google's own research shows that median change size is about 24 lines, and over 35% of changes touch just one file (Modern Code Review: A Case Study at Google). That's not a coincidence—that's a deliberate strategy. Small changes are reviewed more quickly and more thoroughly, are less likely to introduce bugs, and are easier to merge or roll back (Google Engineering Practices - Small CLs). A 200-line change might be okay in one file, but spread across 50 files, it's too large (Google Engineering Practices - Small CLs). So split your work by concern. If you can't describe the change in a single imperative sentence, it's too big.

Step 1: Automate Everything That Doesn't Need Human Judgment

Before a human ever looks at your code, linters and static analyzers should have already caught style issues, potential bugs, and security smells. Let machines handle the mechanical stuff: formatting, naming conventions, unused variables. Use ESLint for JavaScript (ESLint Docs - Getting started), Bandit for Python (Bandit (PyCQA) Docs), gosec for Go (gosec - Go Security Checker), and Semgrep for cross-language security patterns (Semgrep Docs - Getting started). Set up a quality gate like SonarQube's built-in "Sonar way" which fails the build if new code coverage is below 80% or if duplication in new code exceeds 3% (SonarQube Server Docs - Understanding quality gates). This frees your human reviewers to focus on what really matters: design, logic, and edge cases (Google Engineering Practices - code review).

Step 2: Set a Hard Speed Limit: One Business Day, Not One Week

Slow reviews kill team velocity, make developers resent the process, and hurt code health (Google Engineering Practices - Speed of Code Reviews). Google's rule: a reviewer should respond within one business day, meaning first thing the next morning (Google Engineering Practices - Speed of Code Reviews). That doesn't mean you drop everything mid-task—interrupting your flow is more expensive than making a developer wait a bit (Google Engineering Practices - Speed of Code Reviews). But if you're not in the middle of a focused task, review immediately. Quick responses are more important than fast overall turnaround (Google Engineering Practices - Speed of Code Reviews). At Google, median time to first feedback is under an hour for small changes (Modern Code Review: A Case Study at Google). If you're taking longer than that, your review process is the bottleneck.

Step 3: Use "LGTM with Comments" to Keep Momentum

You don't have to block a merge for every nit. Google's "LGTM with comments" technique lets you approve a change while leaving minor comments that you trust the author to address (Google Engineering Practices - Speed of Code Reviews). This works for suggestions like sorting imports, fixing a nearby typo, or removing an unused dependency. It's not for substantive issues. But if you're confident the developer will fix it, and it's not worth a second round, approve. This keeps the review from stalling on trivialities. Remember, the goal is to improve code health over time, not to achieve perfection (Google Engineering Practices - Standard of Code Review).

Step 4: Make the Author Do the Clarifying

When a reviewer says they don't understand something in the code, the author's first instinct is to explain in a comment. Wrong. The code itself should be clarified, either by rewriting it or adding a comment in the code (Google Engineering Practices - Handling reviewer comments). An explanation buried in a review thread does nothing for future readers. This one habit drastically reduces back-and-forth and keeps the codebase self-documenting. Also, require a clear CL description: first line should be a complete imperative sentence summarizing what the change does, followed by a blank line (Google Engineering Practices - Writing good CL descriptions). If the description says "Fix bug" or "Fix build," send it back. The description is a public record—it should explain what and why, including bug numbers or design links (Google Engineering Practices - Writing good CL descriptions).

Step 5: Protect Your Branches and Automate Reviewers

Don't rely on memory to know who should review what. Use GitHub's CODEOWNERS file to automatically request reviews from the right people when a PR modifies their code (GitHub Docs - About code owners). Place it in .github, root, or docs, and remember the last matching pattern wins (GitHub Docs - About code owners). Then enforce branch protection: require a specific number of approving reviews, and require reviews from code owners (GitHub Docs - About protected branches). Turn on dismissal of stale approvals—if new commits change the diff, the old approval is dismissed and the PR needs fresh approval (GitHub Docs - About protected branches). This prevents the classic "I approved before you rebased, but now it's a different change" problem. On GitLab, use required approvals in Premium/Ultimate to enforce reviews by specified users (GitLab Docs - Merge request approvals).

What Can Go Wrong

The biggest risk is turning review into a rubber stamp. If you speed up too much, you'll skip the deep design review that catches architectural issues. Google's research shows that finding bugs isn't even the primary purpose of review—it's education, maintaining norms, gatekeeping, and accident prevention (Modern Code Review: A Case Study at Google). So don't let speed kill those benefits. Also, beware of "emergencies." Google defines a true emergency as a change that unblocks a major launch, fixes a critical production bug, or closes a major security hole (Google Engineering Practices - Emergencies). A soft deadline, a developer who's been working for weeks, or end-of-Friday submissions are not emergencies (Google Engineering Practices - Emergencies). If you treat everything as urgent, you'll sacrifice code health for no good reason.

The Takeaway

Code review should make your codebase better, not slower. Keep changes under 100 lines, automate the boring checks, respond within a day, approve with minor comments when you trust the author, and protect your branches with owners and stale approval dismissal. It's not about being fast for its own sake—it's about removing friction so that review becomes a tool for learning and quality, not a bureaucratic gate. Start with one team, enforce small PRs, and watch your review latency drop from days to hours.

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 - 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
• GitHub Docs - About code owners - https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
• GitHub Docs - About protected branches - https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• SonarQube Server Docs - Understanding quality gates - https://docs.sonarsource.com/sonarqube-server/2026.1/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates