GitHub Just Shipped Stacked PRs. Here's Why Small Teams Running AI Coding Agents Should Care Most

Hero: a git log --graph view of branched, merged, and stacked history — the actual shape of the code arriving in a small team’s repo. Terminal screenshot: PerfektesChaos / Wikimedia Commons, GPL.

On July 30, 2026 — three days ago as this publishes — GitHub put stacked pull requests into public preview. Native support, on github.com, with a CLI extension (gh extension install github/gh-stack), stack-aware review UI, and one-click merging of an entire stack into a merge queue.

If you work at a big company, this is old news wearing a new badge. Meta, Google, and half the well-funded startups in your feed have run stacked-diff workflows for a decade through internal tooling or third-party layers like Graphite, ghstack, and spr. The interesting part is not that stacking exists. The interesting part is who suddenly gets it for free — and the timing.

Because here’s the situation on the ground in 2026: solo builders and 2–5 person teams are generating more code per week than mid-size teams did a few years ago, mostly via coding agents. And nearly all of that code is arriving in exactly the wrong shape — one giant, thousand-line pull request that nobody can honestly review. GitHub’s own launch post quotes the CTO of TED saying the quiet part out loud: AI made their developers “dramatically more productive,” and the direct result was PRs “growing large enough that reviewers were struggling.”

That’s the actual story. Stacked PRs are not a big-company feature trickling down. Right now, in the agent era, they’re a small-team survival tool. This piece explains what shipped, how the workflow actually operates, why agent-driven development makes it urgent, and how to adopt it this week without ceremony.

What actually shipped

Concretely, the July 30 public preview gives you:

• Stacks as a first-class object. A stack is an ordered series of pull requests where each PR targets the branch below it instead of main. PR 1 targets main, PR 2 targets PR 1’s branch, PR 3 targets PR 2’s branch, and so on.
• A CLI extension. gh extension install github/gh-stack adds stack commands to the GitHub CLI, so you can create, restack, and push stacks from the terminal. GitHub also published an agent skill for it, which matters more than it sounds — more on that below.
• Stack-aware review UI. Opening any PR in the stack shows only the diff for that layer, plus a “stack map” at the top showing where this layer sits in the larger change. Reviewers can work different layers in parallel.
• One-click merge of the whole stack — or land layers individually. Stacks work with existing branch protections, required checks, and merge queues. Nothing about your protections changes; each layer still has to pass.
• Automatic retargeting. When a lower layer merges, the layers above it retarget automatically. This is the part that used to eat your afternoon.

That last point deserves emphasis, because it’s the reason most people who tried to do this manually gave up. You could always technically stack branches on GitHub — branch B off branch A, open PR B against branch A. The trap sprang when PR A merged: PR B’s target vanished, diffs went stale, and you entered rebase purgatory, force-pushing branches in order and hoping you didn’t invalidate a review. The manual version of this workflow costs more than it saves for a small team. The native version makes the platform do the bookkeeping.

The 90-second mental model

If you’ve never worked with stacked diffs, here’s the whole idea:

A big feature is almost never one change. It’s a sequence of dependent changes: a schema migration, then a data-access layer, then the API endpoint, then the UI, then the docs and cleanup. The traditional options were both bad:

1. One mega-PR. Reviewable in theory, reviewed in practice by scrolling to the bottom and typing “LGTM.” Risky to merge, brutal to revert, and it blocks all downstream work until the whole thing lands.
2. Sequential small PRs. Ship the migration PR, wait for review, merge, then start the data layer. Clean, but you spend half the week blocked on your own review latency — which for a solo maintainer with outside contributors, or a two-person shop where the reviewer also does sales, can be days.

Stacking is the third option: write the migration, stack the data layer on top of it, stack the endpoint on that, and keep moving. Each layer is a small, coherent, reviewable PR. Review happens in parallel with your continued work. When the bottom of the stack is approved, it merges, everything above retargets, and the conveyor belt keeps moving.

The pancake metaphor is genuinely the right one: thin layers, eaten one at a time, but it’s still one breakfast.

Why this matters now: agents write big diffs

Here’s the uncomfortable math of coding-agent output in 2026.

An agent given a real task — “add team billing,” “migrate the auth flow” — does not naturally produce five tidy sequential PRs. It produces one working tree with everything changed at once: forty files, the migration, the handlers, the tests, the incidental refactors it decided to do along the way. If you’re disciplined, you prompt it into smaller chunks; most people aren’t, and even chunked output tends to arrive faster than a human can review it.

