Stacked Pull Requests Relocate AI Mega-PR Review Cost

AI coding assistants like Copilot, Cursor, and Devin regularly produce diffs that blow past the change-size range where human review stays effective. The instinctive fix is stacked pull requests, which decompose one massive change into a chain of smaller, linked branches. But stacking does not eliminate the review cost of an AI-generated mega-PR so much as relocate it, trading one unreadable diff for a dependency chain that multiplies CI runs, cascades rebase conflicts through every dependent branch, and forces reviewers to hold context across N linked PRs. The real decision is whether your team sits above or below the threshold where that trade pays off, or whether enforced size limits plus AI-aware review tooling would serve you better.

The Mega-PR Problem AI Coding Tools Created

Review effectiveness degrades as diff size grows, a principle well documented across both industrial research and tooling. Google's modern code review study documents how even one of the most review-disciplined engineering organizations on earth treats small, focused changes as a prerequisite for meaningful review, and SmartBear's code review practices, codified in tools like Collaborator, reinforce the same principle. A widely cited rule of thumb places this degradation somewhere in the low hundreds of changed lines, though the exact inflection point varies by codebase, language, and reviewer familiarity. Beyond that range, reviewers start missing defects, skimming instead of reading, and deferring feedback until the PR is too large to act on.

AI coding tools break this model. An agent told to add a product search feature produces a data model, an API route, client wiring, UI states, and seed data in a single pass. The result is a 1,000 to 2,000 line diff that no reviewer can meaningfully assess in one sitting. Enterprise AI coding guidance documents the strain that growing AI-generated code volume places on review pipelines. The PR sits unread, feedback quality collapses, and the change eventually lands under-reviewed or stalls indefinitely.

This is the problem stacked pull requests were designed to solve. The question is whether they actually solve it, or whether they substitute one failure mode for another.

How Stacked Pull Requests Work on GitHub

Take a concrete example. An AI agent builds a product search feature and produces a 1,721-line diff: a catalog data model, a search API, chat grounding logic, and a grounded UI. Pushed as one PR, that diff is effectively unreviewable. Stacking decomposes it into a chain of dependent branches, each scoped to one layer.

The decomposition starts at the data layer. A data modeler agent produces feat/catalog-data (schema and migrations), a backend agent builds feat/search-api on top of it, another agent adds feat/chat-grounding wiring search results into the chat pipeline, and the final layer feat/grounded-ui renders the results in the frontend. Each branch is created off the previous one, not off main, so the dependency chain runs four deep. GitHub's stacked PR docs describe the native support managing these parent-child relationships, but the chain itself is structural.

The CLI makes the chain tractable to create but fragile to maintain. You run gh init stack to start, gh stack add to append each branch, gh stack push to publish, and gh stack submit to open all linked PRs. GitHub renders a stack map showing each PR nested under its parent so a reviewer can navigate the chain without losing their place. Teams that adopted stacking before native support used gh-stack for the same workflow with the same operational profile.

The cost surfaces when something changes mid-review. A reviewer requests a schema fix on feat/catalog-data at the base. The author amends that branch, and the rebase cascades through feat/search-api, feat/chat-grounding, and feat/grounded-ui, each producing its own conflicts. The stack map goes stale until every branch is reconciled, and the further down the change lands, the more dependent branches it disturbs.

Reviewing the stack compounds this fragility. Graphite's stack review guide recommends reading top-down for context and reviewing bottom-up for implementation. That works for a four-layer stack with clean boundaries. It breaks when layers are interdependent in non-obvious ways, because the reviewer approving feat/search-api must hold the feat/catalog-data contract in mind while previewing how feat/chat-grounding will consume it. The cognitive load shifts from parsing one large diff to tracking dependencies across linked PRs.

These trade-offs, not bugs, are what make stacking powerful for large, well-decomposed changes and fragile for everything else.

Four Production Failure Modes for Stacking

Stacking's documentation and announcement posts focus on the happy path. Four failure modes determine whether the pattern actually works at scale.

Rebase Cascade

