Short answer
How do you reduce code review time when AI agents write the code? Make the diffs small. Reviewers find defects well in 200 to 400 lines at a time and worse beyond that, while AI-heavy teams' pull requests grew 154%. Slice agent work into small, self-proving changes and review time drops.
Your agent finished the ticket in twenty minutes. The pull request it opened touches 34 files and 1,400 lines. It has been waiting for review for two days, because nobody has a free afternoon to read it properly, and everyone knows that “LGTM” on a diff that size means nothing.
If you want to reduce code review time, the most effective lever is still the oldest one: smaller changes. That advice predates AI by decades. What changed is that agents produce large diffs by default, so the rule now needs enforcing by the pipeline, not by habit.
AI made pull requests bigger
Faros AI’s 2025 report, based on telemetry from over 10,000 developers, found that on teams with high AI adoption the average pull request grew 154%. Pull requests merged went up 98%, and review time per pull request went up 91%.
The reason is simple. For a person, every extra line costs effort, so people naturally stop and open a pull request when a piece is done. For an agent, more lines cost almost nothing. Ask it to “add export to CSV” and it will add the export, refactor the helper it touched, update three call sites, rename a variable it disliked and write tests for all of it, in one go.
The review maths hasn’t changed
Review is reading, and reading has limits that don’t care who wrote the code. SmartBear’s study of a programming team at Cisco produced guidance that is still the standard reference: review no more than 200 to 400 lines at a time, keep the pace under 500 lines an hour, and stop after about 60 minutes because performance drops off. Beyond 400 lines, the ability to find defects diminishes. A review of 200 to 400 lines over 60 to 90 minutes should find 70 to 90% of defects.
Translate that into review time per diff, at the fastest careful pace.
That is the real problem with a large agent diff. Nobody blocks five hours for one review, so it either waits until someone has time or gets approved on a skim. Both outcomes are bad: the first is the bottleneck, the second is how bugs reach production. DORA’s 2025 report found AI correlates with rising delivery instability, and large, lightly read changes are one plausible route.
Small diffs fix both at once. A 200-line change fits into the gap between meetings and gets a real read.
Why small diffs matter more when an agent writes the code
When a colleague writes a pull request, the reviewer can lean on shared context: they were in the planning meeting, they know the author’s habits, they can ask why. With agent code, that context is thinner. The person who opened the pull request may only have skimmed it. The reviewer has to reconstruct the intent from the code itself, which takes longer per line.
Small diffs also limit how far a wrong assumption spreads. If an agent misreads the requirement in step one of a 1,400-line change, everything after is built on it. In a 150-line slice, the misreading is visible early and the cost of throwing it away is minutes.
And a small, focused diff is easier for another model to review. An independent reviewer model has the same attention problems a person has, just at a different scale. A focused change with a clear purpose and its own evidence gets a sharper review than a sprawling one. More on that in why the writer can’t be the reviewer.
Bad ways to get smaller diffs
Splitting a big diff after the fact into arbitrary chunks (“part 1 of 4”) doesn’t help. Each part can’t be understood without the others, so the reviewer still has to hold all 1,400 lines in their head.
Setting a hard line limit and letting the agent game it is another trap. Agents are good at satisfying the letter of a rule. You will get pull requests of 399 lines that leave the feature half-wired and broken between merges.
Banning refactoring entirely makes the codebase worse over time. Refactors are fine. They just belong in their own diff.
How to make an agent ship small diffs
Good slicing happens before code is written, not after. These are the rules I would put into any agent pipeline:
- Plan in slices. Before writing code, the agent breaks the ticket into steps, each of which leaves the system working and can be merged on its own. The plan is the first thing reviewed, by a person or a second model.
- One purpose per diff. A behaviour change, a refactor and a dependency bump are three pull requests. Renames and formatting never ride along with logic.
- A size budget with a reason. Aim for under about 400 changed lines, excluding generated files and lockfiles. If a slice can’t fit, the agent says why in the description instead of quietly exceeding it.
- Each slice proves itself. The pull request includes the commands that were run and their results: build, tests, and a check for the slice’s own acceptance criterion. Read more in “all tests pass” is a claim.
- Stack, don’t wait. The agent keeps working on the next slice on top of the current one while review happens, so small diffs don’t turn into idle time.
- Description first. Every diff opens with two or three sentences: what changed, why, and what the reviewer should look at hardest.
From one ticket to a stack of small diffs
- Person
- Agent
- Automated check
Steps as text
| Step | What happens |
|---|---|
| 1. Ticket | Person — acceptance criteria |
| 2. Slice plan | Agent — steps that each leave it working |
| 3. Write one slice | Agent — under about 400 lines |
| 4. Prove it | Automated check — build, tests, criterion check |
| 5. Review | Agent — machine first, person by risk |
| 6. Merge | Automated check |
| Loop | next slice: back from step 6 to step 3 |
| Loop | findings: back from step 5 to step 3 |
A good slice plan for “add export to CSV” might be: add the serialiser with unit tests; add the endpoint behind a flag; add the button and wire it up; remove the flag. Four pull requests of 80 to 250 lines each, every one reviewable in a single sitting.
What to expect when you switch
Smaller diffs mean more pull requests, which can feel like more review work. In practice the total reading time goes down, because each read is effective. SmartBear also found that lightweight, tool-based review takes less than 20% of the time of formal inspection and finds just as many bugs, so the small and frequent style is not a compromise on quality.
The bigger effect is on waiting. A 200-line diff gets picked up within the hour because it fits in a gap. A 1,400-line diff waits for a free afternoon. For agent-written code, where the writing itself took minutes, that waiting is nearly all of the lead time. I go into why review became the constraint in the first place in code review is the new bottleneck.
Small diffs are also the precondition for taking people out of review where it is safe. A machine reviewer, plus checks, plus a narrow, well-described change, is something you can trust for low-risk work. A giant diff is something nobody can trust, human or machine.
Questions
How can I reduce code review time?
Make changes smaller and self-explaining: one purpose per pull request, under about 400 changed lines, with test and build results attached. Put an independent automated review before the human one so the person sees cleaner code.
What is the ideal pull request size?
SmartBear’s study of a Cisco team recommends reviewing 200 to 400 lines at a time, at under 500 lines an hour. Beyond 400 lines, reviewers find defects less reliably.
Why are AI-generated pull requests so large?
Extra lines cost an agent nothing, so it tends to bundle refactors, renames and side fixes into one change. Faros AI measured a 154% increase in average pull request size on teams with high AI adoption.
How do I stop an AI agent from making huge pull requests?
Have it plan the work as a sequence of slices that each leave the system working, give each slice one purpose and a size budget, and make it stack the next slice while the current one is reviewed.