workflowReview & Merge10 min read

The Reviewable Stack

Our take

Roughly two thirds of agent-assisted pull requests never merge. Usually not because the code is wrong, but because nobody can hold four hundred lines of someone else's reasoning in their head, so the diff waits, goes stale, conflicts twice and dies. The fix is not a faster reviewer. It is a smaller unit, and as of July 2026 you no longer have to build the tooling for it yourself.

Slice one agent-generated change into an ordered stack of pull requests: each layer a single intent, each reviewable on its own diff, each with its own reviewer, all landing in one operation. GitHub shipped this natively with a CLI and a skill the agent itself can drive, which turns "keep your pull requests small" from advice the author ignores at the end into a shape the agent produces from the start.

On this page10 parts

01The Problem
02What Changed
03Getting It Running
04How to Slice
05The Review Contract
06Measure the Merge Side
07Why This Matters for Senior Teams
08Where It Fits in the Stack
09When Not to Use It
10Source

The Problem

Generation stopped being the constraint about two years ago, and most teams never moved their measurement. CircleCI's 2026 State of Software Delivery, drawn from roughly 28 million workflow runs, found average throughput up 59% year over year while main-branch throughput for the median team went the other way and fell. Their own framing for it is the whole problem in three words: more code, less software. The work is getting produced. It is not getting shipped.

LinearB's 2026 benchmarks, across more than 8.1 million pull requests from 4,800 teams in 42 countries, say where it stops. At the 75th percentile, AI-assisted pull requests ran 2.6 times larger than unassisted ones, 408 lines against 157. Agent-generated pull requests waited 5.3 times longer before a reviewer picked them up, 1,055 minutes against 201. And roughly a third of them merged at all, against roughly 85% of unassisted ones.

Read those numbers together and the failure mode is not quality. A pull request that sits seventeen hours before a first look, on a diff two and a half times the size a reviewer is calibrated for, is a pull request that will be rebased twice before anyone reads a line of it and abandoned on the third conflict. The code was probably fine. The unit was unshippable.

Salesforce Engineering measured the other half of it. After AI tooling raised their code volume by around 30%, pull requests routinely passed 20 files and 1,000 lines, and review time on the largest ones plateaued and then began to fall. That is the number to be frightened of, and it is worth sitting with for a second. Review time going down as diffs get bigger does not mean reviewers got faster. It means they stopped reading. Their conclusion is the sentence this section exists for: the bottleneck was not code creation, it was preparing that code for safe shipment.

"Write smaller pull requests" has been the advice for fifteen years and it has never once worked at scale, for a boring reason. It asks the author to do extra work against their own interest at the exact moment they are finished and want to move on. Nothing about an agent changes that incentive. What changes is that the agent will happily do the extra work, for free, if you make the shape part of the task.

What Changed

GitHub put stacked pull requests into public preview on 30 July 2026, and the reason they gave for building it is the one above: coding agents can now produce an entire feature in one pass, and without a mechanism for splitting it, teams trade the writing bottleneck for a reviewing one.

A stack is an ordered chain of pull requests in one repository. Each branch builds on the branch below it, and each pull request targets that branch rather than main. The consequence is the entire point: a reviewer opening layer three sees the layer three diff only, not the two layers of foundation underneath it that someone else already approved. Merging the top ready layer lands it and every unmerged layer beneath it in one operation. Merging a middle layer auto-rebases and retargets everything above it.

Three details decide whether this works on a real team:

Layers review in parallel.Your staff engineer takes the schema at the bottom while a Frontend reviewer takes the panel at the top, on the same day, without either waiting for the other. Serial review of one big diff has no equivalent.
The agent can drive it.GitHub ships a gh-stack skill that teaches coding agents how stacks work, and names agents as first-class stack participants. This is what moves decomposition from cleanup to authoring.
Merge queue support is rolling out separately, and has a sharp edge.The whole stack enters the queue in order, and if a layer is ejected, everything above it is ejected with it. Check where that rollout stands before you design a process around it.

The hard limits at preview: one repository, no cross-fork stacks, no GitHub Desktop. If you are not on GitHub, the pattern predates the feature by years and Graphite, Sapling and Gerrit all implement it. The methodology below is the part that matters and none of it is GitHub-specific.

Getting It Running

bash

1gh extension install github/gh-stack
2
3# the bottom of the stack is the layer that has to be right
4gh stack init prefs-schema
5
6#   ...write the table and the migration...
7gh stack add -Am "prefs: table and migration"        # commits this layer, opens the next
8
9#   ...write the endpoints...
10gh stack add -Am "prefs: read and write endpoints"
11
12#   ...wire the route, then build the panel...
13gh stack add -Am "prefs: settings route reads from the API"
14gh stack add -Am "prefs: settings panel UI"
15
16gh stack submit    # one pull request per layer, each based on the layer below it
17gh stack           # the stack: pull request links, checks and last commit per layer
18gh stack rebase    # cascading rebase, after a lower layer changes in review

gh stack modify is the one to learn second. It drops, combines, inserts, reorders and renames layers interactively, which is what you reach for the first time a reviewer says "these two are really one change".

How to Slice

The tooling gives you layers. It does not tell you where to cut, and a badly cut stack is worse than one honest big pull request because it multiplies the ceremony without reducing the thinking. Four rules carry almost all of it.

