Originally published on antoniel.sh.
TL;DR How to use AI and stacked PRs to make life easier for your team when reviewing a large PR.
The problem
You open a PR and realize it has around 10k lines of changes. At that point, the problem is not only the code size. It is the review experience. A PR that large is hard to reason about, easy to postpone, and easy to review poorly.
In retrospect, it should have been a stack from the start.
Stacked PRs
The first clear explanation of stacked PRs I saw was in Tomas Reimers's GitKon 2022 talk on the topic: Stacked Pull Requests | GitKon 2022 | Tomas Reimers, Graphite. The idea is simple: instead of one giant PR, you create a sequence of smaller PRs where each one builds on the previous one.
Graphite is one of the tools associated with that workflow, but the key idea is independent of any tool. A stack is easier to review because each PR carries one part of the story.
| One huge PR | Stacked PRs |
|---|---|
| One review with too much context | Multiple reviews with clear boundaries |
| Refactors and feature work mixed together | Each PR carries one part of the change |
| Easy to postpone or skim | Easier to review in order |
A practical guide
Ideally, you plan the stack from the beginning and group changes by delivery. But sometimes you only notice the problem when the PR is already too large. In that case, AI can help you break the branch into a reviewable stack with much less manual work.
- Ask AI to split the branch into stacked PRs.
- Validate that the final stacked branch preserves the original change.
- Ask AI to generate the
ghflow to open the PRs in order.
Using AI to stack PRs
This is one of those cases where the prompt can stay simple.
My branch against
mainhas a huge diff. Split it into stacked PRs. Create the branches locally and I will push them.
The result can come back in a format like this:
I split the branch into 5 stacked PRs.
Merge order:
1. stacked (foundation)
2. 02-api-cleanup (base: stacked)
3. 03-shared-types (base: 02-api-cleanup)
4. 04-backend-flow (base: 03-shared-types)
5. 05-frontend-flow (base: 04-backend-flow)
How to validate nothing was lost
The check that matters
Once the AI gives you a proposed stack, the next step is validation.
I need a quick way to compare the original branch with the final stacked branch and verify that nothing important was lost.
That gives you a command like this:
git --no-pager diff main <original-branch> --shortstat && echo "" && git --no-pager diff main <last-stacked-branch> --shortstat
If both summaries are effectively the same, the stacked branch preserves the original change. Small formatting differences are fine; the overall shape of the diff should remain the same.
61 files changed, 10234 insertions(+), 487 deletions(-)
61 files changed, 10240 insertions(+), 492 deletions(-)
Automating PR creation with gh CLI
Once the diff checks out, the remaining problem is operational: opening each PR and setting the right base branch.
The gh flow
I already have the stacked branches. Give me a
ghCLI flow to open the PRs in order and set each base branch correctly.
Push all branches first, then use the generated gh flow:
PR1=$(gh pr create --base main --head <stacked-1> --title "[1/5] Foundation changes" --body "Stack 1 of PROJECT-123" | grep -oE '[0-9]+$')
PR2=$(gh pr create --base <stacked-1> --head <stacked-2> --title "[2/5] API cleanup" --body "Depends on #$PR1" | grep -oE '[0-9]+$')
PR3=$(gh pr create --base <stacked-2> --head <stacked-3> --title "[3/5] Shared types" --body "Depends on #$PR2" | grep -oE '[0-9]+$')
PR4=$(gh pr create --base <stacked-3> --head <stacked-4> --title "[4/5] Backend flow" --body "Depends on #$PR3" | grep -oE '[0-9]+$')
gh pr create --base <stacked-4> --head <stacked-5> --title "[5/5] Frontend flow" --body "Depends on #$PR4"
Each gh pr create returns the PR URL; grep -oE '[0-9]+$' extracts the number for the next Depends on #N.
The lesson
If the work belongs in a stack, make it a stack. Ideally, do it from the beginning. If you notice too late, ask AI to help you split, validate, and open the PRs.
Top comments (0)