A rant about oversized pull requests did the rounds on Hacker News this week, and every engineering leader I know would nod along to it. I think it aims at the wrong target. Size was always a proxy for reviewability, and AI has broken the proxy. The teams struggling right now are not drowning in big pull requests. They are drowning in all of them.

Small PRs were never asked for because they are easier to write. They were asked for on behalf of the reviewer. That heuristic worked because writing code was the expensive part and reading it was cheap by comparison. Two hundred lines took most of a day to produce and twenty minutes to read, so the economics held without anyone having to think about them. That ratio has now inverted, and the heuristic has quietly stopped describing anything useful.

You can see the failure in the most common advice offered in response, which is to ask the agent to split the work up. One commenter on the thread called the result exactly right: you get large stacks of pull requests that are individually incomprehensible. Five four-hundred line PRs are more review overhead than one two-thousand line PR, because now somebody has to hold context across five queue entries instead of one. The constraint was never the diff. It was the reviewer's attention, and slicing the work thinner spends more of it, not less.

So the real problem in teams adopting AI at scale is volume. Not any single change being too large, but the aggregate arriving faster than any human process was ever designed to absorb. If your answer to that is to ask people to try harder, you have a queue that only pretends to be a quality gate.

What we should actually be checking

Three things matter in a review now: whether the change is risky, whether it does what we agreed it would do, and whether it is any good. Reading the lines is how we used to get at those answers. It is no longer the only way, and for the first two it is no longer the best way.

Line-level reading is the part machines do better than we do. Style, null handling, error paths, injection surfaces, the case nobody thought about. A machine does that check at three in the morning on the fortieth pull request of the day with exactly the same rigour it applied to the first. Humans are poor at this work in volume and get worse as the queue lengthens. If your reviewers are still reading diffs hunting for defects, you have given people the machine's job and kept all of the fatigue for yourself.

What does not automate is judgement. Does this change do the thing we agreed to do, or something adjacent that happened to be easier? What is the blast radius if it is wrong? Should this exist at all, or are we now maintaining two of something? Does it fit the shape of the system we want to be running in two years? That is taste, and taste is the scarcest thing in the review queue.

The uncomfortable part

Most teams cannot automate the adherence check, because there is nothing to check against. The ticket says "add CSV export". The acceptance criteria were discussed in standup and never written down. If the specification lives in a staff engineer's head, then a review that verifies the code against the specification was never really happening, and volume has simply made that visible. This is the same pattern we keep running into: AI does not create the management problem, it removes the cover.

Tests deserve the same scrutiny for the same reason. Models are very good at producing things that look like tests, and occasionally at encoding the wrong behaviour as the specification. That is where human attention belongs now, along with the interfaces and the boundaries. Not the implementation.

Which brings it back to leadership, where it usually ends up. If review is a mandatory gate that you have not funded, you will get rubber stamps, and you probably already have them. If you celebrate throughput while treating review as an unfunded tax on everyone else's week, the pull request queue is telling you precisely what you have chosen to reward.

The rant should read differently. Not stop sending me huge pull requests, but stop sending me changes I cannot assess the risk of. Size was never the point, and shrinking it was never the fix.