Automate the Boring: Why Your Code Review Tooling Is Failing You

At Google, the median code change is about 24 lines (Modern Code Review: A Case Study at Google). That's the median. Half of all changes are even smaller. If your team is routinely reviewing 500-line pull requests, you're not doing code review — you're doing archaeology. And if your reviewers are spending time commenting on missing semicolons or naming conventions, they're not doing code review at all. They're doing what a machine should do.

Here's the deal: automation isn't the enemy of thoughtful review. It's the enabler. The goal 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 design and logic job, not a linting job. So let's walk through a realistic scenario and see how the right tooling — and the right habits — can turn a chaotic, slow, and frustrating review process into something that actually works.

The Scenario: A Typical Pull Request

Imagine you're a senior developer on a mid-sized team. A junior dev opens a pull request. It's a new feature: a user profile page with an upload form. The PR touches 12 files, adds 450 lines, and includes a few files that are just formatting changes. The description says, “Implemented profile page.” No details. No bug number. No test plan.

Your first instinct might be to dive in and start commenting on the code. But before you do, check the PR size. Google's guidance is clear: 100 lines is usually a reasonable size for a change, and 1000 lines is usually too large (Google Engineering Practices - Small CLs). A 450-line PR is borderline, but when it spans 12 files and includes unrelated formatting changes, it's too big. The first thing you should do is ask the author to split it up. Why? Because small changes are reviewed more quickly, reviewed more thoroughly, and less likely to introduce bugs (Google Engineering Practices - Small CLs). You can't do a good job on a monster PR. Your brain just can't hold it all.

Step 1: Let the Linters and Formatters Do the Nagging

Now, let's say the author splits it into a few smaller PRs. The first one is 150 lines of actual logic. Before you even look at the code, check that the CI pipeline ran. Linters, formatters, static analysis, secret scanners, and dependency scanners should handle style and mechanical checks so human review focuses on logic and architecture (Google Engineering Practices - code review). If you don't have these tools enforced in CI, you're wasting your reviewers' time on things like “please add a space after the comma.” That's not review; that's proofreading.

For JavaScript, ESLint is a pluggable tool that catches patterns and makes code more consistent (ESLint Docs - Getting started). For Python, Bandit processes each file and builds an AST to find common security issues (Bandit (PyCQA) Docs). For Go, gosec scans the AST and does taint analysis for SQL injection, command injection, path traversal, and more (gosec - Go Security Checker). These tools don't replace human review — they make human review possible by removing the noise.

And don't forget dependency scanning. Dependabot can alert you when a new vulnerability is added to the GitHub Advisory Database (GitHub Docs - About Dependabot alerts). That's a huge time saver, because it catches problems before a human ever sees them.

Step 2: Enforce Quality Gates Automatically

But linting is just the start. You should also have static analysis tools that check for deeper issues. SonarQube is a widely used platform that analyzes reliability, security, maintainability, coverage, and duplication (SonarQube (GEANT KB)). It can compute a quality gate — a set of conditions that the code must meet before it's considered “ready for release” (SonarQube Server Docs - Understanding quality gates). The built-in Sonar way quality gate includes conditions like: no new issues, all new Security Hotspots reviewed, new code coverage ≥ 80%, and duplication ≤ 3% (SonarQube Server Docs - Understanding quality gates). If your code fails that gate, the merge is blocked.

That's a powerful thing. It means you don't have to manually check for code smells or test coverage. The machine does it. You, the reviewer, can focus on whether the design is sound.

Step 3: Use Branch Protection and Code Owners to Route Reviews

Now, let's talk about process. On GitHub, you can protect branches so that force pushes are disabled and a certain number of approvals are required before merging (GitHub Docs - About protected branches). You can also require status checks to pass. And you can use a CODEOWNERS file to automatically request reviews from the right people when a PR touches code they own (GitHub Docs - About code owners). That's a huge win for routing: instead of someone manually tagging the right reviewer, the system does it.

Similarly, GitLab Premium and Ultimate support required approvals that enforce code reviews by specified users (GitLab Docs - Merge request approvals). You can specify reviewers by category — backend, frontend, QA, database — and even require security team approval for potential vulnerabilities. That's the kind of automation that makes review predictable.

Step 4: Speed Up the Human Part

But no amount of tooling can fix the human bottleneck. Google sets a maximum of one business day to respond to a code review request (Google Engineering Practices - Speed of Code Reviews). And they note that fast individual responses are more important than the overall speed (Google Engineering Practices - Speed of Code Reviews). That's a direct challenge to the “I'll get to it when I'm done with my own work” mentality.

One technique that helps is “LGTM with comments” — you approve the change while leaving unresolved comments, as long as you're confident the developer will address them or they're minor (Google Engineering Practices - Speed of Code Reviews). That unblocks the author and keeps things moving.

And don't forget the power of the review itself. At Google, fewer than 25% of changes had more than one reviewer, and over 80% finished in a single iteration (Modern Code Review: A Case Study at Google). That's because they keep changes small and use tools effectively.

Step 5: Handle the Reviewer's Comments Responsibly

When you do leave comments, be specific. Label them by severity — nit, suggestion, blocking — and offer solutions (Google Engineering Practices - code review). And if you don't understand something, say so. But here's a key point: if a reviewer says they don't understand your code, the first response should be to clarify the code itself or add a comment, not to explain in the review thread (Google Engineering Practices - Handling reviewer comments). Because the review thread is ephemeral, but the code is forever.

And authors: don't be defensive. The golden rule of code review is to critique the code, not the author (Google Engineering Practices - code review). If you keep that in mind, both sides can stay professional.

Step 6: Measure What Matters

Finally, you need to measure whether your process is working. DORA's five metrics — change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate — are the standard (DORA - Software delivery performance metrics). If your change lead time is long, your review process is probably the bottleneck. If your change fail rate is high, your reviews might be too superficial.

And remember: speed and stability are not tradeoffs (DORA - Software delivery performance metrics). Top performers do well on all five metrics.

Quick tip: Set a branch protection rule that requires a minimum number of approvals and dismisses stale approvals when new commits land. That way, you never merge a PR that was approved before the latest changes.

Sources

• Google Engineering Practices - code review - https://google.github.io/eng-practices/review/
• Google Engineering Practices - Small CLs - https://google.github.io/eng-practices/review/developer/small-cls.html
• SonarQube Server Docs - Understanding quality gates - https://docs.sonarsource.com/sonarqube-server/2026.1/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates
• GitHub Docs - About protected branches - https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• 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
• DORA - Software delivery performance metrics - https://dora.dev/guides/dora-metrics-four-keys/

The most important thing to remember: Code review is a human activity, but it should be a human activity about design, logic, and knowledge sharing — not about formatting and typos. Automate the boring stuff, keep changes small, and your reviews will be faster, better, and more enjoyable.