Big diffs are fine, actually

There’s a recurring argument going around about diff size in the age of agentic coding: keep your PRs small, because a big diff is unreviewable. I think that’s wrong, or at least aimed at the wrong target. My position is that the size of a diff is basically irrelevant. What matters is something else entirely.

The real problem with big diffs

A big diff isn’t hard to review because it’s big. It’s hard to review because it’s hard to get from lines of code to what actually happened in this PR. That gap is the actual obstacle, and it exists in small diffs too - it’s just narrower, so you don’t notice it.

And getting from lines of code to what happened is the entire point of human review. Concretely, that means answering:

• What were we trying to achieve?
• How comprehensive and well-aligned was the plan?
• How well did the implementation match the plan?
• What important decisions were made along the way?

“Important decisions” here almost always means architectural ones - changes with future implications for security, scalability, performance, cost, user experience, or product direction. As an experienced engineer reading a diff, that’s largely what you’re actually hunting for, alongside the (much less reliable) hope of spotting bugs. Human review has never been especially good at finding bugs by inspection; it’s much better at catching decisions that will bite later.

Get a summary instead of reconstructing one

All four of those questions are far easier to answer from a summary than by reverse-engineering them out of a pile of diff hunks. And it turns out LLMs are genuinely good at producing that summary - especially when they can draw on the coding agent’s own logs, not just the final diff. Coding agent logs capture the thought process behind a decision, which is usually the single most useful thing for a reviewer to see.

When we do this - feed the code and the session logs into a model and ask for a review-oriented summary - a PR becomes far easier to understand and sensibly review, without reading a single line of code directly. (We still have the LLM flag the particularly interesting or complex bits worth a closer look, but there’s rarely much of that.)

Where the “keep diffs small” advice comes from

I think the instinct to cap diff size comes from still being anchored to the old way of reviewing: read every line, therefore keep the line count down so the job stays tractable. If you’re going to review that way, keeping PRs small is the only lever you have, and it’s a reasonable one to pull.

But if you’re reviewing the useful bits - the plan, the decisions, the deviations from plan - you get the same effectiveness at any diff size, without the overhead of artificially chopping a feature into pieces to keep each PR “reviewable.” Splitting up a natural unit of work for the sake of line count is a cost with no corresponding benefit once your review process isn’t counting lines anymore. (There are other coding-agent-related reasons splitting features up can bite you, too - that’s a topic for another post.)

Diff size was always a proxy for review cost. Fix how you review, and the proxy stops mattering.