GitHub just shipped stacked PRs as a native feature, and for anyone whose AI coding agent generates enormous diffs, this fixes a pain you’ve probably felt this month. It’s the top developer story of the cycle for good reason.
Stacked PRs are an ordered series of pull requests where each one is a focused layer of a larger change. You review each layer independently, checks run per layer, and then merge everything in one click. The official changelog describes it as a way to keep large changes moving without opening one giant PR nobody wants to review.
Why GitHub built this now
The timing isn’t a coincidence. AI coding agents made pull requests bigger, not smaller. TED’s CTO said as much in the changelog: AI made their developers dramatically more productive, which created a new bottleneck where PRs grew large enough that reviewers struggled. Stacked PRs are GitHub’s answer to that specific problem.
That framing matters. This isn’t just a developer convenience feature. It’s GitHub adapting the core review workflow to the agent era, where a single session can produce what used to be a week of human work.
How stacked PRs work
The mechanics are simple. You start with a branch and PR for the first change, then add branches and PRs on top of it, with each PR targeting the layer below it. A stack map at the top of each PR shows where the change you’re reviewing fits into the whole. Reviewers can work different layers in parallel.
Merging is the clever part. You can land one layer, some layers, or the entire stack at once. Lower layers merge first, and the PRs above stay open, automatically rebasing and retargeting. Existing branch protections and required checks still govern what reaches main.
There’s also a CLI extension that gets you started in under a minute: gh extension install github/gh-stack. And GitHub is positioning it for coding agents too, with a gh-stack skill for Copilot. The extension repo is the fastest way to try it.
Who this is for
Stacked PRs shine for teams shipping large features where review is the bottleneck, and especially for teams where agents write a lot of the code. jQuery creator John Resig called the preview incredible after landing five stacked PRs into a merge queue at once. The parallel review workflow is the whole point.
If you’re a solo developer, you mostly don’t need this. Your PRs don’t wait in a review queue. If you’re on a small team with small changes, it’s overhead you can skip. This is a tool for the pain point where review latency starts blocking shipping.
What this means for the tooling landscape
Stacked PRs aren’t a new idea. Graphite built a whole business on them, and there are other third-party options. What changes now is that the workflow is native, works with existing branch protections and merge queues out of the box, and lives where the code already lives.
That’s the pattern that matters. Every time GitHub absorbs a workflow that was previously a third-party tool, the standalone tools have to justify their existence on depth and speed. Some will, some won’t. For most teams, native wins because there’s nothing extra to install, maintain, or pay for.
The best AI coding agents guide I published this month keeps coming back to the same bottleneck: the agents are fast, and human review is the constraint. Stacked PRs don’t make agents faster. They make the human part faster, which is where the actual throughput problem lives.
Bottom line
GitHub stacked PRs are in public preview, and they’re the right answer to the AI-era review bottleneck. If your team ships large features or runs heavy agent workflows, it’s worth installing the CLI extension and trying a stack today. The workflow will feel familiar if you’ve used the third-party tools, and frictionless if you haven’t.