That creates the specific failure mode everyone in this space is circling right now. The essay “Why Software Factories Fail” (humanlayer, late July — one of the most-discussed dev posts of the past two weeks) puts it bluntly: throughput of generated code isn’t the constraint anymore; verified, understood, merged code is. Review is the bottleneck, and unreviewed mega-merges are how you end up with a codebase nobody on the team can actually explain. In the same vein, developer Ruben Weeraman’s widely shared piece this week — “AI doesn’t generate working products, that’s still your job” — makes the complementary point: the gap between a prototype-shaped diff and a product is exactly the verification work that big PRs let you skip.

Small shops feel this worse than big ones, not better:

• You have one reviewer. Maybe. In a two-person team, every mega-PR is a multi-hour tax on the other person. In a one-person team, it’s a multi-hour tax on future you, who will read git log in six months looking for the commit that broke invoicing and find a single 4,000-line “feat: billing” merge.
• Reverts are your only rollback. Small teams rarely have feature-flag infrastructure. If the mega-PR broke something, you revert the whole thing — including the four unrelated fixes riding along in it.
• Agents amplify your merge habits. Whatever your review discipline is, an agent multiplies the volume flowing through it. Sloppy-times-ten is a lot of sloppy. (Related: the handbook-following benchmark showed frontier agents only follow written rules 36% of the time even with the SOP right there in the context — so “we told the agent to keep PRs small” is not the same as “the PRs are small.”)

Stacked PRs attack this directly, and notably, GitHub built for the agent case on day one: the gh-stack skill means you can tell a coding agent — Copilot, Claude Code, whatever you run — to deliver its work as a stack. That is the practically important sentence in the whole launch. “Implement team billing as a stack of PRs: schema, service layer, API, UI — each layer independently green” is now an instruction an agent can execute against native platform plumbing, instead of a convention you enforce by hand.

The small-shop workflow, concretely

Here’s a realistic adoption path for a 1–5 person team. No new SaaS, no process documents.

Step 1 — install the extension (one minute).

gh extension install github/gh-stack

Step 2 — pick your layer convention. The layers that work in practice are boring and predictable:

1. Prep/refactor — the changes that make the feature possible without changing behavior. Renames, extractions, dead-code removal.
2. Schema/data — migrations and models.
3. Core logic — the service or domain code, with its tests.
4. Surface — API routes, UI, CLI flags.
5. Cleanup/docs — the stuff that otherwise never ships.

Martin Fowler’s site ran a piece on July 30 (Kaiser/Fowler, “The Economic Benefit of Refactoring”) arguing the economics of small, continuous refactoring are stronger in the gen-AI era, not weaker — and layer 1 is exactly where agent-assisted refactoring belongs: isolated, behavior-neutral, trivially reviewable, merged first.

Step 3 — make your agent target the convention. Add it to your repo’s agent instructions file (CLAUDE.md, AGENTS.md, whatever your tool reads): “For multi-part changes, deliver work as a stacked series of PRs using gh-stack. Each layer must build and pass tests independently. Prep refactors go in their own bottom layer.” This is a one-paragraph prompt change that converts unreviewable output into reviewable output. (Just remember what the handbook benchmark taught: written policy is a wish, not a wall — verify the shape of the actual output for the first few features.)

Step 4 — review bottom-up, merge as you go. Review the bottom layer first — it’s usually the safest and smallest. Merge it the moment it’s green; the stack retargets itself. You’ll frequently find that layers 1–2 of an agent’s stack are mergeable in minutes, which shrinks the risky surface of what’s left.

Step 5 — keep layers honest. The rule that keeps stacks useful: every layer must be green on its own. If layer 3 only compiles because layer 4 exists, they’re one layer. The discipline sounds fussy but pays for itself the first time you need to land an urgent bottom layer while the top of the stack is still half-baked — or revert one layer without unwinding the week.

When not to stack

Honesty section. Stacking is a tool with a shape, and some work is the wrong shape:

• Truly atomic small changes. A bug fix that’s 30 lines is a PR, not a stack. Don’t ceremonialize it.
• Exploratory spikes. If you don’t know what the layers are yet, stacking prematurely just means restacking later. Spike on a scratch branch, then rebuild the work as a stack once the shape is clear — agents are genuinely good at this “re-deliver it cleanly” step.
• Public-preview caveats apply. This shipped 72 hours ago. Expect rough edges in the UI, expect the CLI extension to iterate quickly, and expect some third-party integrations (review tools, CI dashboards) to not understand stacks yet. If your deploy pipeline makes assumptions about PR base branches, check them before you go all-in.
• Solo with no review at all. If literally nobody reviews your code and you don’t read your own diffs, stacking won’t save you — though it does make self-review dramatically more likely to happen, because reading five 200-line diffs is a task and reading one 1,000-line diff is a punishment.

