The Change Arrived in Chapters

The pull request says it contains one feature. The files tab says it contains a small country.

There is a database change, an API shape, a new component, a migration, tests, documentation, and a tidy generated summary assuring everyone that the work is ready for review. The reviewer opens the diff between meetings, scrolls until the green and red begin to resemble weather, and leaves comments on the parts that remain small enough to hold in working memory.

This was a familiar engineering problem before coding agents. Better generation has made it easier to arrive there.

GitHub's new preview of stacked pull requests offers a useful change in shape. Instead of presenting one large branch against main, a developer can arrange a series of dependent branches. Each pull request targets the layer below it. A reviewer sees the diff for that layer, while a stack map shows where the layer sits inside the larger change.

The stack can land all at once, or only its lower layers can merge. Pull requests above a merged layer automatically rebase and retarget. Existing checks and branch protections still apply. The feature does not make the work smaller. It gives the work chapters.

That distinction matters because review has always been partly an attention design problem. A change can be correct and still be shaped badly for another person to understand. One giant diff asks the reviewer to reconstruct the author's sequence of thought from the final pile of files. A stack can preserve some of that sequence: first the data contract, then the service behavior, then the interface that depends on both.

The unit of production no longer has to become the unit of review.

This is especially useful as agents make production less expensive. GitHub includes an account from TED's engineering team: AI-assisted work made developers more productive, but the resulting pull requests grew large enough to strain reviewers. Dependency-ordered slices made the work easier to examine as logical changes rather than as one polished delivery.

That is a healthier response than asking review to accelerate until it matches generation. The machine can produce another thousand lines without needing another thousand lines of attention. The person still has to understand what the change teaches the codebase to become.

Smaller diffs are not automatically safer, though. A chapter can be beautifully edited while the book has the wrong plot.

The first layer may introduce an abstraction that looks reasonable in isolation. The second makes that abstraction feel necessary. By the fourth, the architecture has hardened around a choice nobody reviewed as a whole. Each pull request passes its checks. Each local comment gets resolved. The stack merges with the emotional texture of five careful decisions, even if the consequential decision happened in the relationship among them.

This is where the stack map becomes more than navigation. It is a draft mark on the change itself.

We have argued that polished work needs draft marks: finished-looking artifacts need visible places where human judgment can still attach. A dependency map does that for code. It tells the reviewer that the current diff is a bounded view, not the whole object. The branch below is an assumption. The branch above is a consequence. The clean page in front of you belongs to a larger argument.

Good stacked review therefore needs two postures. The layer review asks whether this focused step is understandable, tested, and honest about what it changes. The stack review asks whether the sequence makes sense as a system: whether boundaries still belong where they were drawn, whether an early compromise became invisible through repetition, and whether landing the complete stack creates a risk no individual check can see.

The interface should protect both views. Show the layer without making the rest disappear. Make dependency order prominent. Keep comments attached when a lower layer changes. Let a reviewer see which assumptions have already been accepted and which later branches will make expensive. If one click can merge the stack, the same surface should make the full consequence easy to inspect before the click.

AI review can help with this, but it inherits the same geometry. GitHub now lets Copilot code review use repository skills and read-only MCP context, with attribution when that context shapes a comment. Teams can also give the reviewer branch-local instructions, setup steps, and a controlled network environment. Those are useful ways to make review more situated.

More context does not repair a badly presented change. A reviewer with access to every service catalog, issue tracker, and engineering standard can still miss the architectural turn buried on line 2,614. Context has to arrive in a shape attention can use.

This extends the case that AI code review needs disagreement. High-value disagreement is easier to preserve when the object is small enough to discuss. The important review comment is often not “this line fails.” It is “this layer is asking the system to believe something we will regret.” A stack can give that conversation a room before the finished feature makes objection feel late and expensive.

There will be bad stacks. Teams will slice changes mechanically, creating seven pull requests that must be opened in order to understand one renamed function. Authors will optimize for green checks and call the result reviewability. Agents will become very good at producing dependency trees that look disciplined. Every useful workflow eventually acquires a ceremonial version of itself.

The test is whether the chapters help another person think.

A considerate change lets the reviewer stay close to the local work without losing the system around it. It acknowledges that comprehension has a pace, that sequence carries meaning, and that review is not the administrative delay between generation and merge. Review is where a private implementation becomes shared responsibility.

The change arrived in chapters. The interface still has to let us read the book.