EN
Book a call

Development Approach

Stacked Pull Requests vs One Large Pull Request: Which Review Shape Fits AI-Generated Code?

Stacked pull requests vs one large PR: review size, rebase cost, signed commits and agent fit — with 2026 data.

Reviewed by Michael Kerkhoff, as of

Definition
Coding agents did not create the review bottleneck, but they moved it. Authoring a feature is now minutes of work; reading it is still a human sitting down with a diff. GitHub's own worked example is blunt about the result: a single prompt to add product search produces a data model, an API route, client wiring and four UI states in one 1,721-line pull request. The reviewer's reaction in that post — "I'll review this later" — is the whole problem in four words. The change lands under-reviewed not because anyone was careless, but because the package was the wrong shape. Stacked pull requests answer that with decomposition. Instead of one pull request that does everything, you ship an ordered chain in which each branch targets the branch below it: data first, then the API, then the wiring, then the UI. Each layer is small enough to hold in a reviewer's head, each can go to the owner who actually knows that layer, and layer one can be approved while layer four is still being written. GitHub shipped this natively — private preview on 13 April 2026, public preview on 30 July 2026, with a gh-stack CLI extension and an agent skill that teaches coding agents to build the stack from the start rather than slicing a finished diff afterwards. The trade is real and worth naming up front. A stack is a dependency chain, and dependency chains need maintenance. Change layer one after review and every branch above it has to be rebased. GitHub automates the cascade, but the web-based rebase button resets the committer and produces unsigned commits — which quietly breaks any repository that requires signed commits. This comparison scores both approaches on review size, feedback latency, maintenance cost, merge mechanics, branch-protection compatibility and agent fit, using verifiable 2026 numbers rather than workflow folklore.
Category
Development Approach
Options
Stacked Pull RequestsOne Large Pull Request

Detailed Comparison

A side-by-side analysis of key factors to help you make the right choice.

Stacked Pull Requests vs One Large Pull Request
FactorStacked Pull RequestsOne Large Pull Request
Size of the unit under reviewEach layer is scoped to a single concern and stays in the 200-400 changed-line band where review is measurably most effective. WinnerThe entire feature arrives as one diff; GitHub's worked example lands 1,721 changed lines before decomposition.
Reviewer allocationThe data owner reviews the data layer, the UI owner reviews the UI layer, and layers can be reviewed in parallel. WinnerOne reviewer has to hold the data model, API contract, client wiring and UI states in their head at the same time.
Feedback latencyLayer one can be reviewed, fixed and approved while layer four is still being written. WinnerNothing is reviewable until the whole feature is finished, so all feedback arrives at the end.
Cost of changing an early layerA fix at the bottom forces a cascading rebase of every branch above it; gh stack sync automates the cascade but the rebase is still real work.One branch, one rebase, no dependency chain to repair when feedback arrives. Winner
Merge mechanicsMerge the whole stack in one operation, or land lower layers and let the pull requests above automatically rebase and retarget.A single merge with no stack state to reason about and no partial-landing decisions.
Signed commits and branch protectionThe web Rebase stack button runs on GitHub's servers, resets the committer and produces unsigned commits, which breaks signed-commit protection; gh stack rebase locally avoids this.No cascading rebase, so no committer reset and no signature loss to guard against. Winner
Scaling ceilingPractitioner guidance puts the practical limit at three to four layers, after which dependency tracking outweighs the review benefit.No structural limit on size, but review quality and reviewer attention decay as the diff grows.
Fit with coding agentsThe gh-stack agent skill teaches agents to decompose work into ordered layers while authoring, so the shape is a constraint rather than a cleanup task. WinnerAgents trained on a decade of monolithic pull requests default to one large diff, and slicing a finished diff into layers afterwards is harder than building it in layers.
Total Score · 2 ties4 / 82 / 8

Key Statistics

Real data from verified industry sources to support your decision.

  • GitHub's worked example packs a data model, an API route, client wiring and four UI states into a single 1,721-line pull request before it is decomposed into four stacked layers. — GitHub Engineering Blog (2026)
  • An analysis of 1.5 million pull requests cited at the stacked-PR launch found that pull requests of 200 to 400 changed lines had 40% fewer defects and were approved three times faster than larger ones. — InfoQ (2026)
  • Gartner projects coding agents will drive a 50% productivity gain across every stage of the software development lifecycle by 2028, increasing the rate at which large diffs arrive for review. — Gartner, cited by GitHub Engineering (2026)
  • GitHub's gh-stack CLI extension reached 1,093 stars and cut its first tagged release, v0.1.0, on 29 July 2026 — one day before stacked pull requests entered public preview. — GitHub REST API, github/gh-stack (2026)
  • Stacked pull requests entered private preview on 13 April 2026 and public preview on 30 July 2026, with the public-preview announcement reaching 780 points on Hacker News. — GitHub Changelog (2026)
  • Practitioner guidance puts the practical ceiling at three to four pull requests per stack, beyond which the cognitive overhead of tracking dependencies outweighs the review benefit. — Alan West, cited by InfoQ (2026)