It’s also fair to note the ecosystem angle: Graphite, ghstack, and similar tools built businesses on exactly this gap, and a native free version changes their landscape the way native features always do. If you’re already happy on one of those, there’s no urgency to move — but if you never adopted them because it was one more tool and one more login, that objection just expired.

A worked example: shipping “customer notes” as a stack

To make this concrete, here’s what a real small-shop feature looks like both ways. Say you run a service business on a homegrown Rails or Next.js app and you want to add customer notes — staff can attach timestamped notes to a customer record, notes show up in the customer view, and there’s a small audit trail.

The mega-PR version is what most agents produce by default: one branch, one PR, ~1,100 lines. It contains a migration, a model, a service object, two API routes, three UI components, a permissions tweak, and — because the agent noticed while it was in there — a drive-by rename of client to customer across fourteen files. The rename alone is 400 lines of pure noise wrapped around 700 lines of substance. Your reviewer (or future you) has to hold all of it in their head at once, and the permissions tweak — the only genuinely risky part — is buried on page six of the diff where nobody’s attention survives.

The stacked version of the identical work:

1. PR 1 — rename client → customer. 400 lines, zero behavior change, reviewable in ninety seconds because you’re only confirming it’s mechanical. Merged same day.
2. PR 2 — migration + Note model + model tests. 120 lines. Boring, safe, merged.
3. PR 3 — notes service + permissions. 180 lines, and now the risky permissions change is the whole PR, sitting alone under the reviewer’s full attention instead of hiding in the noise.
4. PR 4 — API routes + UI. 350 lines of mostly-mechanical wiring.
5. PR 5 — audit trail + docs. The layer that historically never ships, shipping.

Same code, same total line count, radically different review economics. The risky 180 lines got real scrutiny; the mechanical 750 got appropriately light scrutiny; and layers 1–2 were already merged and de-risked before layer 4 was even written. That last property — risk drains out the bottom of the stack while you’re still building the top — is the thing no amount of “please write smaller PRs” discipline gives you without platform support.

The bigger pattern: review is the product now

Zoom out and the stacked-PR launch is one data point in a trend line that’s been sharpening all month: the industry is rebuilding its tooling around the assumption that generation is cheap and verification is scarce.

Merge queues went from big-company exotica to a checkbox. Agents ship with skills for structuring their own output. Fowler’s crew is publishing economics arguments for refactoring in the AI era. The “software factory” discourse keeps converging on the same conclusion from different directions: the teams winning with agents aren’t the ones generating the most code, they’re the ones with the tightest loop between generated and trusted.

For a small shop, that’s actually good news, because tight loops are the one thing small teams can have that big teams can’t buy. You don’t need a platform team to adopt the workflow in this post. You need one CLI extension, one paragraph in your agent instructions, and the discipline to keep layers green. (And, since we’re on the topic of agents you turn loose in your repo: what layer of your setup is actually a policy vs. an enforced control is not always what you think it is — worth an audit while you’re already in your tooling.)

The feature’s been publicly available for three days. The backlog of agent-generated mega-PRs sitting unreviewed in small-team repos has been building for two years. Rarely does a free platform feature line up this cleanly with the actual bottleneck. Take the hour.

Try this week

• Install gh-stack and convert your next multi-part feature into a 3-layer stack. Time how long review takes versus your last big PR.
• Add the stack-delivery paragraph to your agent instructions file and ask your agent to re-deliver its next big change as a stack.
• Pick one stale mega-PR rotting in your repo right now and ask an agent to split it into a stack — this is a genuinely great first task, because the code already exists and you’re only changing its shape.

Sources

• GitHub Changelog — “Stacked pull requests are now in public preview” (July 30, 2026) — the launch post, including the CLI extension, review UI, merge behavior, and the TED/Vercel quotes cited above.
• github/gh-stack on GitHub — the official CLI extension for creating and managing stacks.
• Kaiser & Fowler — “The Economic Benefit of Refactoring” (martinfowler.com, July 30, 2026) — the economics of small continuous changes in the gen-AI era.
• humanlayer — “Why Software Factories Fail (or: harness engineering is not enough)” (late July 2026) — the review-bottleneck argument for agent-driven development.
• Ruben Weeraman — “AI doesn’t generate working products, that’s still your job” (August 2026) — on the verification gap between generated diffs and shipped product.