When a reviewer requests changes on a parent PR and the author amends or rebases that branch, every dependent branch in the stack must rebase onto the new commit history. A four-layer stack means four branches that may each produce merge conflicts against the revised parent. GitHub flags diverged branches and blocks stack merges until you rebase, and the conflict surface grows with stack depth. An eight-deep stack can turn a one-line fix at the base into hours of conflict resolution cascading upward.

The safer approach is to run rebases locally with gh stack rebase rather than using GitHub's web-based rebase button, which resets the committer, strips commit signatures, and can silently break branch protection rules that require signed commits. GitHub's enterprise stacked PR docs cover these management workflows, but the conflict propagation itself is inherent to the dependency chain and cannot be engineered away.

CI Cost Multiplication

The AI-specific cost trap compounds through agent rebase loops. When a reviewer requests changes on a base layer, the AI agent regenerates that layer and rebases, triggering fresh CI runs on every dependent layer above it. A single review comment on the schema branch of a four-layer stack can cascade into four full pipeline re-runs. Two more rounds of feedback on that same base, and the count keeps climbing, because every dependent layer rebuilds each time.

This creates a perverse incentive. Teams feel the CI bill and respond by keeping stacks shallow, which defeats the decomposition purpose that motivated stacking in the first place.

The math is unforgiving for expensive pipelines. A single 1,500-line mega-PR triggers one 12-minute CI run. The same change split into five stacked layers, with two rounds of feedback on the base, triggers roughly 15 runs as each layer rebuilds on every base amendment. That is 180 CI minutes on one feature. GitHub's pricing page shows how Actions minutes accumulate under exactly this pattern.

The cost-control tactic is to share build artifacts across layers and use conditional jobs that skip work when a dependent layer has not changed. Build the shared dependency once, cache it, and let upper layers pull from the cache instead of rebuilding. This narrows the cost gap but requires pipeline engineering most teams skip until the bill arrives.

Cross-PR Cognitive Load

Stacking shifts reviewer cognitive load rather than eliminating it, trading one large diff for the burden of holding context across N linked PRs, understanding the dependency chain between them, and tracking which layers have already been reviewed versus which are still pending. The directional guidance helps in principle, but the mental model still requires the reviewer to understand how layer three's API contract affects layer four's UI implementation.

For simple, well-decomposed stacks with clean layer boundaries, this is manageable. For stacks where layers are interdependent in non-obvious ways, the cognitive overhead can exceed what a single mega-PR would have cost. Reviewers also lose the ability to see the complete change in one view, which makes it harder to catch integration bugs that only surface when all layers compose.

Organizational Coordination Overhead

Stacking requires tooling investment, team discipline, and a shared mental model. Every engineer needs to understand stack creation, rebase workflows, and merge ordering. Code owners need to coordinate review across layers rather than within a single PR. CI pipelines need to be stack-aware. Branch protection rules need to account for stack-specific merge behaviors.

This overhead has a fixed cost regardless of how often you stack. If your team stacks occasionally, the cost of maintaining that institutional knowledge may exceed the benefit. If your team stacks constantly, the overhead amortizes across many features and the pattern pays for itself.

The Stacking Adoption Threshold

The four failure modes above interact with four team-level variables to produce a threshold. On one side, stacking removes more pain than it adds. On the other, it adds more than it removes. Each variable has a binary tipping point.

Are your AI-assisted diffs genuinely too large to review? If PRs regularly land in the low hundreds of lines and get meaningful feedback, size limits solve the problem without stacking. If they routinely hit 1,000-plus lines where reviewers skim and defer, stacking may be the only path to real review.

Is reviewer availability fragmented or concentrated? Fragmented availability (reviewers squeezing in minutes between meetings) fits the distributed model of a stack. Concentrated review blocks (a reviewer sits down for one focused session) make a single large diff more efficient than coordinating across a chain.

Is your CI pipeline cheap or expensive? As shown in the failure modes above, deep stacks on expensive pipelines (15-plus minutes with browser tests and container builds) burn budget faster than the review benefit justifies. Cheap pipelines (under a few minutes) absorb the multiplication without pain.

