GitHub Stacks the PRs Agents Made Too Large • The Weighted Average

GitHub has put stacked pull requests into public preview, letting teams review dependency-ordered layers separately and land an approved stack in 1 operation. For coding-agent teams, the switch is worth piloting now: a four-layer feature can expose 4 focused review surfaces for one ordered landing, but only if engineers design the stack before the agent writes the code.

GitHub finally treats review as the scarce compute

Agents made generation cheap before they made judgment cheap. The predictable result is a swollen pull request: hundreds of coherent-looking lines that take minutes to create and hours to understand. GitHub’s launch post names the new bottleneck directly. Stacks break a large change into an ordered series of PRs, each targeting the layer below it, so separate reviewers can inspect focused diffs in parallel while existing checks and branch protections remain active.

The workflow is native enough to matter. Teams can use github.com, mobile, or the gh-stack CLI extension; coding agents can install GitHub’s skill through the CLI. A ready pull request can merge along with every approved, unmerged layer beneath it in one operation. Merge a lower subset and GitHub leaves the upper PRs open, then rebases and retargets them. This removes the branch bookkeeping that made stacks feel like a private ritual practiced by unusually patient teams.

The derived payoff is structural, not a vendor productivity claim. GitHub’s official guide illustrates authentication as four layers: data model, CRUD endpoints, JWT middleware, and tests. That creates a 4:1 ratio of focused review units to ordered landing operations. It does not prove review becomes four times faster. It proves a reviewer can judge schema, API, policy, and verification as distinct decisions instead of reconstructing those boundaries inside one diff.

That decomposition is especially useful for agents. Install the skill, then ask the agent to propose the stack before generation: foundation first, dependent behavior above it, verification last. GitHub explicitly warns that the developer owns the shape of the stack. The tool can preserve dependency order; it cannot determine whether “refactor half the service” is a coherent layer.

The prerequisites are modest: GitHub documents gh 2.90.0 or later and Git 2.20 or later. The product is rolling out to all repositories, while merge-queue support arrives progressively. There is no announced separate SKU. Compared with buying another review platform, the adoption cost is mostly workflow training, extra CI runs, and the discipline to keep layers small.

This is the next step after Codex made agentic coding hands-free. Voice and parallel agents increase the number of changes a developer can launch. Stacked PRs answer the less glamorous question: how can a team absorb that output without turning review into archaeology?

A stack can distribute a mistake just as efficiently

The bottom layer is a single point of semantic failure. If an agent gets the data model wrong, every branch above inherits the mistake. GitHub’s guide therefore tells authors to review the foundation before proceeding and run tests, linters, and scans on every layer. Agent speed makes that advice more important, not less: fast generation can build four elegant floors on a crooked slab.

Operations also become more complicated. The GitHub FAQ says a cascading rebase stops when it hits a conflict; closing a middle PR blocks everything above it; cross-fork stacks are unsupported; and server-side rebases do not sign commits. If a stack merge fails midway, lower PRs remain landed while the failed layer and everything above it stay open. This is recoverable, but it is not atomic in the database sense.

More layers can multiply CI consumption and notifications. A team that turns a 200-line change into eight microscopic PRs may spend more attention on metadata than code. Reviewers can also approve layers independently while missing an emergent bug across their composition. Stacking improves local comprehensibility; it does not eliminate the need for an integration test or a final whole-stack read.

The right pilot is bounded. Choose one repository where agent-authored changes frequently exceed the team’s comfortable review size. Set a maximum layer size or review-time target, require each layer to pass focused checks, and preserve a final end-to-end suite on the top branch. Measure time to first review, rework after review, merge conflicts, escaped defects, and CI minutes. GitHub offers customer praise from Vercel, TED, and WHOOP, but no controlled improvement figures; your baseline must supply the evidence.

Teams should also define when not to stack. Independent fixes belong in parallel PRs, not an artificial dependency chain. Small changes stay single. Urgent production repairs should minimize branch choreography. Cross-repository work still needs a higher-level release plan. The technique earns its keep when one feature is too large for a humane review yet naturally decomposes into ordered, independently testable decisions.

The verdict changes if the preview proves unstable, merge queues lag, or rebases consume more time than review saves. It strengthens if a four-week trial cuts review latency and defects without exploding CI. Until then, treat stacks as a review architecture, not a throughput hack. The purpose is not to help agents ship more code. It is to let humans understand the code agents already made.

That distinction connects directly to Amazon’s capacity race: adding supply moves the bottleneck downstream. Clouds add compute; agents add diffs; the scarce resource becomes informed approval. GitHub has finally promoted that constraint into the product.