A pull request that touches 40 files cannot be reviewed the way a 5-file pull request is reviewed, and trying to anyway is exactly how a large AI-generated change slips through with real defects inside it. The method that actually works is to check the PR’s own history and plan first, split the read-through by category (refactor versus functional change, never both at once), and read bottom-up, function by function, rather than trusting that a coherent top-to-bottom narrative means every individual function inside it is correct. None of this requires more willpower than a normal review. It requires a different shape of review, because a 40-file diff is a different object than ten 4-file diffs.
This matters more than it sounds like it should, because the evidence points the wrong direction from what intuition suggests: larger AI-generated changes carry more risk per line, not less, and the review process most teams already have tends to break down exactly when it is needed most. This method is one part of the wider discipline covered in working with an AI coding assistant; once the read is done, it feeds into the same ten-point checklist used for any AI-written change before merge.
Why large AI PRs carry more risk per line
Research comparing AI-assisted and human-only pull requests has found that AI co-authored code contains roughly 1.7 times more issues per change than comparable human-only code. That gap alone is a reason for caution. Combine it with a second, separately documented finding, that review time on the largest pull requests tends to plateau rather than scale with size, and the actual risk becomes clear: the pull requests most likely to contain a meaningful defect are also the ones least likely to receive review effort proportional to their size. Reviewers do not read a 40-file PR forty times more carefully than a 1-file PR. Past a certain size, most reviewers’ engagement flattens out, and the review becomes closer to a skim than a read.
That plateau is not a character flaw in reviewers. It is a predictable response to an unbounded task, and the fix is a method that bounds the task differently rather than a demand for more diligence.
Before you read a single line, check the PR’s own history
Two quick checks, before touching the code, change how much scrutiny the rest of the review needs.
Has this PR been through previous rounds, and was it responsive to feedback? A PR that has already absorbed one or two rounds of review comments and adjusted accordingly carries a different risk profile than one submitted cold and unreviewed. If this is the first pass, budget for it to need more, not less.
Was there a clear implementation plan, or did the agent just start writing code? A PR built against a stated plan (files it intended to touch, a stated approach) is generally easier to verify against its own stated intent. A PR with no visible plan and 40 changed files is a request to reverse-engineer the intent from the diff itself, which is a slower and less reliable review.
Split the read-through by category, not by file order
The single highest-leverage structural habit for a large diff is refusing to review a refactor and a functional change together, even when the agent bundled them into one PR because it seemed efficient at the time. Structural changes (renames, reorganizing files, extracting a function without altering its behavior) can be verified quickly by confirming behavior did not change. Functional changes (new logic, changed behavior, a different return value under some condition) need the opposite: close reading of what actually changed, not a quick diff of “same shape, different location.”
Mixing the two in one read-through is exactly how a genuine behavior change hides behind what looks like an innocuous rename. Read the structural changes as one pass, confirm nothing behavioral moved with them, then read the functional changes as a separate pass with full attention.
Read bottom-up, function by function
AI-generated code can read as a coherent, plausible narrative from the top of a file to the bottom, in a way that masks individual functions that do not actually hold up on their own. The practical fix is reading each function independently rather than following the file’s narrative flow: does this specific function, taken on its own, do what its name and its callers expect, regardless of how naturally it reads in sequence with the functions around it. This catches the case where an assistant writes five functions that together tell a convincing story, but one of the five silently calls an invented method or a real function with the wrong signature that the surrounding narrative papers over.
For diffs large enough to risk exceeding a reviewer’s own working context, the same principle scales to tooling: reviewing each changed file independently and aggregating the results catches issues that get lost when a review tries to hold all 40 files in context at once, whether that review is done by a person or assisted by another tool.
When splitting after the fact is worth it, and when it costs more than it saves
The advice to keep pull requests small, the evidence here is that teams keeping PRs near 50 lines ship meaningfully more code over time than teams that routinely let PRs exceed 200 lines, is correct advice for the next PR. It is not always practical advice for the one already sitting in the review queue. Splitting an already-complete 40-file PR into smaller pieces after the fact means re-establishing which files depend on which others, which is itself real work, and sometimes more work than reviewing the PR as a whole using the method above.
The judgment call is whether the files genuinely separate into independent concerns (in which case splitting first is worth the overhead) or whether they are load-bearing on each other (a schema change and every file that reads that schema, for instance), in which case reviewing as a single unit with the category-split and bottom-up methods above is the faster, safer path.
FAQ
Should I just reject any AI-generated PR over a certain file count?
Rejecting outright trades one risk for another either the work does not get reviewed at all, or it gets resubmitted in a way that hides the same scope inside several smaller PRs that individually look fine. The method above is generally more effective than a hard size limit.
Does asking the agent to split its own PR before review actually work?
Sometimes. If the changes genuinely separate into independent structural and functional pieces, asking for that split before review is worth trying first. If the files are load-bearing on each other, the split will often just move the same complexity into a different shape.
What is the single most important thing to check first in a large AI PR?
Whether a refactor and a functional change are bundled together. Separating those two categories before reading anything else changes how much scrutiny each part of the diff actually needs.
Is a large AI-generated PR always worse than a large human-written one?
The research comparing the two found more issues per change in AI co-authored code specifically, but a large PR from any source, human or AI, carries the same fundamental review-time-plateau risk. The size is the bigger risk factor; the authorship changes the odds, not the underlying dynamic.
How do I know if the PR actually had an implementation plan or the agent just started coding?
Check the PR description and any linked issue or conversation history for a stated approach before code was written. Its absence is not disqualifying on its own, but it means the reviewer has to reconstruct intent from the diff, which takes longer and is less reliable.
