Engineering

Decomposing AI-Generated Pull Requests Into Stacks

By Edoworks · August 5, 2026

On August 4, 2026, GitHub published Julia Muiruri's post on turning one giant AI-generated pull request into a reviewable stack. The post is one of the clearest practical write-ups of a problem agent-driven development has created: coding agents are productive enough to produce 1,000-plus line diffs that no human can review well, and the path to fixing that is structural, not motivational. The answer is not to ask the agent to write smaller diffs. The answer is to decompose the diff into an ordered stack of small, independently reviewable pull requests, each scoped to a single concern.

The post walks through a worked example: adding product search to a shopping assistant. A naive agent run produces a single 1,721-line pull request containing a new data model and its seed data, an API route and its validation, and the client wiring, UI, and empty, fallback, and error states, all in one diff. The post then shows how to turn that into a four-layer stack using GitHub's native stacked pull requests and the gh stack CLI, with custom agents assigned per layer.

The un-reviewable giant PR

The problem the post names is familiar to anyone who has worked with coding agents. The agent is given a prompt, runs autonomously, and returns a complete implementation. The diff is large because the agent did the work that a human would have split across multiple sessions. The pull request description is long but shallow. CI checks turn green. Self-review is a diff scroll. Reviewers receive a PR that is too large to review well, so it sits, loses context, and eventually merges under-reviewed.

The post's framing is direct: agents amplify the need to make the choice between one giant PR and a chain of smaller PRs, because agents are productive enough to make the giant PR the default output. The trade-off is no longer between "hard to review" and "hard to maintain." The agent can maintain the chain if the structure is set up correctly, which removes the maintenance cost that previously pushed developers toward the single PR.

The stack decomposition

The post's stack structure for the worked example is four layers. Layer one is the data catalog foundation, a typed catalog with seed data, validation, and a data access module, branched from main. Layer two is the product search API, a validated endpoint, branched from layer one. Layer three wires chat to the API, branched from layer two. Layer four is the grounded UI with product citation cards and state, branched from layer three. Each layer is a single concern, small enough to hold in a reviewer's head, with enough context naturally flowing from the previously reviewed PR.

The decomposition principle is what makes the pattern general. Data, API, wiring, UX are independent concerns that can be allocated to different reviewers: a data owner reviews the data layer, a UI owner reviews the UI layer. The agent assignment in the post mirrors the layering: a data modeler agent owns layer one, a backend agent owns layer two, a frontend agent owns layers three and four. The agents are not the reviewers; they are the layer authors, and the human reviewer comes in per layer with a focused checklist.

Key insight: The agent writes the layer. The human reviews the layer. The stack propagates changes upward when a lower layer is revised. No layer ships without a human checkpoint, but the human checkpoint is small enough to be effective.

The review discipline that makes it work

The post describes the review flow as directional. Read top-down for context, so the reviewer starts with the end goal and sets a bearing. Review bottom-up to build on the predetermined checkpoints, because each layer only makes sense once the layer below it is understood. The stack map is the reviewer's compass, a one-click navigation system between PRs in the stack.

The change-propagation mechanism is what makes the pattern maintainable. When a lower layer is revised after review, GitHub flags that branches above it have diverged and must be rebased. The post recommends gh stack rebase over the one-click web rebase button, because the web rebase runs on GitHub's servers, resets the committer to whoever clicked the button, and produces unsigned commits that can break branch protection. A single gh stack sync then fetches from origin, cascades the rebase of every branch above the revised one onto the new commit, pushes the rebased branches, and syncs PR state from GitHub. The change ripples upward without anyone touching the upper layers by hand.

Why this matters for agent-driven development

The pattern matters because it solves the structural problem that agent-driven development creates without asking the agent to be less productive. The agent still produces a large amount of code. The code is just structured into layers that are independently reviewable, independently testable, and independently mergeable. The agent's productivity is preserved; the human's review burden is reduced to what a human can actually do well.

The post also surfaces an operational detail that matters for agent workflow design: each layer's CI checks run against the stack base, not just the layer's immediate parent. That means a change to a lower layer that breaks an upper layer's tests will be caught before the upper layer is merged. The stack is a dependency-ordered chain, and the dependency is enforced by CI, not by convention.

The per-layer agent assignment is the part most directly applicable to an agent-driven team. A layer with a single concern and a single author agent is a verifiable unit of work. The agent owns the layer, the layer has a focused reviewer, and the review is small enough to be meaningful. The pattern turns the agent's output from an un-reviewable blob into a stack of small, owned, reviewable units, which is what a review process needs to function.

References

The stacked pull requests pattern is a structural answer to the un-reviewable agent diff. The pattern preserves agent productivity while making the human review checkpoint effective.