GitHub's New Stacked Pull Requests: The Review Bottleneck Fix AI-Generated Code Made Unavoidable

Kynodex

·August 10, 2026·10 min read

GitHub's New Stacked Pull Requests: The Review Bottleneck Fix AI-Generated Code Made Unavoidable

GitHub handled roughly one billion commits in 2025. It's on pace for around 14 billion in 2026. That's not a gradual climb — it's the direct fingerprint of AI coding tools making code generation nearly free, while code review stayed exactly as slow and human-paced as it's always been.
Stacked pull requests, now in public preview, is GitHub's answer to the bottleneck that mismatch created.

Introduction

For most of the last decade, "stacked PRs" was a workflow you had to go out of your way to adopt — a pattern engineers at Meta and Google used internally, and one that spawned an entire ecosystem of third-party tools (Graphite, Sapling, git-branchless, the community-built ghstack) for teams who wanted the same discipline without building it themselves. As of July 30, 2026, it's a native GitHub feature, rolling out to every repository, free, with no separate tool or subscription required.

The timing isn't incidental. This post covers what stacked PRs actually are, why GitHub built this specifically now, how the workflow works day to day, and what it changes for teams whose AI-assisted coding output has been quietly outpacing their review capacity.

What a Stacked Pull Request Actually Is

The core idea is a direct alternative to the two bad options engineers have lived with for years: cramming an entire feature into one enormous pull request that takes a reviewer half a day to get through, or splitting work across separate branches that then require constant, manual rebasing every time an earlier piece changes.

A stack is an ordered chain of branches, where each one builds directly on the branch before it, and each opens as its own independent pull request pointing at the layer beneath it rather than straight at the main branch. A typical example: a foundational database schema change sits as layer one, an API change that depends on that schema sits as layer two, and a UI change consuming that API sits as layer three — three focused, individually reviewable PRs instead of one sprawling diff that tries to explain three different kinds of change at once.

Each layer gets its own review, its own required checks, and its own approval — all while GitHub's existing branch protection rules and status-check requirements keep applying exactly as they do for any normal pull request. Reviewers can look at just the layer relevant to their expertise — a database specialist reviewing the schema layer, a frontend engineer reviewing the UI layer — without needing to hold the entire feature in their head at once.

The Mechanics: What's Actually New

The stack map

Every pull request within a stack displays a stack map — a visual index showing exactly where that specific PR sits relative to the rest of the chain: what's beneath it, what's above it, and how the whole sequence eventually resolves into the finished feature. A reviewer opening layer two doesn't have to go hunting through other tabs or ask in Slack "wait, does this depend on anything else" — the dependency is right there in the interface.

Automatic rebasing on merge

This solves what was previously the most tedious part of running a stacked workflow by hand. Before this feature, merging the bottom layer of a manually-managed stack meant manually updating every branch above it and reopening each affected pull request. With native support, that retargeting and rebasing happens automatically the moment a lower layer merges — the layers above shift down and re-point without the developer touching git directly.

One-click merge for the entire stack

Once every layer in a stack has passed review and its required checks, the whole sequence can merge together in a single operation — landing what functions as one coherent feature, built and reviewed as several small, digestible pieces. John Resig, the creator of jQuery, described landing five stacked PRs directly into a merge queue in one action as a genuinely different experience from what third-party stacking tools had offered before.

No proprietary metadata

Because a GitHub-native stack is just an ordered sequence of ordinary branches and pull requests, there's no special format that only a particular client application understands. Anyone looking at the repository through the normal GitHub interface, or through git directly, sees a completely legible structure — a meaningful difference from third-party stacking tools that sometimes required their own CLI or client to fully interpret the stack's relationships.

CLI and Copilot integration

The gh stack extension supports the core stacking commands directly — gh stack init, gh stack add, gh stack submit — reducing what used to be a genuinely fiddly manual process to a short, scriptable sequence. GitHub has also built a dedicated gh-stack skill specifically for GitHub Copilot and other coding agents, meaning an AI coding assistant generating a large multi-part change can structure its own output directly into stack-formatted layers, rather than producing one giant diff for a human to manually decompose after the fact.

Rollout status

Merge queue support for stacks specifically is still rolling out gradually as of this writing — worth checking your organization's current access before assuming full feature parity with a standard single pull request workflow.

Why GitHub Built This Specifically Now

This is the part that matters more than the feature mechanics themselves, and it's a pattern directly connected to a theme we've covered before on this blog: AI coding tools have made generating code dramatically cheaper, without making the human work of reviewing that code any cheaper at all.