Slice by reviewer, not by file count.GitHub's own worked example is data, then API, then wiring, then UX, and the reason that example is good is that each layer has a different right reviewer. If two adjacent layers go to the same person and they would read them together anyway, they are one layer.
Order by cost of being wrong.The bottom is the schema, the contract, the token, the thing that is expensive to change after it lands. The top is copy, spacing, layout, the things that are cheap. Reviewers then spend their attention in the same order, which is what you actually wanted from review all along.
One layer, one intent.If the layer title needs the word "and", it is two layers. This is the rule the agent can check itself, and the one to put in the prompt.
Never mix generated and hand-written in one layer.A codemod output and a judgement call are read completely differently. Four hundred mechanical edits reviewed as a rule, in their own layer, is a five-minute review. The same edits sprinkled through a feature layer make the whole thing unreviewable.

The decomposition belongs in the plan, before implementation, not in a cleanup pass afterwards. That is the direct payoff of Spec-Driven Development: the plan's steps are the stack's layers, so approving the plan is approving the review shape. Once your AGENTS.md says features land as stacks and names the slicing rules, you stop asking for it every time.

The Review Contract

A smaller diff buys attention. It does not buy context, and an agent-authored layer arrives with none: no author to ask, no commit history of intent, no hallway conversation. So the agent owes the reviewer an artifact per layer, and it costs the agent nothing to produce.

What changed and why, in the layer's own terms, not a restatement of the diff.
The evidence it works.Named tests that now pass, and for any layer that renders, the screenshot from the Browser Verification Loop. A layer whose only evidence is "it compiles" is a layer nobody has checked.
The risk note.What this layer could break, and what is deliberately not covered. This is the one reviewers actually read, and the one an agent will skip unless you ask for it.

Then put a second model in front of the human. A fresh-session Writer / Reviewer pass, or ai-tools via /cr-react, runs per layer and clears the mechanical findings before a person spends attention on them. The human is then reviewing intent and risk, which is the only part of review that was ever scarce.

Measure the Merge Side

If your delivery dashboard counts pull requests opened, commits, or lines generated, it is measuring the half that stopped being hard, and it will show a triumph in the same quarter your release slips. Four numbers say whether any of this worked:

Reviewer pickup time, split by agent-authored and human-authored. The 5.3x gap is the single most actionable number in the LinearB set, because it is a scheduling problem, not an engineering one.
Merge rate of agent-authored pull requests.If two thirds are dying, you are paying for work that never ships and calling it velocity.
Diff size distribution, not the mean. The mean hides the 1,000-line outliers that are doing the damage.
Rework after merge.Churn on recently landed code is what tells you review got faster because it got better, rather than because it stopped happening.

Why This Matters for Senior Teams

It is the constraint you can actually move.You cannot hire your way past review capacity fast enough to match a fleet of agents, and telling reviewers to try harder is how you get rubber stamps. Changing the size of the unit is the only lever that scales with generation.
It protects the thing review was for.Every argument in this hub for verification assumes a human still exercises judgement somewhere. Salesforce's plateau is what that assumption looks like when it quietly fails. A reviewer who approves without reading is more dangerous than no reviewer, because the process still reports green.
It converts abandoned work into shipped work.The gap between a third and 85% is not a quality gap. It is a packaging gap, and it is the cheapest throughput available to most teams right now.
It gives the agent a target shape."Implement the feature" has no definition of done that a reviewer recognises. "Four layers, each independently reviewable, bottom layer is the schema" does, and the agent will hit it.

Where It Fits in the Stack

It is the missing half of Golden-PR Evals.Evals tell you the output is good. This tells you a human can accept it. A team with excellent evals and a 1,000-line pull request still does not ship.
Agent Teams generate the pressure this relieves.The moment you fan out agents across worktrees, review is the shared resource they all queue on. Fan out without a merge-side answer and you have built a faster way to fill a queue.
The Autonomy Ladder sets how far a layer runs unattended.Layers are not equal: the schema at the bottom deserves a lower rung than the panel at the top, and stacking is what makes that distinction expressible.
Continuous AI does the first pass on every layer.A per-layer agentic review in CI is what keeps the parallel-review promise honest when four layers land on four reviewers at once.
The Context Budget is the same argument pointed at a human.Attention degrades over a long window, findings drop off past a certain volume, and the answer in both cases is a smaller unit rather than a better prompt.

When Not to Use It

Not when the change is genuinely atomic.A rename that breaks the build unless every call site moves with it is one pull request. Splitting it produces layers that cannot be reviewed or merged independently, which is all cost and no benefit.
Not deeper than your team's review cadence.A nine-layer stack whose bottom layer waits three days is worse than one pull request, because every layer above it rebases when it finally moves. Match stack depth to how fast your reviewers actually turn around, and that is usually three or four.
Not as a way to make a large change look small.If no layer stands on its own and the split is arbitrary, you have not reduced the reviewing work, you have hidden it across seven tabs. Slice by intent or do not slice.
Not without CI on every layer.A green top layer says nothing about the layer below it. If your pipeline only runs on the pull request targeting main, fix that before you stack anything.
Not for free.Rebases cascade. When the bottom layer changes in review, everything above it moves, and on a deep stack with slow reviewers that cost is real. It is smaller than the cost of a dead 400-line pull request, but it is not zero and your team should hear it named.