Why I Stopped Accepting Big PRs (and You Should Too)

I used to think a 400-line pull request was normal. Until I reviewed a 1,200-line monster that broke our payment flow in production. That's when I looked at Google's data: their median change is about 24 lines, and over 10% of changes are a single line. If you're routinely reviewing 500-line PRs, you're not reviewing—you're skimming.

The 24-Line Reality Check

Picture this: you're a tech lead at a mid-sized SaaS company. Your team ships a feature that touches 30 files and 1,200 lines. The PR sits in review for three days. Reviewers skim, leave a few nits, and approve because they're exhausted. Sound familiar? That was my life. Google's study found that over 80% of reviews finished in a single iteration, and the median time to first feedback was under an hour for small changes. Small changes get reviewed faster, more thoroughly, and introduce fewer bugs.

So what's the right size? Google says 100 lines is usually reasonable, 1000 is too large. But their own median is 24 lines. That's not a coincidence—small is the default, not the exception. When I see a 500-line PR now, I ask the author to split it. If they push back, I remind them of the time we shipped a bug because nobody noticed a missing null check in the middle of a mega-PR. Not fun.

What Actually Matters in Review

When you get a small PR, what should you look at first? Google says the most important thing is the overall design—before functionality, complexity, tests, naming, and comments. Design is where big problems hide. A 24-line change that breaks the architecture is worse than a 500-line change that's just verbose.

But design isn't the only thing. Reviews should cover functionality, code quality, maintainability, testing, security, performance, architecture, and documentation. For a 24-line PR, that's manageable in 20 minutes. For a 500-line PR, you'd need a full afternoon, and you'd still miss things.

Here's a concrete example from my own work: I recently reviewed a 30-line Python function that handled user input for a new endpoint. I checked design—it fit the existing pattern. Security—I looked for input validation and SQL injection, and I ran a quick mental scan of OWASP Top 10 items like Injection (A05) and Broken Access Control (A01). Tests—they were there, covering edge cases. All doable in 20 minutes. For a 500-line PR, that level of scrutiny is impossible.

How to Actually Get Small PRs

If you're a developer, you're not going to magically produce 24-line changes. You have to break your work down. Google says to split larger PRs by concern—not by file or time. One PR for the database migration, another for the API endpoint, a third for the frontend. That's not always possible, but it's a goal.

As a reviewer, you can enforce small PRs with branch protection rules. On GitHub, require a certain number of approving reviews and require review from code owners. Dismiss stale approvals when new commits are pushed—that forces people to keep PRs small and focused. On GitLab Premium, require approvals from specific users, even security teams for potential vulnerabilities.

But tools only go so far. The real change is cultural. You need to make it clear that a 500-line PR is not acceptable, and that a 24-line PR is normal. If you're a lead, model that behavior. Break your own work into small chunks. Review small PRs quickly—within one business day, ideally. When you respond quickly, you ease frustration and keep momentum going.

What About the Big Stuff?

You might be thinking: “Some changes are inherently big. A new feature, a refactor, a security fix.” True. But Google's data shows that even large changes can be split. In their study, about 90% of changes touched fewer than 10 files. That's a rule of thumb: if you're touching more than 10 files, you're probably doing too much in one PR.

For those rare big changes, you still need to review them, but you need to be smarter. Use automation to handle the mechanical stuff. Linters, formatters, static analysis, secret scanners, and dependency scanners should handle style and mechanical checks so human review focuses on logic and architecture. Tools like SonarQube can catch bugs, vulnerabilities, and code smells automatically, and a quality gate can block a merge if new code has issues. For security, run gosec on Go code (it does taint analysis for SQL injection and path traversal) or Bandit on Python (it builds an AST and runs plugins). Semgrep can scan any codebase for insecure patterns.

But automation is not a substitute for human review. It's a filter. The human review should focus on design and logic, not on whether you used tabs or spaces.

Quick tip: If you're a reviewer and a PR feels too big, don't approve it just because the code looks okay. Ask the author to split it. You'll both be happier.

Bottom line

Stop reviewing big PRs. Aim for 24 lines, not 500. Use automation to filter mechanical issues, and focus your human review on design and logic. Small PRs are reviewed faster, more thoroughly, and with less friction. That's the best move you can make for your codebase's health.

Sources:

• 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
• Google Engineering Practices - What to look for in a code review - https://google.github.io/eng-practices/review/reviewer/looking-for.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
• SonarQube Server Docs - Understanding quality gates - https://docs.sonarsource.com/sonarqube-server/2026.1/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates