Use Stacked Pull Requests to Make AI Code Review Managable

AI coding tools can produce a surprising amount of code in a short time.

That can be useful, but it has also made an old engineering problem more visible: generating a change and reviewing a change are not the same job.

An agent can update a data model, create a migration, modify an API, change a user interface, add tests, and revise documentation in one session. The result may even build successfully. A reviewer still has to understand what changed, determine whether the design is appropriate, identify hidden risks, and decide whether the change is safe to merge.

A 4,000-line pull request doesn't become easy to review just because an AI tool produced it quickly. (You can see my prior social video posts about just how fun it can be!)

GitHub's general availability of stacked pull requests provides a timely way to address this problem. Stacks aren't an AI feature, but they can be a key part of an AI-assisted development workflow because they encourage us to break a large outcome into smaller, dependent, reviewable changes.

Faster Code Generation Creates a Review Bottleneck

When writing the code was the slowest part of a task, a large pull request often represented several days of work. AI-assisted development can compress some of that implementation time, but it doesn't reduce the reviewer's responsibility.

The reviewer still needs to answer questions such as:

• Does the data model represent the requirement correctly?
• Is the authorization boundary enforced in the correct layer?
• Does the migration preserve existing data?
• Are errors observable and actionable?
• Do the tests validate behavior, or merely repeat the implementation?
• Did the agent change anything outside the intended scope?

Those questions require context and judgment. Large pull requests make both harder because unrelated concerns compete for the reviewer's attention.

The answer is not to stop using agents for meaningful work. Instead, design the work so a human can evaluate it effectively, or even additional AI agents!

What a Stacked Pull Request Changes

A stacked pull request workflow represents one larger change as a sequence of smaller pull requests. The first pull request is based on the main branch. The next is based on the first, and the sequence continues until the complete feature is represented.

For example, a feature might be divided into the following stack:

1. Add the domain model and database migration.
2. Add the service and authorization behavior.
3. Add the API or Blazor user interface.
4. Add end-to-end tests and documentation.

Each pull request has a narrower purpose and a more understandable diff. Reviewers can evaluate the foundation before spending time on dependent code. It also lets reviewers focus more easily.

GitHub's stacked pull request support keeps the relationship between those pull requests visible. It also supports rebasing and merging the stack while preserving its order. That reduces some of the branch-management friction that previously made this workflow feel more complicated than the code itself.

Small Does Not Mean Arbitrary

The goal isn't to split a change based on a line-count limit. A small pull request can still be confusing, and an arbitrary split can make the feature harder to understand.

Each layer in a stack should represent a coherent engineering decision. A reviewer should be able to describe what the pull request does, why it exists, and what is intentionally deferred to the next layer.

Good boundaries often follow the way risk enters the system:

• Schema and persistence: Can the database change be applied and reversed safely?
• Business behavior: Are validation, authorization, and state transitions correct?
• Integration: Are external services, queues, or APIs handled reliably?
• User experience: Does the interface communicate states, failures, and permissions correctly?
• Operational readiness: Are tests, telemetry, deployment notes, and rollback steps present?

This structure also gives an AI agent clearer constraints. Instead of asking it to “implement the feature,” we can ask it to work within one defined layer and stop before crossing into the next concern.

Give the Agent a Change Plan Before Code

Stacked pull requests work best when the stack is planned before the agent begins making broad changes.

A useful request might look like this:

Plan this feature as a sequence of small, dependent pull requests.

For each pull request, identify:
- Its single purpose
- The files or layers it may change
- The tests that prove the change
- Its dependency on earlier pull requests
- What must be deferred to a later pull request
Do not modify code until the plan is approved.
    

This does not guarantee a perfect plan. It creates an explicit point where a human can correct the architecture before a large volume of code exists.

Once the plan is approved, the agent can implement one pull request at a time. The stop point matters. An agent that quietly crosses three planned boundaries has recreated the large-review problem under several branch names.

Make Every Layer Independently Reviewable

A pull request in a stack may depend on an earlier pull request, but it should still be understandable on its own.

Each pull request description should include:

• The decision introduced by this layer.
• The earlier pull request on which it depends.
• The behavior a reviewer should concentrate on.
• The commands or automated checks used to validate it.
• Known limitations that are addressed later in the stack.

Tests should align with the same boundary. If the first pull request introduces persistence behavior, it should include tests that validate that behavior. Deferring all tests until the final pull request weakens the value of reviewing the stack in layers.

The same principle applies to generated summaries. An AI-written pull request description can be a helpful starting point, but it should not replace a developer's responsibility to verify that the description matches the actual diff.

Do Not Use a Stack to Hide an Unsafe Change

Stacked pull requests improve reviewability, but they do not make a risky design safe.

A stack may be the wrong approach when intermediate changes cannot pass required validation, an early database change would break the currently deployed application, or partial merging would leave the repository unusable.

Feature flags, backward-compatible database changes, and expand-and-contract migrations may be needed so that each merged layer remains deployable. In some cases, keeping the entire stack unmerged until every layer is approved is appropriate. The team should decide that strategy before work begins.

We should also avoid allowing the number of pull requests to create false confidence. Five lightly reviewed pull requests are not safer than one carefully reviewed pull request. The benefit comes from focused review, not from the stack itself.

Measure Review Quality, Not Generated Volume

GitHub reports that repositories using stacked pull requests during the preview experienced increases in merged code and improvements in time to merge. Those product-level results are interesting, but they should not become the only measures a team uses.

More merged code is not automatically better code. For an AI-assisted team, I would pay attention to:

• How long a pull request waits for meaningful review.
• How often reviewers request structural rework.
• How many defects escape after approval.
• Whether developers can explain code produced with an agent.
• Whether each change can be deployed and rolled back safely.

The goal is not to maximize agent output. The goal is to turn useful output into changes the team understands and is willing to support.

A Practical Starting Point

Don't start by forcing every task into a stack. Start with one feature that naturally crosses several application layers and has clear dependency boundaries.

1. Ask for a pull request plan before code is written.
2. Review the proposed boundaries and merge strategy.
3. Implement and validate one layer at a time.
4. Require a focused description and matching tests for every pull request.
5. Review the completed stack as one product change before release.

AI coding agents can help us move faster, but speed also increases the importance of how we divide and review work. Stacked pull requests give teams a useful way to turn a large result into a sequence of understandable decisions.

The key shift is simple: don't let the size of an agent's output determine the size of the review.

Have you tried stacked pull requests with AI-assisted development? I would be interested to hear whether they improved review quality or simply changed where the workflow became complicated.  Or, even without AI usage, have you used stacked pull requests and noticed a difference?