The Real Problem Is Not That AI Writes Code
The problem is that AI-assisted development makes large diffs feel cheap. A developer can ask a coding agent to add a feature, refactor a service, update tests, touch documentation, and clean up types in one run. The agent happily produces one wide patch. Then the team pretends the resulting pull request is reviewable. Very wholesome. Completely fake.
Large pull requests were already bad before AI coding tools arrived. They mix decisions, hide risky changes behind boring edits, and make review comments expensive because any requested change may ripple through the whole branch. AI just makes the failure mode more common. The code arrives faster than the review process can absorb it.
That is why GitHub stacked pull requests matter. GitHub describes stacked PRs as a way to break large code changes into a chain of smaller, dependent pull requests that can be reviewed and merged independently, and its docs currently mark the feature as public preview: https://docs.github.com/en/pull-requests/get-started/about-stacked-prs.
For teams using AI coding agents, the interesting part is not the pancake icon. It is the discipline: one task, one layer, one reviewable unit.
What A Stacked PR Actually Is
A stacked PR is a set of pull requests where each later PR is based on the branch below it. The bottom PR targets the trunk branch, often main. The next PR targets the branch from the first PR. The next one targets the branch from the second. The chain represents dependency order.
For example, an AI-assisted feature might become this stack:
- PR 1: Add database fields and migration.
- PR 2: Add backend service logic that depends on those fields.
- PR 3: Add API endpoint using the new service.
- PR 4: Add UI changes consuming that endpoint.
- PR 5: Add documentation and integration tests.
That is much better than one 2,500-line pull request titled “implement account exports,” which is developer-speak for “good luck, everyone.”
GitHub’s docs say stacked PRs can be used through GitHub CLI, the GitHub website, GitHub Mobile, and programmatic surfaces such as webhooks, REST API, and GraphQL. The same docs also note two practical limits: stacked PR branches must be in the same repository, and GitHub Desktop is not supported for stacked PRs at the time of writing.
The same-repository requirement matters for open source maintainers. If a contributor works from a fork, this may not be the right workflow yet. Inside a company repo, though, it is much easier to standardize.
Why This Fits AI Coding Work Better Than One Big Pull Request
AI coding tools are good at continuing. That is useful and dangerous. Once a coding agent has enough context, it may keep editing adjacent files because the next step seems obvious. Sometimes it is obvious. Sometimes it is a confident detour wearing a little hard hat.
Stacked PRs force a pause between concerns. The developer can ask the tool to produce a foundation change, stop, test it, open a PR, then continue on top of that branch. The result is still AI-assisted code, but the review surface becomes human-sized.
This pairs well with a policy the team should already have: AI-generated or AI-assisted changes need a paper trail. Not a novel. Just enough context for a reviewer to know what was requested, what files changed, what tests ran, and where the human author took responsibility. Notavello covered that review discipline in AI-written pull requests need a paper trail.
The stack becomes that paper trail’s skeleton. Each PR answers one question:
- What does this layer change?
- What earlier layer does it depend on?
- What tests prove this layer works?
- What should the reviewer ignore because it belongs to another layer?
That last question is underrated. Reviewers waste enormous time separating “this is the actual change” from “this is a dependency I cannot approve yet.” Stacks make the dependency visible instead of implied.
The CI Cost Is Real, So Plan For It
Stacked PRs do not make continuous integration cheaper by default. GitHub says workflows for stacked PRs run as if each pull request targets the base of the stack, so a workflow configured for pull requests into main runs for every PR in the stack, not just the bottom one: https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests.
That is the correct safety default. It is also a lovely way to burn CI minutes if the team turns every five-line change into a seven-layer tower.
The practical answer is to split checks into tiers:
- Every layer: formatting, linting, type checks, focused unit tests, and cheap security checks.
- Lowest unmerged layer: checks that prove the next mergeable piece is safe.
- Top layer: expensive integration tests that need the full combined change.
- Nightly or manual: slow end-to-end suites, load tests, and non-blocking exploratory scans.
GitHub exposes stack metadata to workflows, including stack size, position, and base branch. That gives teams enough information to avoid blindly running every expensive job on every layer.
A simple rule works well: every PR in the stack must be independently understandable, but not every PR must run the most expensive test suite. If a layer changes a README, it does not need the full production-shaped integration circus. The circus can wait for the top of the stack. It has little shoes to polish anyway.
How To Split An AI-Assisted Change Into A Useful Stack
The split should follow dependency order, not file type and not whatever order the coding agent happened to edit files. A good stack starts with the lowest-risk foundation and climbs toward user-visible behavior.
Use this order when it fits:
| Layer | What Goes There | Reviewer Question |
| 1 | Schema, types, interfaces, feature flags | Is the foundation small and compatible? |
| 2 | Core logic | Is the behavior correct without UI noise? |
| 3 | API, adapters, integration code | Are boundaries and errors handled? |
| 4 | UI or user-facing surface | Does the feature behave as expected? |
| 5 | Docs, cleanup, broader tests | Does the final package make sense? |
Do not create a stack where every layer is “misc cleanup.” That is not a stack. That is a junk drawer with branches.
Also avoid splitting changes so thinly that reviewers need five tabs open to understand one idea. A stacked PR should be smaller, not microscopic. The target is a pull request that can be reviewed with confidence in one sitting.
When using an AI coding agent, give it explicit boundaries. For example: “Create only the migration and type changes. Do not update service logic yet.” Then inspect the diff before asking for the next layer. This is slower than letting the agent rip through the repo. It is also how adults ship software.
The Review Rules Should Change With The Workflow
Stacked PRs are only useful if the team changes how it reviews them. If reviewers still wait until the entire feature is done, the stack has become decorative branch origami.
Set a few rules:
- Review bottom-up. The foundation must be sound before higher layers get serious attention.
- Keep each title boring and specific. “Add export job status enum” beats “export improvements.”
- Require a short stack summary. The top PR or tracking issue should explain the full chain.
- Do not hide risky changes in upper layers. Authentication, permissions, data deletion, billing, and migrations deserve their own obvious PRs.
- Close or rewrite bad stacks early. A confusing stack is not better than a confusing large PR. It just has more tabs.
For AI-assisted work, require the author to say which parts were generated, which prompts or tasks were used at a high level, and what manual checks were performed. The reviewer is reviewing the code, not the vibes.
The biggest benefit is social as much as technical. A stack tells the reviewer, “Here is the path through this change.” That lowers review friction. It also makes it harder for generated code to sneak in as one overwhelming blob.
Use Stacked PRs For Big Work, Not Every Work
Not every pull request needs to be stacked. A typo fix does not need dependency choreography. A small bug fix should not become a three-act play. Use stacked PRs when a change is large, dependent, or likely to be generated in phases by an AI coding tool.
The sweet spot is work that is too connected to split into unrelated pull requests but too large to review honestly as one. That includes refactors that unlock a feature, backend changes followed by UI work, migrations followed by application logic, and agent-generated task sequences.
GitHub stacked PRs are not a substitute for code ownership, tests, security review, or a human author who understands the patch. They are a better container. And with AI coding tools producing more code than teams can comfortably review, better containers are not a luxury. They are the difference between useful acceleration and a faster mess.