AI Code Review for Large Pull Requests: Reading the Diff Nobody Reads

The pull request nobody wants to open

Every engineering team has one in flight right now: eighty files, four thousand lines, a title that begins with "refactor" and a description that says "see commits". It has been open for six days. Two people have approved it without reading it. One person left a comment about a variable name on line 12 of the first file and then quietly stopped.

Large pull requests are the place where code review stops being review and becomes theatre — and they are also where AI review is most often oversold. The pitch writes itself: the machine does not get tired, so let it read the four thousand lines. That is true and almost entirely beside the point. A reviewer that reads everything and says everything is not solving the large-PR problem; it is adding to it.

This post is about what actually goes wrong in large diffs, what an AI reviewer has to do differently to be useful on them, and how to configure PURA so a big PR gets a genuinely shorter path to merge rather than a longer comment thread.

Why large PRs defeat human review specifically

It is worth being precise about the failure mode, because it determines what help is actually useful. Reviewer attention does not degrade gracefully with diff size — it collapses. The pattern is consistent across teams:

• Attention front-loads. The first few files get real scrutiny. By the twentieth, the reviewer is scanning for syntax and skipping logic. The most dangerous change in a large PR is statistically likely to be in the part nobody read.
• The important change hides behind the boring one. A PR that renames a function across sixty files and changes its behaviour in one of them is nearly impossible for a human to review, because the signal is one file in sixty of visually identical noise.
• Approval becomes social. Past a certain size, the cost of reviewing properly exceeds the cost of trusting the author. Teams do not admit this, but the approval-to-read ratio in large PRs tells the story clearly.
• Feedback arrives too late to act on. By the time someone has read enough of a four-thousand-line PR to raise a structural objection, the author has moved on and the rework cost is high enough that the objection gets deferred to a follow-up that never happens.

Notice that only the first of those is a stamina problem. The other three are structural, which is why "an AI that never gets tired" is a partial answer at best.

What a reviewer has to do differently at scale

A reviewer that is useful on a large PR does four things that a reviewer tuned for twenty-line diffs does not.

It separates mechanical change from semantic change. The single most valuable output on a large PR is the sentence "fifty-eight of these files are a pure rename; three contain behavioural changes, here they are". That reframes an unreviewable diff into a reviewable one. It is also exactly the kind of judgement a machine can make reliably and a tired human cannot.

It budgets its own output. A fixed comments-per-file instinct produces ninety comments on a large PR, which guarantees the PR is merged unread. Restraint has to scale inversely with size: the bigger the diff, the higher the bar for saying anything, and the more the value shifts from line comments to a structured summary. We made the general case for this in the piece on false positives and noise; on large PRs it is not a preference, it is the difference between being read and being ignored.

It reasons beyond the diff. Large PRs touch shared surfaces, and the consequences of those changes are usually not in the diff at all. A reviewer that can look up call sites and consumers is doing work no reviewer of the diff alone can do — the same capability that makes review viable in monorepos, applied to a different shape of problem.

It orders its findings by consequence. Not by file path, not by line number, not by the order it happened to read them. On a diff a human will only partially read, the ordering of the output is doing as much work as the content of it.

Configuring PURA for large pull requests

PURA runs inside your own infrastructure, which removes the first practical objection to pointing a reviewer at your largest diffs: a four-thousand-line PR across your platform code is precisely the payload most teams are least willing to send to a third-party SaaS. Self-hosting makes full-context review of large changes a security-team conversation you can actually win — the argument we set out in the case for self-hosted AI review.

From there, four settings do most of the work:

• Raise the severity bar with diff size. Configure large PRs to surface only high-confidence, high-consequence findings, and let style and nit-level feedback drop entirely. A style comment on file forty of eighty has never once changed an outcome.
• Ask for a change classification up front. Instruct the reviewer to open its summary by grouping files into mechanical, additive, and behaviour-changing. This is the highest-leverage single instruction you can give it for large diffs, and it turns the review output into a reading order for the human.
• Make shared-surface changes explicit. Require the summary to name any modified exported type, public function, schema, or migration, along with the consumers it found. These are the findings that justify the review existing.
• Scope model routing by path. Large PRs concentrate cost, and review spend tracks volume. Point the strongest model at the high-stakes directories inside the diff and something cheaper at generated files and fixtures, then watch the number with per-repository budgets so the finance side of a big refactor stays predictable.

The uncomfortable part: this is a symptom

Everything above makes large PRs survivable. None of it makes them good, and a tool that makes a bad practice comfortable is not an unambiguous win.

Large pull requests are usually a batching failure rather than a review failure. They happen because the work was not split, because a branch lived too long, because a refactor and a feature travelled together, or because the review queue was slow enough that authors stopped opening PRs early. That last one is worth dwelling on: slow review causes large PRs, and large PRs cause slow review. It is a loop, and the review bottleneck is where it starts.

The honest position is that AI review helps at both ends of that loop, but differently. On the diff you already have, it makes an unreviewable PR partially reviewable. On the next one, fast and consistent feedback on small PRs is what makes authors willing to open them small in the first place. The second effect is worth more than the first, and it is the one teams under-measure.

So the recommendation comes with a caveat. Configure the reviewer to handle your large PRs well, because you will keep having them. But if the reviewer is reporting that most of your PRs are large, treat that as the finding, not the workload. The review tool is telling you something about how the work arrives, and no amount of reading speed fixes that.

What good looks like on a big diff

A well-configured review of a four-thousand-line PR should be short. Something close to: a one-paragraph summary of what the change does, a three-way split of the files by kind of change, a named list of shared surfaces touched with their consumers, and between zero and five line comments on the things that genuinely matter.

That output is an order of magnitude more useful than ninety comments, and it takes a human four minutes to act on. The measure of whether it is working is not how much the reviewer found. It is whether the human reviewer who reads it afterwards knows exactly which three files to open — and actually opens them.