Stop Your AI Agent Writing 1,000-Line PRs

Coding agents emit 1,000-line PRs reviewers rubber-stamp. Fix diff size at generation, not review: specs, stacked PRs, and feature flags.

The fix for a coding agent that writes 1,000-line pull requests is not a faster reviewer. It is a smaller diff, decided before the agent writes a line. GitHub's own engineering team describes the failure plainly: a large AI-generated pull request becomes hard to review, so it just sits there. The high-value move is to cap change size at generation time, not to speed up review after the diff already exists.

Sources: GitHub: Turn one giant AI-generated pull request to a reviewable stack

Keep two problems apart. One is review throughput: how fast a reviewer clears a queue. The other is change size: how many lines land in a single unit of review. Most tooling attacks throughput with AI reviewers and diff summaries. This post is about the second problem, because a diff that is too big to review well stays too big no matter how fast anyone reads it. That thesis points toward a category we build in, so judge the mechanism first and treat any tool, ours included, as one way to run it.

Why big diffs get rubber-stamped

Reviewer attention has a measured ceiling. SmartBear's best-practice research, drawn from a study of a Cisco Systems programming team, recommends reviewing no more than 200 to 400 lines of code at a time, because the ability to find defects drops beyond that. A review of 200 to 400 lines over 60 to 90 minutes should surface 70 to 90 percent of the defects present. Push harder and the same research reports a significant drop in defect density found once a reviewer exceeds 500 lines of code per hour. A 1,000-line agent diff is already outside the range where review does its job.

Sources: SmartBear: Best Practices for Code Review

Volume makes it worse. GitHub reports that Copilot code review has processed more than 60 million reviews, growing tenfold in under a year, and that more than one in five code reviews on GitHub now involve an agent. The changes arriving for review are both larger and more numerous. A January 2026 study, More Code, Less Reuse, found agent-generated code carries more redundancy and more technical debt per change than human-written code, and that reviewers tend to express more neutral or positive sentiment toward those contributions despite the quality issues. Bigger diffs, more of them, and a reviewer who feels fine approving them: that is how the rubber stamp forms.

Sources: GitHub: Agent pull requests are everywhere. Here's how to review them, More Code, Less Reuse (arXiv 2601.21276)

The failure has a shape teams recognize. GitHub's engineering account of the problem notes that when a pull request grows past what a reviewer can hold, it becomes hard to review and simply sits there. Reviewers lose context, feedback quality drops, and under-reviewed code eventually ships on stretched merge timelines. The diff did not get better while it waited; it got approved because the queue needed clearing. Size, not effort, decided the outcome.

Sources: GitHub: Turn one giant AI-generated pull request to a reviewable stack

Fix size at generation, not at review

The lever is the prompt and the plan, not the review stage. By the time a 1,000-line diff exists, every option is bad: reject it and throw away the work, or approve it and skim. Deciding the shape of the change before the agent writes it costs nothing and removes the dilemma. Four practices do the work: start from a spec, split the spec into small pull requests, keep refactors out of behavior changes, and use feature flags plus stacked pull requests to land partial work safely. Each one caps size upstream, where it is cheap, instead of downstream, where it is not.

Start from a spec, then split it into small PRs

A spec turns a vague task into an ordered list of small, independently shippable changes. Instead of one instruction that invites one giant diff, you write down the target behavior, then have the agent produce a plan that breaks the work into roughly 100-line pull requests, each with a single stated purpose. Spec-driven development covers how to write that spec so the agent cannot wander off it. The plan is the size control: if a step cannot be described in one sentence, it is two steps. Giving the agent a durable place to keep that plan and the decision behind each step, a private, persistent memory layer like memx.app, keeps later pull requests consistent with the ones already merged.

GitHub's guidance on reviewing agent work names the same triggers from the other side. Ask for a smaller pull request when the diff touches more than five unrelated files, when nobody can state the purpose of the change in one sentence, or when the agent produced no implementation plan at all. Those are size-and-scope signals, and each one is easier to enforce at planning time than to catch at review time.

