Stacked Pull Requests With AI Coding Agents

An AI coding agent asked to add a feature, left unattended, comes back as one enormous pull request. That's the pattern, and it's not a glitch. The GitHub Engineering blog walks through a real example: a request to add product search to a shopping assistant comes back as a single diff over 1,000 lines long, touching the database schema, the backend logic, the tests, and the UI all at once. The agent did what it was asked to do. It just did all of it in one pass.

Nothing in how these agents work pushes them toward breaking a task apart. They're built to finish the job, not to make the job easy to check. So when a reviewer opens that PR, they're not looking at one idea, they're looking at four or five ideas stacked on top of each other with no walls between them. A wall of code drains the context out of the room for the reviewer. Feedback gets shallower, review takes longer, and plenty of that code ends up merged after only a once-over.

How the review queue broke before stacking existed

The review system was buckling before agents started writing whole features in one shot. AI-assisted code was already piling up faster than humans could read it, and agentic PRs just stepped on the gas.

LinearB's 2026 benchmarks looked at more than 8.1 million pull requests across thousands of engineering teams and found that, at the 75th percentile, AI-assisted PRs ran significantly larger than ones written without AI help, and agentic AI PRs sat waiting for a reviewer far longer than the rest. Developers are producing more. The business isn't getting more out of it.

How Stacked PRs Work

A stacked PR is an ordered chain of branches with a merge model designed to let review happen in parallel.

The bottom PR targets main, and every PR above it targets the branch directly below it. A reviewer looking at any layer sees only the diff for that layer, not the whole pile of changes underneath it. Back to the shopping assistant example: layer one is the data model, layer two is the API, layer three wires up the chat logic, layer four is the UI. Four concerns, four PRs, each one small enough to actually read. When a reviewer checks out layer two, they're comparing it against layer one, not against the entire feature, so they see what's new at their layer and nothing they've already reviewed.

Compare that to the old small-PR approach, where PRs just come out one after another without a formal chain. PR #2 can't really be reviewed against a solid foundation until PR #1 merges. So the team either waits around for PR #1 to land, or reviews PR #2 against a base that keeps moving and re-checks it after every rebase. Neither option is pleasant. Stacking makes the dependency explicit instead of implicit, solving the ordering problem.

Merging runs bottom-up: merge the lowest PR that's ready, and it takes every unmerged layer below it with it in one move, instead of a manual chain of merges and conflict resolution. The catch with doing this by hand is cascading rebases. Each layer should compile and pass its own checks on its own. If a layer genuinely can't stand without something that comes later, that dependency gets written down, not buried.

Why stacking became broadly necessary only recently

None of this is a new idea. What changed in 2026 isn't the concept, it's how many teams suddenly need it.

Meta ditched its old branch-based workflow for stacked diffs because it made engineers measurably more productive. Google has run comparable stacking workflows internally for years, and third-party tools like Graphite and Meta's Sapling have spent that time building for teams that needed this before GitHub ever supported it out of the box.

Because the group of people who need stacking just got a lot bigger. GitHub took the feature to public preview in July 2026 and general availability on October 6, 2026, right as AI agents turned "occasionally review a big PR" into "constantly review huge ones." What used to be a tool for high-volume engineering organizations is turning into the sensible default for any team pointing agents at a codebase.

GitHub made stacked pull requests generally available on October 6, 2026, across every github.com plan. The feature spent time in public preview starting July 30, 2026, before reaching this point.

A few additions appear specifically at GA that weren't there during preview, fixing the parts of stacking that used to be genuinely annoying. The REST API's stack field just comes back null for a regular standalone PR.

There are real limits to know before anyone builds a workflow around this. A stack has to be a straight line: one PR can't have two children hanging off it. GitHub Desktop doesn't support stacks. Bots still calling the legacy PR merge API endpoints will fail outright trying to merge one. A stack's merge-queue group can run up to 50% over the configured maximum size. And ejecting a single PR from a stack's merge queue pulls every PR above it out of the queue too.

The gh-stack CLI and agent skill, setting up and running a stacked workflow

GitHub pairs this with a CLI extension, gh-stack, and an agent skill that teaches a coding agent how to work inside this system. Together they handle the branch and PR mechanics. Deciding how to split the work still falls to a person, or to how well the agent's prompt is written.

Getting set up takes one command: gh extension install github/gh-stack, which needs GitHub CLI 2.0 or newer and Git 2.36 or newer. To give an agent the skill, run gh skill install github/gh-stack (or npx skills add github/gh-stack). Installing the skill guides what the agent does. It still needs separate, explicit permission from a person to create branches, push code, open PRs, or merge anything.

The day-to-day workflow runs through a handful of commands: initialize the stack and set its base, add each new layer as a branch on top of the last one, then run gh stack submit --auto to open the PRs (they come in as drafts unless --open is added). Running gh stack view --json shows whether the structure actually holds together, the bottom PR targeting trunk, each PR above targeting the one below it, no file showing up in a layer where it doesn't belong. For routine upkeep, gh stack sync fetches the latest state, fast-forwards trunk where it can, rebases the stack if trunk has moved, and pushes everything back in sync.

