Your Code Review Process Is Too Slow — Here's How to Fix It

Most teams treat code review like a gate that must be passed. That's wrong. The best teams treat it as a conversation that happens fast. I've seen too many teams let pull requests sit for days, then wonder why velocity drops. The fix isn't more process — it's less waiting. Here's how I'd run it.

Who this is for

This is for tech leads and engineers on teams of 5–50 who already have some review process but feel it's sluggish, inconsistent, or painful. If you're still doing formal Fagan inspections with a moderator, this isn't for you. Modern review is informal, tool-based, and asynchronous (Modern Code Review: A Case Study at Google (ICSE-SEIP '18)). Let's make yours fast and useful.

1. Set a response-time SLA that actually matches reality

Google's rule is simple: respond to a review request within one business day, and ideally much faster. But here's the nuance — individual responses matter more than the whole review finishing quickly. Quick replies ease frustration. So I tell my team: if you're not deep in a focused task, do the review shortly after it comes in. Don't interrupt yourself mid-flow; that costs the team more than making someone wait a bit (Google Engineering Practices - Speed of Code Reviews). At Google, median time to first feedback was under 1 hour for small changes, and median review latency was under 4 hours overall. That's the bar. If your team's median is 24 hours, you have a problem.

2. Make small changes the default

Google's data: median change size was about 24 lines. Over 35% of changes touched only one file, and about 90% touched fewer than 10 files. That's not an accident. Small changes are reviewed faster, more thoroughly, and are less likely to introduce bugs (Google Engineering Practices - Small CLs). I aim for under 100 lines of meaningful change per pull request. If a change is 200 lines in one file, fine. Spread across 50 files? Split it. Use stacked PRs or feature flags. The goal is to keep the cognitive load low. When I see a 1000-line PR, I ask for it to be broken up.

3. Automate the boring stuff so humans focus on design

Linters, formatters, static analysis, secret scanners, and dependency scanners should handle style and mechanical checks. That frees human review for logic and architecture. I run ESLint for JavaScript, Bandit for Python, gosec for Go, and Semgrep for custom rules. On GitHub, Dependabot alerts on vulnerable dependencies; code scanning with CodeQL catches security issues. But these tools have limits: Dependabot only triggers on advisories reviewed by GitHub, and it won't catch everything (GitHub Docs - About Dependabot alerts). Use them, but don't rely on them for correctness.

4. Review in the right order — design first

Google says the most important thing to cover is the overall design of the change, before checking functionality, complexity, tests, naming, and comments (Google Engineering Practices - What to look for in a code review). I start by reading the CL description. Google requires the first line to be a short, imperative summary — not 'Fix bug' but 'Add retry logic to payment API client'. If the description is vague, I ask for a better one before reviewing code. Then I look at the design: does this solve the right problem? Is it over-engineered? Google warns against over-engineering — code more generic than needed or functionality added for speculative future needs. I push back on that hard. Solve the problem you have now.

5. Label your comments by severity

Not all feedback is equal. I use three labels: nit (minor, optional), suggestion (should consider), blocking (must fix before merge). This prevents authors from treating every comment as a blocker. Also, offer solutions, not just problems. 'This will deadlock under load' is okay; 'This will deadlock under load — consider using a mutex here' is better. And if you don't understand something, ask the author to clarify the code itself, not just explain in the review tool. An explanation buried in a PR comment doesn't help future readers (Google Engineering Practices - Handling reviewer comments).

6. Know when to LGTM with comments

Google's 'LGTM with comments' technique: approve while leaving unresolved comments when you're confident the developer will address them, when comments don't have to be addressed, or when suggestions are minor — sort imports, fix a typo, remove an unused dependency. This keeps velocity up. I use it when I trust the author and the change is safe. If the change touches critical security code, I don't use it; I wait for a new commit.

What can go wrong

The biggest failure mode is letting review become a bottleneck. When reviews are slow, developers protest the process, and code health suffers. Another risk: over-relying on tools. SonarQube quality gates can block merges, but they won't catch architectural flaws or subtle race conditions. And if you set a quality gate with 80% coverage on new code, teams may write useless tests just to hit the number. I've seen that happen. Use gates as a floor, not a ceiling.

What I'd actually do

If I were starting from scratch today, I'd implement three things this week. First, a response-time SLA: first review within 4 hours during work hours. Second, a size limit: no PR over 200 lines without a written justification. Third, a comment convention: tag every comment with nit, suggestion, or blocking. Then measure your median review latency. If it's over 8 hours, you're losing velocity. At Google, 97% of developers were satisfied with their review tool, and the top expectations were education, maintaining norms, gatekeeping, and accident prevention — not finding bugs. That tells me the social and process aspects matter more than defect hunting. So make your process fast, kind, and consistent. Your team will thank you.

Sources

• 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
• 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
• GitHub Docs - About Dependabot alerts - https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
• Google Engineering Practices - What to look for in a code review - https://google.github.io/eng-practices/review/reviewer/looking-for.html