Does your team already know stack tooling? A team fluent in gh stack or Graphite absorbs the overhead quickly. A team learning from scratch pays a tax on every stack for weeks, and that tax is pure overhead with no review benefit.

The interaction is what matters. Stacking wins when diffs are large, reviewers are fragmented, CI is cheap, and the tooling is familiar. It loses when PRs are moderate, reviewers concentrate their time, CI is expensive, and the workflow is new. Most teams adopting AI coding tools sit in the middle, which is why a blanket recommendation to stack does more harm than good.

Alternatives and Complements to PR Stacking

Stacking is one response to the mega-PR problem. Others may outperform it depending on your constraints, and the strongest production setups combine several.

Enforced PR-size limits. The simplest fix is to reject PRs above a line-count threshold before they enter review. Graphite's guidance on enforcing PR reviewers covers review policy enforcement on GitHub broadly, including reviewer assignment and approval rules that can be extended to size-based gating, and tools like Danger or reviewdog can block oversized PRs automatically. This works when the problem is discipline, not decomposition. If your team can split a 1,500-line diff into five independent 300-line PRs off main, you do not need stacking at all.

AI-aware code review tools. Automated review tools designed for AI-generated code are emerging as a complement to human review. Anthropic's recently launched AI code review tool targets exactly this problem, flagging issues in AI-generated code before human review. These tools can reduce the review burden on mega-PRs without requiring structural decomposition.

Ephemeral review environments.Preview environments let reviewers test the full change in a deployed environment without reading every line. This does not replace code review but reduces the risk that a large, under-reviewed PR ships a runtime defect that a line-by-line read would have missed.

Trunk-based development.Trunk-based development with very short-lived branches and continuous integration reduces the size of individual changes at the source. Teams that merge small changes to trunk multiple times per day rarely produce mega-PRs because the workflow structurally prevents accumulation. AI coding tools that push to short-lived branches and merge quickly never give the diff room to grow into a mega-PR in the first place.

The strongest production pattern combines enforced size limits as the default with stacking reserved for genuine overflows. Stacking becomes the escalation path, not the primary workflow.

A Practical Playbook With Five Scenarios

The pattern is consistent across all five scenarios. Stacking wins on large interdependent diffs with cheap CI, loses on deep stacks where a parent rebase cascades through dependent branches, and is unnecessary when PRs are already small enough to review independently.

Decision Criteria for Your Team

Use this checklist to decide whether to adopt stacked pull requests for your AI-assisted workflow.

1. Are your AI-assisted PRs regularly exceeding a few hundred lines? If yes, you have a mega-PR problem that stacking can address. If no, enforce size limits and skip the stack tooling investment.
2. Is your CI pipeline cheap (under 5 minutes per run)? If yes, the CI multiplication cost of stacking is manageable. If no, deep stacks will strain your monthly budget and may negate the review benefit.
3. Do reviewers have fragmented availability? If yes, the distributed review model of stacking fits your workflow. If reviewers review in dedicated blocks, a single PR may be more efficient than coordinating across a chain.
4. Is your team willing to invest in stack tooling? If yes, the overhead amortizes over time as the workflow becomes routine. If no, the learning tax will undercut every stack you attempt.
5. Do you have a rollback path? If a stack breaks mid-review, can you abandon it and fall back to independent PRs? If not, stacking creates a commitment you cannot easily exit without discarding work.

Stacked pull requests are a structural tool, not a default workflow. They solve a real problem in AI-generated diffs that exceed human review capacity, but they introduce their own costs: rebase cascades that grow with stack depth, CI runs that multiply per layer, cross-PR context that reviewers must track across linked branches, and organizational overhead that exists whether you stack once a month or once a day. The teams that benefit are the ones that treat stacking as a conditional decision with a measurable threshold, not a universal practice. Enforce size limits first. Stack when the limits are genuinely exceeded. And measure whether the stack's overhead is actually less than the mega-PR it replaced.