Merging can target different scopes depending on what's ready: the whole current stack with gh stack merge --yes, a specific remote stack by number with gh stack merge 7 --yes, or everything from the bottom up through one PR with gh stack merge 42 --yes.

How to decompose agent output into a well-ordered stack

The CLI handles the mechanics. It has no opinion on where the seams of a change should go, and getting that wrong is what turns a stack from a clean review tool into a pile of fragments nobody can follow.

The rule holds up across almost any feature: find the dependency chain first, put the foundational work at the bottom, build everything dependent on it in layers above, and keep each layer narrow enough that one reviewer can hold it in their head without notes. There are specific ways this goes wrong, too. Layer one should not import something from a higher layer that hasn't been built yet, which keeps the order of construction honest. Layer two shouldn't be quietly patched with UI-specific workarounds that belong somewhere else. Layer three shouldn't be carrying fixes that were actually needed in the API below it but got left out. Each layer needs to compile and pass whatever checks make sense at that point in the stack, and if a layer genuinely can't function without something that comes later, say so directly rather than presenting it as something that could ship on its own.

Applied to the shopping assistant example, this looks like assigning a data modeler agent to layer one, a backend agent to layer two, and separate frontend agents to layers three and four, each one working a defined slice with firm boundaries on what it's allowed to touch. Every PR in the stack gets evaluated against its own base, so any check that's missing at the start surfaces somewhere in the middle of the stack.

The tradeoffs of stacking

Stacking cuts down on how much a reviewer has to hold in their head at once, and it speeds up merging when it's set up well. But the research doesn't back treating it as a fix for everything, and how well the work is split, how deep the stack runs, and how comfortable the team is with rebasing all decide whether it helps or just adds friction.

A controlled experiment took one tangled PR, split the same change into two logically coherent PRs, and compared how reviewers handled each. Reviewers flagged fewer false-positive issues on the split version and approached the review differently. They didn't find more actual defects, finish faster, or come away with a better grasp of why the change was made. The lesson there is narrower than it sounds: separating concerns into coherent review units helps, but it doesn't guarantee faster or better reviews on its own.

The picture for agent-authored PRs specifically is even less settled. A separate 2026 study of review activity found plenty of agent-authored PRs with no recorded review at all, and among the comments that did exist, 71.58% were written by agents, not humans. Stacking a PR that no human ever actually reads is still an unreviewed change, just a smaller one.

Stacking isn't the right call in every situation. A small, self-contained change is simpler as one PR. If branches aren't genuinely dependent on each other, filing them as parallel independent PRs is the honest version of that workflow, not a stack. Teams that aren't comfortable with rebasing will find the coordination cost outweighs whatever review benefit they were chasing. Depth matters too: practitioners generally treat three or four layers as the practical ceiling before coordination costs eat the benefit, and a stack five layers deep is a management problem distinct from one that's two layers deep. And if a layer keeps getting rewritten, those rewrites cascade upward through the whole stack and can leave it less stable than a single branch would have been. The split itself, done well or done badly, is what decides whether any of this pays off.

Open-source, model-agnostic agents in a stacked PR workflow

Running an agent continuously across a team, rather than in occasional one-off sessions, raises a different question: whether anyone can actually see what the agent did and enforce decomposition discipline across the whole stack. That's where open, model-agnostic agent platforms have a structural edge over closed systems.

The gh-stack skill changes what a session produces by default, but the underlying idea, teaching an agent the decomposition workflow through explicit instructions, works with any agent system built to take those instructions, not just one vendor's product. A model-agnostic setup lets a team pick which model handles which layer: one model tuned for code generation on the logic layers, a different one for writing tests, instead of funneling every layer through a single company's stack.

Running agents inside infrastructure the team actually controls, instead of a closed, cloud-hosted platform, means the record of what the agent did, which branches it created, what it committed, when each rebase happened, lives somewhere the team can inspect directly. For enterprise teams working under regulatory or compliance requirements, that's not a nice-to-have. Agent-generated code needs a traceable path from the original prompt to the merged PR, and that path has to be verifiable by someone other than the vendor that built the agent.

An open-source coding agent platform can be built around exactly that model: model-agnostic, deployable inside a team's own infrastructure, with the visibility needed to run agents continuously across a stacked workflow without losing track of what happened at each step. Teams can assign separate agents to separate layers of a stack and pull up the full execution history for each one afterward.

The single-reviewer bottleneck that recurs in agent PR research reflects a workflow design flaw as much as a tooling gap. Spreading review across layers, and spreading agent authorship across layers with clear scoping rules, cuts down that single point of failure, but only when the underlying agent system gives enough visibility to trust each layer before a human signs off on it. A 2026 arXiv paper lays out a future where reviewers stop manually inspecting every line and instead supervise staged, AI-run workflows. Stacked PRs are already the structural shape that makes that kind of supervised, staged delivery possible.