GitHub Finally Shipped Stacked PRs. The Timing Is the Real Story.

GitHub has shipped stacked pull requests in public preview. For the first time since the platform launched in 2008, stacking a PR on top of another PR is an officially supported workflow. That sounds like a modest feature drop, but the timing is suspicious. This looks less like a roadmap item finally coming due and more like an answer to a problem that only got urgent in the last 18 months: AI agents are generating code faster than humans can review it.

What Stacking Actually Solves

The default GitHub flow is simple and slightly broken. Cut a branch, do the work, open a PR against main, wait. While you wait, you’re blocked — especially if your next task depends on the code sitting in review.

So people pick one of two bad options. Wait for review to clear, or bundle everything into a single 2,000-line PR and hope for the best. The first is slow. The second is reviewer abuse. Anyone who has been handed a 2,000-line diff knows exactly what happens next: scroll, scroll, scroll, LGTM.

Stacking is the third path. You branch off PR #1 to create PR #2, then branch off that for PR #3. Each one stays in the 100 to 200 line range, so the reviewer gets a series of logically complete chunks instead of one archaeological dig. Meanwhile you keep working up the stack while the bottom is still in review.

The hard part is rebase automation. When review feedback lands on PR #1 and you amend it, everything stacked above has to be rebased. Doing that by hand is where most homegrown stacking attempts die. That’s precisely what GitHub is now handling: it understands the dependency graph of the stack, and when one PR merges, it updates the base branches of everything above it.

Fifteen Years of Someone Else’s Problem

GitHub wasn’t the only one who noticed this gap. It’s more accurate to say everyone noticed and GitHub was the last to act.

Meta went so far as to build its own version control system. Sapling made commit-level review the internal default, and the culture followed the tooling. Google’s Critique does the same thing. Phabricator did it at Facebook before Sapling. Engineers who leave those companies for GitHub-based startups reliably hit the same culture shock, and it shows up on Hacker News every few months in some variation of: why is everyone here shipping such enormous PRs?

Third-party tools rushed the vacuum. Graphite is the obvious one — founded by ex-Meta engineers, pitched essentially as “the Sapling experience, bolted onto GitHub,” and now the default workflow at a long list of startups. Open source alternatives like git-branchless and spr kept a steady following too.

GitHub’s announcement lands directly on that ecosystem. This is the classic platform absorption pattern: incumbent watches a third party prove demand, then ships the feature natively. The only survival strategy for the third party is to move up a layer the platform can’t reach quickly. Graphite’s recent push into AI code review is not a coincidence.

Why Now, Specifically

Fifteen years of inaction, then a fix in 2026. What changed?

Volume. Coding agents are routine now, and the amount of change a single engineer produces in a day is not comparable to what it was two years ago. Hand a task to an agent, go do something else, come back to a finished PR. That’s a normal Tuesday.

But review capacity did not scale. Reading code and taking responsibility for it is still a human job, and humans still have 24-hour days. Picture a factory that multiplied line output by ten and kept exactly one inspection station. Inventory piles up in front of the inspector.

That’s the actual state of a lot of engineering orgs right now. The cost of producing code collapsed. The cost of understanding and owning that code did not. It may have gone up, because reading code you didn’t write is meaningfully harder than reading code you did.

Stacked PRs target that bottleneck. Break the big chunk into small ones, lower the reviewer’s cognitive load per unit, raise review throughput. For GitHub, the business logic writes itself: if review jams up on your platform, Copilot gets harder to sell.

The Part That Doesn’t Quite Add Up

A few reasons for skepticism.

First, splitting a PR doesn’t reduce the total. One 2,000-line diff becoming ten 200-line diffs means ten context switches for the reviewer. Each piece is lighter, but the sum is the same or worse. Stacking only works when each slice is logically self-contained, and that depends on the engineer’s ability to decompose a change — not on the tooling.

Second, tools don’t create culture. Stacked workflows worked at Meta partly because of Sapling and largely because there was shared agreement that small, incremental diffs are simply how you work. Drop the same tool into an org without that agreement and you get 2,000 lines arranged in a stack.

Then there’s the deeper question. In a world where AI writes most of the code, is human review still the right chokepoint? One camp says AI-written code will inevitably be AI-reviewed. The other says that’s how you end up with production systems nobody understands. Stacked PRs are a bet on keeping humans in the loop — not eliminating the bottleneck, just making it survivable.

What to Check Before You Adopt

It’s public preview, so full rollout is premature. But there are things worth sorting out now.

Start with CI cost. Deep stacks trigger cascading rebases, and every rebase re-runs the pipeline. Decide up front whether mid-stack PRs get a full build every time or only at final merge. This gets expensive fast.

Merge ordering is the other trap. If you want to merge a PR from the middle of a stack, your team needs a rule for what happens to everything above it. Check how branch protection rules and required reviewers interact with stack structure before you find out the hard way.

If you’re already on Graphite or similar, there’s no urgency to switch. Preview features are typically rougher than mature tooling, and the stack visualization and bulk-update features you’re used to are either missing or thin.

The Signal, Not the Feature

The interesting part of this announcement isn’t the feature. It’s the confirmation that the bottleneck moved. A few years ago the constraint on shipping software was writing the code. Now it’s understanding and vouching for the code that keeps arriving. That’s why tooling companies suddenly care about review workflows.

So: what’s the slowest step on your team right now? Writing the code, or the PR that’s been sitting in the queue since Tuesday waiting for someone to look at it? If it’s the second one, the shift already happened to you. Whether stacking fixes it is something you’ll have to find out yourself.