How to Split an AI-Generated PR Into a Reviewable Stack

Think about the last big feature your team shipped. Be honest: did it land as one giant pull request, or as a chain of small ones you babysat by hand, syncing branches and untangling conflicts every time something below changed? For years those were the only two options. One is hard to review. The other is hard to maintain.

Now add coding agents to the picture. They are genuinely productive — Gartner projects a 50% productivity gain across every stage of the software development lifecycle by 2028 — but they do not remove the choice of how you structure a pull request. They amplify it. An agent’s default is to solve the whole problem in one pass and hand you one enormous diff, because that is how most of the code it trained on was written.

We build Kahoona, and we watch this happen constantly: generation is getting cheap and fast, while review is still the bottleneck. Review — not writing — is where a five-person team actually pays for AI. So when GitHub published its own playbook for turning one giant AI-generated pull request into a reviewable stack, we read it closely. Here is the practical version.

The default: one ginormous diff

GitHub’s example is adding product search to a shopping assistant. You prompt the agent, walk away, and minutes later it returns a pull request containing all of this at once:

• a new data model and its seed data
• an API route and its validation
• the client wiring, the UI, and the empty, fallback, and error states

That is a 1,721-line diff. The reviewer’s reaction, quoted from the post, will feel familiar: “1,721 lines changed!! This description isn’t very helpful. I’ll review this later.”

And then the familiar cascade: the pull request sits there because nobody wants to review it. Reviewers lose context, so feedback quality drops. Merging slows down. The feature eventually lands under-reviewed, or dies in the stack of “later.”

The reviewer, looking at the diff.

The fix: stacked pull requests

Stacked pull requests are a different structure of delivery. The principle is decomposition: instead of one pull request that addresses the whole issue, you break the feature into logical layers, figure out the dependency chain, and ship a stack of small, focused, independently reviewable pull requests.

GitHub’s example stack:

Each layer is one concern, small enough to hold in a reviewer’s head, with context flowing naturally from the pull request below it. You also get a side benefit we like: different people can review different layers. The data owner reviews the data layer; the UI owner reviews the UI. No single person has to hold all 1,700 lines.

The commands that make it work

The setup takes two commands, and the second one is the interesting part:

gh extension install github/gh-stack
gh skill install github/gh-stack

The extension gives you the stack workflow. The skill teaches the skill — literally: it installs instructions your coding agents can follow, so the agents learn to create and manage stacks on your behalf. The workflow per layer is: initialize the stack with gh init stack (first branch, main as base), add each layer on top with gh stack add, run checks, and commit only when green. When the layers are done, gh stack push and gh stack submit open all the pull requests.

Reviewing a stack has its own etiquette, straight from the post: read top-down for context, review bottom-up. The stack map at the top of each pull request is a one-click navigation system between layers — you know the end goal first, then verify each checkpoint as you climb.

The trade-off nobody puts in the marketing

Here is the honest part. A stack turns a big unreviewable diff into a small maintenance chore — but it is a real chore, and it has teeth.

When a fix lands on the bottom branch out of turn, GitHub flags the whole stack: “Some branches in this stack have diverged and must be rebased,” and it blocks the merge. There is a one-click Rebase stack button, and it works — but it runs on GitHub’s servers. That means the committer resets to whoever clicked the button, the resulting commits are unsigned, and if your branch protection requires signed commits, that one click quietly breaks it.

The safer equivalent is gh stack rebase locally, resolving conflicts with your own Git configuration, then gh stack push, then gh stack sync to ripple the change upward through every layer. That last command is the point: one change at the bottom of the stack propagates to the top without anyone touching layers two, three, and four by hand.

What a small team should take from this

You are trading a 1,721-line review for a rebase ritual with clear commands. For a small team, that is a good trade — review is your scarce resource, and a stack protects it. But it only works if the structure is a habit, not a heroics move. Agents make decomposition cheaper to do and easier to skip.

That is the same bet we are making with Kahoona: put the artifact and its review on one surface, so “generated” and “approved” stay close together instead of dissolving into threads nobody re-reads. If your agent can write 1,700 lines in minutes, the only question that matters is whether your review process can keep up.

👉 Keep review on one surface, free to start

Related: Review Pull Requests Without a Meeting · Pull Request Dashboards, Explained