Stacked PRs and AI Worktrees

Mar 17, 2026·
Dr. Georg Heiler
Dr. Georg Heiler
· 6 min read
blog

AI coding agents can shorten implementation time. They do not reduce the need for code review, branch management, or merge coordination. In practice, those activities often become the limiting factor once agents can produce changes quickly.

Without a clear workflow, parallel sessions tend to create large diffs, overlapping branches, and avoidable merge conflicts. The problem is usually not model capability. It is the absence of a structure that keeps work small, traceable, and reviewable.

Review remains the constraint

Code review still determines how quickly code reaches the main branch. When a pull request grows while earlier feedback is pending, the reviewer receives a large mixed diff instead of one coherent change. That slows review and increases the chance that defects or unintended side effects are missed.

AI-assisted development amplifies that pattern. A model can generate a substantial amount of code in a short period, which makes it easier to accumulate work faster than a team can review it. If teams keep using a single long-lived branch, output increases but review quality often declines.

That pressure is now visible at the platform level as well. On January 27, 2026, GitHub opened a public discussion about low-quality contributions and said maintainers were spending substantial time reviewing submissions that often failed project guidelines, were abandoned, and were often AI-generated. Among the options GitHub said it was exploring were collaborator-only pull requests and disabling pull requests for specific repository use cases, which The Register later summarized as GitHub pondering a PR “kill switch.”

The practical requirement is straightforward: keep units of change small enough that they can be reviewed independently.

Monolithic PR vs. stacked PRs: one large branch compared with a sequence of smaller, reviewable pull requests.

Stacked PRs reduce review scope

Stacked PRs address that requirement by organizing work as a sequence of dependent branches rather than one large feature branch. A lower branch might introduce a schema change, the next branch might add API logic, and a later branch might update the user interface. Each pull request can then be reviewed on its own terms.

This offers two practical advantages. Reviewers see a narrower diff, and authors can continue working while earlier pull requests are under review. Once the lower branch is merged, the next pull request can be retargeted or restacked onto the main branch.

The trade-off is operational overhead. Managing dependent branches manually requires regular rebasing, careful branch targeting, and cleanup after merges. For stacked PRs to work consistently, the workflow needs tooling support.

stax as a supporting tool

stax is a Rust CLI for working with stacked branches and GitHub pull requests. It supports creating and submitting stacks, syncing and restacking branches, merging from the bottom of a stack, and recovering from risky history edits with st undo and st redo.

For AI-assisted workflows, several functions are especially relevant:

  • st resolve can assist with rebase conflicts by sending only the currently conflicted files to a configured AI agent.
  • st generate --pr-body can draft pull request text from the branch diff.
  • st submit --squash allows commit-heavy local iteration while still publishing a clean, one-commit pull request per branch.
  • st standup --summary can generate a short status summary across recent work.
  • st absorb helps route staged fixes back into the correct branch when review feedback spans multiple layers of a stack.
  • st worktree / st wt manage parallel worktrees that remain part of the normal stack model.

These features do not replace review or Git fundamentals. They reduce the overhead of keeping many small branches in order.

Agent worktree lanes

A useful part of the workflow is the agent worktree lane. Each lane is a separate Git worktree with its own tracked branch. That makes it possible to run multiple AI-assisted sessions in parallel without sharing a working directory or mixing unrelated edits.

# Create a lane for a test stability task
st wt c fix-tests --agent claude -- "fix the flaky integration tests in tests/api/"

# Create a second lane for a feature task
st wt c add-export --agent codex -- "add CSV export to the /reports endpoint"

# Inspect active lanes and their branches
st wt ll
st ls

In practice, each lane:

  • runs in its own worktree, which reduces interference between concurrent sessions,
  • uses a normal branch that appears in st ls and can be restacked or submitted like other stack entries,
  • can be re-entered later with st wt go,
  • can be combined with tmux for persistent long-running sessions.

AI worktree lanes: multiple isolated AI-assisted sessions managed as tracked branches within one stacked workflow.

A typical loop looks like this:

  1. Create lanes for independent tasks.
  2. Re-enter a lane later to inspect progress or continue work.
  3. Sync or restack lanes when the trunk branch moves, for example with st wt rs.
  4. Submit the resulting branches as pull requests.
  5. Remove the lane when the work is merged.

roborev as a review companion

roborev works at commit time: install a post-commit hook, commit frequently, and let it review each new commit in the background. Stacked PR workflows operate at a different level. In a stack, the unit that reviewers ultimately merge is the branch or pull request, not the individual commit.

That difference used to make the pairing feel awkward. roborev tends to encourage many small commits during the fix-and-review loop, while stacked PR workflows usually want a clean branch boundary. With the merged stax integration work, that boundary is now explicit instead of improvised.

In practice, the combined workflow is straightforward:

  • let roborev review incremental local commits while the branch is still in progress,
  • publish the stack with st submit --squash so each branch is presented upstream as one clean commit,
  • use st modify when you want review-driven edits folded back into the current branch before submission,
  • use st absorb when staged fixes belong to different branches in the stack.

The result is a better division of labor. roborev provides fast feedback during local iteration. stax remains responsible for branch structure, restacking, and presenting reviewable pull requests at the right granularity. The tools still optimize for different layers of the workflow, but they now integrate cleanly enough to use together on the same stack.

Why this matters for AI-assisted development

The main effect of AI coding tools is higher output volume. That makes branch structure and review discipline more important, not less. Teams still need a way to isolate changes, understand dependencies, and integrate work without turning every update into a large pull request.

Stacked PRs address review scope. Worktree lanes address parallelism and isolation. Used together, they provide a practical way to keep AI-assisted development compatible with normal engineering controls: smaller diffs, clearer sequencing, and more predictable merges.

This is less about any single tool than about workflow design. If AI-generated changes are going to be useful in a team setting, they need to arrive in a form that other engineers can review and merge without unnecessary friction.

References

Engineering Ai Developer-Tools Git
Dr. Georg Heiler
Authors
Dr. Georg Heiler
senior data expert
Georg is a co-founder @Jubust and a Senior data expert at Magenta as well as a ML-ops engineer at ASCII. He is solving challenges with data. His interests include geospatial graphs and time series. Georg transitions the data platform of Magenta to the cloud and is handling large scale multi-modal ML-ops challenges at ASCII.