Turning a Massive AI-Generated Pull Request into a Reviewable Stack

Coding agents tend to implement entire features at once and submit them as massive pull requests exceeding 1,000 lines. This approach makes it difficult for reviewers to grasp the changes, degrades feedback quality and merge speed, and consequently increases the risk of merging insufficiently reviewed code.

To address this, GitHub proposes stacked pull requests. This method decomposes a single large PR into multiple layers focused on a single concern, configuring each PR to depend on the previous layer to make them small and independently reviewable.

An example of adding product search to a shopping assistant is divided into the following 4 layers:

• L1 feat/catalog-data: Adds typed catalog, seed data, validation, and data access modules based on main.
• L2 feat/search-api: Adds the /api/products/search API endpoint with validation features and depends on L1.
• L3 feat/chat-grounding: Connects the chat feature to call the API and answer with actual product data, depending on L2.
• L4 feat/grounded-ui: Adds product citation cards and various UI states, depending on L3.

When constructing a stack, you must first specify the stack base. Then, place the most foundational task at the bottom of the stack and stack dependent tasks such as API, feature integration, and UX on top in order. This allows appropriate reviewers to be assigned by change area, such as data owners reviewing the data layer and UI owners reviewing the presentation layer.

This structure clarifies the review scope compared to previous methods that required manually organizing the entire implementation created by agents and managing conflicts. As Gartner predicts that coding agents will boost productivity by 50% across the software development lifecycle by 2028, the way PR structures are designed becomes increasingly important as agent usage grows.