All statistics come from verified third-party sources. Source, year, and direct link are shown on each metric.

When to Choose Each Option

Clear guidance based on your specific situation and needs.

Our Recommendation

Choose stacked pull requests when review capacity is your bottleneck and the change has natural layers. That is now the common case: TED's CTO describes exactly this failure mode in GitHub's launch post — AI made developers dramatically more productive, and the new constraint became pull requests growing large enough that reviewers struggled. The data supports the smaller unit: an analysis of 1.5 million pull requests cited at launch found that pull requests of 200 to 400 changed lines had 40% fewer defects and were approved three times faster than larger ones. A stack is the mechanism that keeps individual pull requests in that band even when the feature is substantial. Choose a single pull request when the change is genuinely one concern, when your repository requires signed commits and your team will not reliably use the local gh stack rebase path, or when the feature would need more than three or four layers. That ceiling is not arbitrary: practitioner guidance puts it at three to four pull requests per stack, beyond which tracking dependencies costs more attention than the smaller diffs save. A five-layer stack that nobody rebases correctly is worse than one honest large diff. The decisive factor is not tooling maturity but who is writing the code. An agent trained on a decade of monolithic pull requests will produce a monolithic pull request unless you tell it otherwise, and slicing a finished 1,700-line diff into layers afterwards is strictly harder than building it in layers. Install the agent skill, give each layer a defined scope and an owner, and the decomposition happens at authoring time where it is cheap. Skip that step and stacked pull requests are just extra branches to rebase. The review shape has to be a constraint on the agent, not a cleanup task for the human.

Choose Stacked Pull Requests when...
  • The change splits naturally into dependency-ordered layers — data, API, wiring, UI — with different owners for each.
  • A coding agent produced a diff you cannot honestly review in one sitting.
  • Review capacity is your bottleneck, not authoring speed.
  • You need the foundation layer reviewed and merged while the layers above it are still being written.
Choose One Large Pull Request when...
  • The change is genuinely one concern and stays within a few hundred changed lines.
  • Your repository requires signed commits and the team will not reliably use the local gh stack rebase path.
  • The feature would need more than three or four layers, where dependency overhead exceeds the review gain.
  • Your team has no stack-aware tooling and would have to maintain the branch chain by hand.

Common questions about this comparison answered.

Frequently Asked Questions

(01)What are stacked pull requests?
Stacked pull requests are an ordered chain in which each branch targets the branch immediately below it rather than the main branch. A feature becomes a sequence of small, independently reviewable layers — for example a data model, then an API endpoint, then the client wiring, then the UI. GitHub made this native in 2026: private preview on 13 April, public preview on 30 July, with a gh-stack CLI extension, a stack map in the pull request interface and one-click merging of the whole stack.
(02)Do stacked pull requests work with existing branch protection and CI?
Yes. Checks and merge rules are evaluated against the stack base rather than each branch's immediate parent, so CI runs on every layer as if it targeted the main branch directly, and existing branch protections still govern what reaches main. One caveat matters: the web-based Rebase stack button runs on GitHub's servers, which resets the committer and produces unsigned commits. If your protection rules require signed commits, use gh stack rebase locally and then gh stack push instead.
(03)Why do coding agents produce one giant pull request by default?
Because that is what the training corpus looks like. Agents learned from a decade of pull requests in which a whole feature landed in one diff, so a single prompt yields a single large change. The fix is to make the review shape part of the instruction rather than a cleanup task: installing the gh-stack agent skill teaches compatible agents to initialise a stack, add each layer on top of the one below and commit only when checks pass — so the decomposition happens while the code is written, not afterwards.
(04)How many layers should a stack have?
Three to four is the practical ceiling reported by practitioners; beyond that the cognitive overhead of tracking dependencies starts to outweigh the review benefit. Aim for layers that each do one logical thing and land in the 200-400 changed-line band, where an analysis of 1.5 million pull requests found 40% fewer defects and approvals three times faster. If a feature would need six or seven layers, that is usually a signal to ship it as two separate features rather than one very tall stack.

Need help deciding?

Book a free 30-minute consultation and we'll help you determine the best approach for your specific project.

Book Free ConsultationEmail Us

Free consultation · No obligation · Personal reply