Sources: GitHub: Agent pull requests are everywhere. Here's how to review them

Never mix a refactor with a behavior change

One pull request should either change behavior or preserve it, never both. A refactor that renames and moves code produces a large diff that is safe precisely because nothing observable changes. A behavior change is usually small, and it is where the risk lives. Combine the two and the reviewer has to separate the handful of risky lines from hundreds of safe ones by eye, which is the exact task the 400-line ceiling says fails. Ship the refactor first as a no-behavior-change pull request, confirm the tests still pass without edits, then build the feature on the clean base. The behavior change then arrives as a small, legible diff a reviewer can actually reason about.

Use feature flags to merge partial work

Feature flags let you merge unfinished work in small pieces without shipping it to users. The alternative, holding all the work on a long-lived branch until it is complete, is what produces the giant pull request in the first place. Release toggles, as Pete Hodgson describes on martinfowler.com, allow incomplete and un-tested code paths to reach production as latent code that stays off until you turn it on. Each slice of the feature merges to main as a small, reviewable pull request behind the flag, and the branch never grows into a 1,000-line merge. The work still gets done in full; it just arrives in reviewable increments.

Sources: Pete Hodgson: Feature Toggles (Feature Flags)

Stacked pull requests are the mechanical enabler

Stacked pull requests are the tooling that makes small-PR discipline practical. GitHub moved them to public preview on July 30, 2026. A stack is an ordered series of pull requests where each targets the layer below it, so a large change lands as focused layers instead of one diff. You open any pull request in the stack and review only that layer's diff, then merge the latest ready layer to land it and every unmerged layer beneath it in one operation, while the pull requests above stay open and automatically rebase. Your existing branch protections and required checks still govern what reaches main. GitHub frames the payoff by owner: data is reviewed by a data owner, UI by a UI owner, each layer small enough to hold in a reviewer's head.

Sources: GitHub Changelog: Stacked pull requests are now in public preview, GitHub: Turn one giant AI-generated pull request to a reviewable stack

The reason small PRs used to be rare is the reason stacked pull requests matter. The old choice was a single monolithic change that nobody could review, or a manual chain of dependent branches that needed constant syncing and conflict resolution every time an earlier layer moved. That manual overhead is exactly why teams gave up and shipped the big diff. Stacking automates the rebase and retarget across the chain, so keeping work small stops being a tax the author pays and starts being the path of least resistance.

Sources: GitHub: Turn one giant AI-generated pull request to a reviewable stack

This is about size, not review speed

To be exact about the boundary: this is change-size control, which happens before review, and it is distinct from review throughput, which happens during it. Reviewing code at AI speed deals with clearing a fast-moving queue. Nothing here speeds up a reviewer. It changes what the reviewer receives, so each unit falls inside the range where human review actually catches defects. The two compound: small units make fast review trustworthy, and no amount of review speed rescues a diff that was too big to read. Pair size control with real verification, because a small pull request still needs tests that check behavior rather than restate it, which testing AI-generated code covers.

Where phase gates cap the diff for you

Phase-gated TDD caps diff size as a structural side effect. TLM Forge runs a spec audit before code, then drives the work in phases where each phase is a small, independently verifiable unit: a failing test, the change that makes it pass, and a review before the next phase opens. Because a phase cannot proceed until its slice is verified and reviewed, the diff that reaches a human stays bounded by construction rather than by a reviewer's willpower. That is the same discipline the practices above ask for, enforced by the process instead of remembered by the author. It does not replace stacked pull requests or feature flags; it produces the small, ordered units those mechanisms were built to carry.

None of this asks the agent to write less code overall. It asks the code to arrive in units a human can actually review. Decide the shape before generation, keep refactors and behavior changes apart, hide partial work behind flags, and let a stack carry the layers. The reviewer stops rubber-stamping because there is nothing left in front of them that is too big to read.