PRs are ridiculous sizes since adopting AI coding tools and people cannot review them. What do teams do?

Teams that get large AI pull requests back under control do four things. They set a size limit and make the agent split its work. They put an automated first pass on every PR so people never see the obvious problems. They send human attention to the riskiest changes. And they give the agent enough of the team's context that it writes less code, and the right code, in the first place. A review budget is the amount of careful human reading a team can spend per day. AI tools raised the amount of code going in without raising that budget, so the fix has to happen before and around review.

Why AI PRs outgrew review#

DX studied more than 400 companies, and its methodology pairs survey answers with PR telemetry. Median PR size "nearly doubled, growing from 44 lines to 72 lines per pull request between July 2025 and June 2026" (DX, June 2026). By September, "more than 40% of pull requests on GitHub started with an agent's first draft, up from 17% in March" (GitHub Octoverse, October 2026). The same report found that about 87 percent of those agent PRs changed more than one file, against 79 percent of the rest.

Size is also where agent PRs fail. A January 2026 study of more than 33,000 agent-written PRs found that "not-merged PRs tend to involve larger code changes, touch more files," and often fail CI (Ehsani et al., 2026). We put a number on that cost in cost per merged PR.

Set a size limit and split the work before review#

Google's public review guide says "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large", where a CL is a change list. It adds that reviewers "have discretion to reject your change outright for the sole reason of it being too large" (Google engineering practices). Teams write the limit down and let reviewers send big PRs back without guilt.

Splitting is easier now that GitHub supports it directly. Stacked pull requests are a chain of small PRs where each one builds on the one below it. GitHub's documentation describes the benefit plainly: "instead of one large pull request, you get a set of smaller pull requests". Each one has its own diff, so "teammates can review and approve each layer independently," and the whole stack can land as one merge (GitHub docs).

The agent has to be told to work this way. Put the size rule in the instructions file it reads, such as CLAUDE.md or .github/copilot-instructions.md, and ask for a plan with one PR per step before any code. If agents keep ignoring those rules, this answer covers why and what to do.

Put an automated first pass on every PR#

A human should not be the first reader of an agent's diff. GitHub reports that use of AI-assisted code review grew more than 90 percent in a year (Octoverse, linked above). The tools are built to assist human reviewers. GitHub says Copilot's reviews "do not count toward required approvals" by default, and tells teams to "supplement Copilot's feedback with a human review" (GitHub docs). Anthropic's Code Review runs several agents over the diff and checks their findings before posting. "A review never approves or blocks the pull request, so the decision to merge stays with your team" (Claude Code docs).

A first pass that only reads the diff will miss what the diff does not show. Unblocked's code review also reads earlier comment threads on the PR and pulls in Slack and Teams conversations that mention it. It checks claims about dependencies before it posts (Unblocked docs). Leah Langford, Senior Software Engineer at Optro (formerly Auditboard), describes the effect on her team: "Unblocked catches things I probably would've missed and honestly speeds up the whole review cycle. It flags issues early, so by the time my peers look at the PR it's already cleaner, and we all avoid a bunch of unnecessary back-and-forth."

Send human attention by risk, not by line count#

Size is not risk. A 900-line PR that renames a field is less dangerous than a 12-line change to how payments settle. Risk routing is the practice of deciding who reviews a PR, and how closely, from what it touches rather than how long it is.

First, take machine-made files out of the diff. Unblocked skips files marked linguist-generated or linguist-vendored in .gitattributes, so lockfiles and generated clients do not eat the review (Unblocked docs). Second, write down what your team counts as risky. With Unblocked's risk assessment you list policies in .unblocked/risk-policies.yaml, and each PR gets a score from lowest to highest with a reason. A team can turn on auto-approval for low-risk PRs with no findings and keep senior reviewers on the rest (Unblocked docs). The docs warn that "Database schema changes are high risk" is too broad, while a policy naming one ledger table, and why it cannot be repaired, is useful.

A routing table might look like this:

Fix what goes into the agent#

The biggest PRs often come from an agent that did not know enough. It cannot see that a helper already exists, that a pattern was dropped after an incident, or that another team owns the module. For example, it rebuilds a retry helper the team already has, and touches files it should have left alone. Reviewers then spend their time restoring that context, one comment at a time.

Agents need the same background a new hire picks up over months: past PRs, the Slack thread behind a decision, the ticket that set the scope. Unblocked gives coding agents that background through MCP in Claude Code, Cursor, and GitHub Copilot in VS Code and JetBrains. With Data Shield on, each answer holds only what the asking engineer is allowed to see. Stop babysitting your agents walks through what changes when the agent starts with the full picture, and the AI productivity paradox explains why more code does not mean more shipped.

Start this week with one change. Pick the size limit your reviewers already wish they had, write it into the agent's instructions, and send back the next PR that breaks it.