The pull request too big to review because an agent wrote it

An engineering manager at a healthcare software company described a pull request that landed on a Friday. The ticket had been small, a change to how one report was generated. The diff was over two thousand lines. The agent had refactored adjacent code, renamed variables it thought were unclear, added helper functions, and touched six files that were not in the original scope. All of it looked reasonable. None of the reviewers wanted to be the one to hold up a change that was, by every appearance, an improvement. So it was approved with comments like “looks good, big one.” A bug in one of the untouched-by-the-ticket files surfaced two weeks later.

Review quality falls off a cliff with size

There is a well-known and unforgiving fact about code review. A reviewer who does a careful job on a fifty-line change does a much worse job on a five-hundred-line change, and barely reads a two-thousand-line one. Attention does not scale with diff size. Past a certain point the reviewer is skimming, and both people know it, and the approval becomes a social act rather than a technical one.

Agents make large changes almost free to produce. Ask for a small fix and you can get a sprawling one, because the agent has no cost sense about how much a human can hold in their head. It will happily refactor things you did not ask it to touch, and each individual edit will look defensible. The problem is not any single line. The problem is that the whole thing is now too large to review at the quality the code deserves, and the reviewer’s honest options are to skim it or to spend an afternoon they do not have.

This is a new failure mode. It used to be that a two-thousand-line pull request signaled that the author had bitten off too much, and a lead could push back on scope. Now the size can come from the tool, not the person, and it arrives looking tidy. The scope crept while nobody decided to expand it. The review that follows is theater.

Constrain the change, not just the prompt

The lesson teams learn is that change size is a review risk they have to manage on purpose, because the tool will not manage it for them. A small ticket should produce a small diff. When it does not, that is a signal to split the work, not to widen the review.

What teams do to keep AI-generated changes reviewable.

Cap the scope of a change to the ticket, and reject unrelated refactors that rode along, even good ones, into a separate pull request.
Ask the agent to make the smallest change that solves the problem, and treat a sprawling diff as a prompt to redo, not a bonus.
Split large changes into a reviewable sequence, so each piece can be understood on its own.
Separate mechanical changes, like a rename, from behavioral ones, so the reviewer is not hunting for the two lines that matter among a thousand that do not.
Measure review quality by whether the reviewer could explain the change, not by how fast it was approved.

The agent’s speed is real. It just moved the bottleneck from writing the code to understanding it, and a huge diff is where understanding goes to die.

How we approach it at Density Labs

When we help teams adopt AI-assisted development, one of the first things we look at is change size, because it quietly predicts review quality. A workflow that produces large diffs will produce weak reviews, no matter how disciplined the people are, because human attention does not stretch to cover a tool that never tires.

Our AI Opportunity Assessment is a fixed two-week engagement, priced at $2,500, that scopes the real work of shipping AI-assisted, including the workflow around it. Part of that is deciding how changes stay small enough that a review still means a human read and understood the code, rather than waved it through because it was too large to argue with.

The agent can write two thousand lines in a minute. A person still has to understand every one of them, and that is the part that sets your pace.