The PR size that makes review work again

Once a PR goes past 300 lines, I'll be honest: I stop reviewing it myself.

That's a big part of why there's a number I keep coming back to: 300 to 500 lines.

When I hold PRs to that size, they tend to get approved in one turn or none. Not because they're trivial, but because the reviewer can understand the whole thing in a single sitting. The conversation is about whether the change is right, not about whether anyone has the energy to read it.

The honest version of how review works now

Reviewing PRs is slowly becoming more complex over time, to the point where engineers just give in and approve. And that's if, as an engineer, you're still at the stage where you haven't fully trusted that the code your teammates generate with their own AI agents truly meets the quality bar.

Yes, AI agents can cheaply write code fast. But agents sometimes lack a lot of context, especially in large codebases with plenty of hidden business and domain context, so we engineers still feel the need to be in the loop. There's also a meta question about whether that even matters at this point, but that's a different conversation for a different day.

For now, here's what tends to happen with me past that point. I point my agent at the PR to do an adversarial review, test the changes and approve. Which just leaves agents reviewing other agents' work. I guess this is the world we're definitely heading towards.

I'm not presenting that as best practice. I'm sharing it because I suspect a lot of engineers do something similar and don't say so. And it shows the real problem: once a PR crosses a certain size, the size decides how much human attention it gets, not the risk of the change.

Why big diffs fail

The opposite end can be worse than people admit. AI makes 2,000-line PRs cheap and fast to produce. In my experience, they often get minimal review. Few people can give them proper review in one sitting, so human reviewers can end up skimming, trusting the code and approving. That's the quiet bottleneck with AI-generated code. And it isn't only people. Agent reviewers can miss things in very large diffs too. What slips through is often the remaining chunk of unchecked output that, over months, wears the codebase down.

So there are two thresholds I work with. Under 300 lines, a human can realistically read the change. Under 500 lines is the ceiling I try to keep to for anything, even if an agent is doing most of the review.

PR stacks have a cost too

Splitting into stacks helps, up to a point. One of my PR stacks reached 16 PRs. That sounds disciplined until you look at the mechanics. Our tooling only runs CI after approval and has no auto-merge, so a tweak to PR 1 rebases the other 15 and rebuilds all of them. You spend compute and patience to review tiny pieces.

So keep each PR small enough to read, and each stack short enough to rebase cheaply. Around six PRs is a reasonable ceiling, and after that, wait for merges before adding more.

Put it in the rules

I'd rather not rely on willpower for this. Write it into the agent rules: atomic commits, one concern per PR, no giant diffs. In my experience, agents are good at following a rule they've been given.

Small PRs aren't about style. They're how you keep review real, for humans and for the agents doing more of it every month.