The scale data backs this up directly — GitHub's own leadership has discussed the platform going from roughly one billion commits in 2025 to a projected 14 billion in 2026, an order-of-magnitude jump that lines up precisely with the same period AI coding assistants went from a novelty to a default part of many engineers' workflow.

Direct testimony from teams already using the feature reinforces the same point. TED's engineering leadership described AI making their developers dramatically more productive at generating code — while simultaneously creating a new bottleneck, because pull requests were growing large enough that reviewers genuinely struggled to keep pace. Their read on stacked PRs: breaking large changes into small, dependency-ordered pieces doesn't just make review faster, it makes review more accurate, because a reviewer evaluating one focused layer catches things a reviewer skimming a 2,000-line combined diff simply won't.

This connects directly to a structural point worth internalizing: as coding becomes cheaper through AI assistance, the actual bottleneck in software delivery shifts to review and verification — a pattern that shows up repeatedly in 2026 engineering discourse, from arguments about the ceiling AI coding tools put on total productivity gains once review time is accounted for, to direct complaints that reviewing AI-generated output sometimes takes longer than writing the equivalent code would have taken a human in the first place.

What This Means for Engineering Teams

For teams already running trunk-based development

If your team already favors small, frequent pull requests, native stacking closes a real, specific gap: the workflow you've wanted was always achievable, but it required either external tooling or a genuinely tedious amount of manual branch and rebase management. This removes that tax entirely.

For teams generating large changes via AI coding agents

This is the more consequential shift. An AI coding agent tasked with a substantial feature can now structure its own output directly as a stack via the gh-stack skill — meaning the review burden an agent creates arrives pre-decomposed into reviewable layers, rather than landing as a single overwhelming diff a human then has to manually break apart before review can even meaningfully begin.

For engineering managers evaluating review process

The direct claim from teams already adopting this — smaller, dependency-ordered chunks produce more accurate review, not just faster review — is worth testing against your own team's actual PR size distribution. If your team's average pull request has been creeping upward as AI-assisted coding adoption increased, that's a concrete, measurable signal this feature is worth adopting now rather than waiting for general availability.

The honest caveat

This is public preview, not general availability. Startup Fortune's reporting notes the feature entered private preview back on April 13, 2026, before this July 30 public rollout — a meaningful gap that suggests real production hardening happened before the wider release, which is a reasonable trust signal. Still, treat any public-preview feature as one to pilot deliberately on a lower-stakes repository first, rather than something to roll out across your entire organization's critical path on day one.

Key Takeaways

Stacked pull requests are now a native GitHub feature, in public preview since July 30, 2026, rolling out free across all repositories — no separate tool, client, or subscription required.
The core mechanism: an ordered chain of branches, each building on the one before it, each opening as its own independently reviewable pull request — with a visual stack map showing every layer's place in the sequence.
Automatic rebasing on merge removes the single most tedious part of manual stacking — previously, merging a lower layer meant manually updating and reopening every PR above it; now that happens automatically.
The timing is directly tied to AI coding tools breaking the old review model. GitHub's own commit volume — roughly 1 billion in 2025, trending toward 14 billion in 2026 — is the clearest evidence that code generation has outpaced review capacity, and stacked PRs is a direct structural response to that gap.
A dedicated gh-stack Copilot skill lets AI coding agents structure large changes into pre-decomposed, reviewable layers themselves — rather than producing one large diff a human has to manually break apart before meaningful review can start.
This remains a public preview feature, with merge queue support for stacks still rolling out gradually — pilot it deliberately before treating it as a default workflow across your whole organization.

Conclusion

Stacked pull requests solve a problem that stopped being optional the moment AI coding assistants made generating large volumes of code nearly free. The review bottleneck that creates was always going to force a structural fix — either engineering teams built more discipline around smaller changes on their own, or the platform itself had to make that discipline the path of least resistance. GitHub chose the second option, and made it native rather than leaving it to a fragmented ecosystem of third-party tools.

For any team whose average pull request size has been quietly growing as AI-assisted coding adoption increased, this is worth piloting now — not because it's novel, but because the underlying problem it solves, unreviewable diffs outpacing reviewer capacity, is a problem that's actively compounding for most engineering organizations in 2026, whether or not they've named it yet.

References

At Kynodex, we build engineering workflows and review infrastructure designed to keep pace with AI-assisted development — not just the code generation half of the equation. If your team's review process is straining under AI-generated code volume, talk to us.

Comments

No comments yet. Be the first to start the conversation.

All posts Work with us