Overview
On July 31, GitHub moved Stacked Pull Requests into public preview; the August 4 engineering blog documented a complete workflow for turning a 1000+ line AI-generated diff into a reviewable stack. This is not a new feature so much as the first explicit acknowledgment that the classic one-PR-one-conversation model breaks when an agent produces a thousand lines in one shot.
How Stacked PRs Work
A stack is an ordered set of linked PRs inside the same repository. Each PR targets the branch of the one beneath it, forming a bottom-up merge chain. The bottom layer merges first; every layer above auto-rebases to follow. GitHub.com ships a native UI plus a stack map. On the CLI side, the gh-stack extension (GitHub CLI 2.90.0+, Git 2.20+) manages lifecycle, and an gh-stack skill lets agents such as Copilot call gh stack directly to split work automatically. Branch protection and required checks propagate across the whole chain, so stacking never bypasses any merge gate — that linkage is GitHub's key move tying safe governance to a workflow upgrade.
The Underlying Pain Point
The blog's worked example is blunt: a single 1000+ line AI diff gets split into L1 (data model) → L2 (API) → L3 (wiring) → L4 (UI), with a different reviewer per layer. Lower layers are reviewed and merged first; upper layers build on them. This matches engineer Mayank Saini's note from WHOOP: one big change used to mean one giant PR nobody wanted to review; now it is a stack of small PRs reviewers can actually follow, with the whole chain merged in one go.
Why Now
AI coding collapses the cost of generating code, but the cost of reading code is unchanged — a human does not review a 1000-line PR much faster than a 200-line one, while an agent can emit 1000 lines in minutes. The bottleneck has shifted from writing to reading, and pipeline throughput now stalls on the review side. Stacked PRs are not a discipline slogan for "small PRs"; they make small-step delivery the platform default. The agent decides how many layers, how big each one is, and who reviews. The stack map lets reviewers browse layers in parallel while still seeing dependencies.
Four Real Caveats
- Splitting is not free: when a lower layer changes, every layer above must rebase and resolve conflicts, with CI required throughout.
- Tests must accompany every layer, not just the final stack.
- Upper-layer code is not independently shippable until it reaches the trunk.
- The
gh-stackskill's auto-split quality depends on the prompt; reviewers still must inspect each layer's actual diff. - GitHub blog: <https://github.blog/engineering/turn-one-giant-ai-generated-pull-request-to-a-reviewable-stack>
- Docs: <https://docs.github.com/pull-requests/get-started/stacked-prs-quickstart>
Context and Outlook
Stacked PRs sit alongside OpenAI's Codex Sol/Luna layering (August 3 topic) and Cloudflare ADLC (August 4 topic) in the same wave: as AI compresses the "implementation" stage toward zero, every phase of engineering management has to be rewritten. GitHub chose stacking over alternative shapes because it still lives inside the "PR as unit of collaboration" tradition and avoids inventing new workflow vocabulary — the path of least resistance, and the most ecosystem-compatible. Teams already using Graphite, Sapling, or git-branchless may not fully replace those mature tools, but GitHub's entry moves "stacking" from an advanced trick to the default action; at GA, native stacking will likely become the default workflow for new repositories.