Turn one giant AI-generated pull request to a reviewable stack

AI编程助手生成的大量代码，终于不用再挤在一个巨型“代码包”里让人看得头大了！GitHub这次教大家用“堆叠式拉取请求”来拆分AI生成的代码，就像把一个大披萨切成好几块，每块独立上桌，评审起来轻松又高效。以前开发者写大功能，要么把所有改动塞进一个上千行的代码合并请求里，要么手动拆成好几个小请求，还得不停处理冲突，两边都麻烦。现在有了AI编程助手，代码生成速度飞快，更需要好的管理方式。堆叠式拉取请求是把一系列小改动按顺序叠起来，每个请求只干一件事，评审者可以逐个查看，逻辑清晰，不会迷失在海量代码中。对普通用户来说，这意味着未来AI帮我们开发的软件和App会更稳定、上线更快，因为代码质量更容易保障。对开发者而言，能省下大量纠结和等评审的时间，把精力真正用在打磨功能上。这项技术正在悄悄改变软件交付的方式，让AI写代码这件事变得更靠谱、更可控。

Think about the last big feature you shipped. Be honest. Did you cram it into one giant pull request, or did you split it into smaller scoped pull requests? For years, you have silently had to decide between watching a pull request grow so large that reviewing it becomes a nightmare or breaking it into a chain of smaller pull requests that you have to babysit, sync by hand, and untangle conflicts every time a change is introduced below. Both options have trade-offs. One is hard to review, while the other is hard to maintain. Your decision that day leans towards the less painful option. Now add coding agents. They are incredibly productive and are projected to drive a 50% productivity gain across every SDLC stage by 2028, according to Gartner. But, they can’t take away the choice of how you structure your pull requests. They amplify the need to make it. In this post, follow along with an example of how you can use stacked pull requests to simplify reviews. A closer look: Adding product search to a shopping assistant Let’s say you issue a prompt to add product search to a shopping assistant, walk away and minutes later, literally, you come back to review, steer, and approve. But look closely at what tends to land in that single pull request: A new data model and its seed data An API route and its validation The client wiring and the UI and the empty/fallback/error states …all of this and more in one ginormous 1,000+ line diff. For agents largely trained on how code has traditionally been written over the years, this pattern is their default way of shipping. Let’s play this out. You want to add product search on as existing web application and your starting state is: A mock AI Assistant showing responses from a random-line generator Inconsistent product data hardcoded and scattered across components No catalog module, no API, no data layer—no nothing An issue is opened to implement the feature, and a typical flow would be to create a feature branch, assign it to a coding agent (or multiple custom agents), get a first draft of the whole implementation code and updated tests… …you read the code (well, you maybe read the code). Then, you still need to manually verify feature behavior and make any necessary updates, push and open a pull request with its long-yet-shallow AI generated description, ensure CI checks are green, and self-review diff then request reviewers. You get started… <reviewer's hat> Reviewer: 1,721 lines changed!! This description isn’t very helpful. I’ll review this later. </reviewer's hat> And what follows is familiar: The large pull request becomes hard to review—so it just…sits there. Reviewers lose context and the feedback quality drops. It becomes even slower to merge. This kicks off a manual, messy, time-consuming process that’s prone to conflicts before the feature lands, and it eventually lands under-reviewed. GitHub stacked pull requests Stacked pull requests introduce a different and better structure of delivery. The principle is simple: decomposition. Instead of shooting for a single pull request that addresses the issue in its entirety, you break down the feature into logical layers and identify the dependency chain to arrive at your desired goal. This gives you, and your agents, a native way to decompose work that otherwise lands in a giant pull request into a chain of small, focused and independently reviewable layers. That large pull request that’s hard to review becomes a stack of smaller, logically ordered pull requests, each scoped to a single concern, small enough to hold in a reviewer’s head and with just enough context naturally flowing from the previously reviewed pull request. Let’s make it happen. The stack structure Let’s look at the steps involved when decomposin