Automate the Boring Part of Code Review, Not the Thinking

Imagine You're Reviewing a 900-Line PR

You open the pull request. It's 900 lines across 14 files. Half the changes are whitespace, renames, and a refactor that should've been three separate PRs. You spend 20 minutes just parsing what's happening. Then you spot a real bug — a race condition in the new caching layer. But by then your brain is fried, and you approve it anyway, hoping the CI catches the rest.

This is the reality of code review for too many teams. We've built processes that treat every change as a candidate for a Fagan inspection — the formal, stage-gated relic from the 1970s — but modern review is informal, tool-based, and asynchronous (Modern Code Review: A Case Study at Google). The problem isn't that we review too little; it's that we review the wrong things.

The Thesis: Automation Should Eat the Mechanical Checks

Here's my position, plainly: linters, formatters, static analyzers, secret scanners, and dependency scanners should handle every style and mechanical check, so human review is reserved for logic, architecture, and design. Google's own engineering practices say exactly that — automation should handle the rote stuff so reviewers can focus on what matters (Google Engineering Practices). But most teams don't draw that line cleanly. They let humans do the work a machine should do, and they let machines make decisions that need human judgment.

The result is a review process that's slower than it needs to be and dumber than it should be. Slow reviews decrease team velocity, make developers protest the process, and hurt code health (Google Engineering Practices - Speed of Code Reviews). And when reviewers are buried in trivia, they miss the design flaws that actually determine whether code improves the codebase over time — which Google calls the primary purpose of review (Google Engineering Practices - Standard of Code Review).

The Facts: What Tools Actually Catch

Static analysis has matured. SonarQube alone claims to analyze reliability bugs, security vulnerabilities, maintainability code smells, coverage, and duplication (SonarQube). Security-focused analyzers like Semgrep, Bandit, and gosec detect dangerous patterns — SQL injection, unsafe deserialization, path traversal (SonarQube). gosec goes further, using taint analysis for SQL injection, command injection, XSS, and SSRF (gosec). These tools are not hypothetical; they're free, open-source, and run in CI.

But the numbers tell a deeper story. At Google, the median change size is about 24 lines; more than 10% of changes modify a single line, and over 90% touch fewer than 10 files (Modern Code Review: A Case Study at Google). If your team's PRs are routinely 500+ lines, you're already outside the norm that enables thorough review. Google's guidance says 100 lines is usually reasonable, 1000 is usually too large (Google Engineering Practices - Small CLs). Small changes are reviewed more quickly and more thoroughly, and they're less likely to introduce bugs (Google Engineering Practices - Small CLs). Automation doesn't just speed up review; it makes small changes feasible by catching the small stuff instantly.

The Counter-Argument: "But Tools Can't Understand Context"

I hear it constantly: "Static analyzers produce false positives; they can't understand the intent." That's true — and it's a weak excuse. The objection confuses the tool's role with the human's. A linter isn't supposed to judge design; it's supposed to catch a missing semicolon or a hardcoded credential. When SonarQube flags a security vulnerability, it's not telling you the architecture is wrong; it's telling you there's a known CWE pattern in your code. That's a fact, not an opinion.

But the objection does point to a real limit: tools can't tell you if the design is right. That's why Google says the most important thing to cover in review is the overall design, before functionality, complexity, tests, naming, and comments (Google Engineering Practices - What to look for in a code review). Automation should never be the gatekeeper for design. The risk is that teams set up a quality gate with a SonarQube "A" rating and assume the code is good. It isn't. A clean static-analysis report tells you nothing about whether the abstraction is over-engineered or whether the edge cases are handled.

So I reject the counter-argument as a reason to avoid automation, but I accept it as a reason to design your pipeline carefully. The goal is not to eliminate human review; it's to eliminate the parts of review that are mechanical.

The Table: What Each Tool Should Own

This table is my line in the sand. The left column is non-negotiable automation. The right column is non-delegable human judgment. If your review checklist includes "check for consistent indentation," you're wasting brainpower. If your CI passes with 80% coverage but no one ever looks at whether the tests assert the right behavior, you've automated the wrong thing.

The Speed Factor: Why Automation Is a Velocity Lever

Here's the kicker: automation doesn't just make review cleaner; it makes it faster, and speed is a feature, not a luxury. Google sets one business day as the maximum time to respond to a review request — first thing the next morning — and says a typical change should get multiple rounds of review within a single day (Google Engineering Practices - Speed of Code Reviews). At Google, the median time to first feedback for small changes is under an hour, and the overall median review latency is under 4 hours — far below the 14.7 to 24 hours median approval time reported in Microsoft projects (Modern Code Review: A Case Study at Google).

How do you get to under an hour? Not by making reviewers read 900-line diffs. You get there by ensuring that when a human opens a PR, the trivial stuff is already gone. The linter has run, the security scanner has passed, the build is green. The human's job is to answer one question: does this change improve the codebase? That's a question a machine can't answer.

And there's a deeper benefit. Research at Microsoft found that code review is less about defects than expected — it's about knowledge transfer, team awareness, and alternative solutions (Bacchelli & Bird, ICSE 2013). If your reviewers are spending their time hunting for missing semicolons, they're not sharing knowledge. They're not catching the race condition that a tool can't see. They're not asking the author, "Why did you choose this pattern?" That's the part of review that builds teams, and it's the part that automation should free up.

What I'd Actually Do

Here's my concrete recommendation, and it's not a wishy-washy "it depends." First, adopt a baseline of automation that runs on every PR: a linter (ESLint for JavaScript, Bandit for Python, gosec for Go), a dependency scanner (Dependabot or similar), and a static analyzer (SonarQube or Semgrep). Configure them to block on security issues and on any new issues that violate your quality gate. SonarQube's built-in "Sonar way" gate — no new issues, all Security Hotspots reviewed, 80% coverage on new code, and less than 3% duplication in new code — is a sane starting point (SonarQube). Don't let the gate be the only check, but make it a hard stop.

Second, enforce small PRs. Use branch protection to require that the diff is under, say, 500 lines — Google's own upper bound is 400-500 lines of meaningful change (Google Engineering Practices). If a PR exceeds that, split it. This isn't bureaucracy; it's the single highest-leverage change for review quality. At Google, the median change is 24 lines, and 80% of reviews finish in one iteration (Modern Code Review: A Case Study at Google). That's not because Google reviewers are superheroes; it's because the changes are small enough to understand.

Third, train your reviewers to use "LGTM with comments" when appropriate. Google's technique: approve while leaving unresolved comments when you're confident the author will address them, or when the comments are minor (Google Engineering Practices - Speed of Code Reviews). Don't hold up a merge for a typo. The goal is code health, not perfection — as Google puts it, "there is no such thing as perfect code, only better code" (Google Engineering Practices - Standard of Code Review).

Finally, remember that automation is a tool, not a replacement for judgment. A quality gate that fails on a minor style nit is a quality gate that trains developers to hate the process. A security scanner that flags a true positive but the team ignores it because "it's just a prototype" is a security scanner that's wasted. The tools are only as good as the culture around them.

So stop using humans as linters. Start using them as architects. Your codebase will improve, your developers will be less frustrated, and your reviews will actually catch the bugs that matter.

Sources

• Google Engineering Practices - Code Review - https://google.github.io/eng-practices/review/
• SonarQube (GEANT KB) - https://kb.pert.geant.net/pages/viewpage.action?pageId=412221495
• 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
• 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: Expectations, Outcomes, and Challenges (Bacchelli & Bird, ICSE 2013) - https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/