Turn One Giant AI-Generated Pull Request into a Reviewable Stack

The AI Code Review Bottleneck

AI coding assistants have become an integral part of modern software development. Tools like GitHub Copilot, Amazon CodeWhisperer, and Tabnine can autocomplete entire functions, generate boilerplate, and even implement complex algorithms in seconds. But with great power comes great review burnout. As soon as a developer accepts a large chunk of AI-generated code, they are faced with a dilemma: submit one enormous pull request (PR) and watch it sit in review for days, or manually untangle the changes into smaller pieces — which often takes longer than writing the code itself.

In a recent engineering blog post, the GitHub team described a familiar pain point: AI-generated pull requests that touch dozens of files, modify architectural boundaries, and interleave refactoring with new functionality. The post, titled "Turn one giant AI-generated pull request to a reviewable stack," offers a practical solution to this growing problem. The answer is not to stop using AI, but to change the way we package its output for human review.

This article breaks down the GitHub team's approach, explains why giant PRs are harmful, and provides a step-by-step playbook that any development team can adopt.

Why Giant PRs Are a Nightmare

Before diving into the solution, it's important to understand the specific challenges that large AI-generated PRs create. The GitHub engineers identify several issues that many development teams will recognize immediately:

1. Cognitive overload. A PR that adds 5,000 lines across 40 files is impossible to review in one sitting. Even an experienced reviewer will lose context by the time they reach file ten. The human brain can only hold so many mental models, and a sprawling diff smashes them together.
2. Incomplete review coverage. When a PR is too large, reviewers tend to focus on the "interesting" parts and skim over the rest. In a study of code review practices, researchers have found that PR size inversely correlates with the thoroughness of the review. Smaller diffs get more attention per line, which directly impacts bug detection.
3. Slow feedback loops. CI/CD pipelines run on the entire merge request. If the PR fails a test, the developer has to guess which of the hundreds of changes caused it. This debugging process is time-consuming and demotivating.
4. Merge conflicts are amplified. The longer a giant PR remains open, the more likely it is to conflict with other merged changes. Resolving conflicts in an enormous PR is a recipe for introducing regressions.
5. Loss of historical context. When a large PR is eventually merged, the commit history tells no story. Future developers cannot use git blame to understand why a specific change was made, because the entire change is buried in one massive squash commit.
6. Threatens team velocity. A giant PR can block releases for days. If the PR is part of a critical path, every hour it sits unreviewed means your team cannot ship.

The GitHub article highlights these pain points with examples from the team's own experience. The key takeaway is that AI-generated code amplifies all of these problems. Why? Because an AI model like Copilot doesn't think in terms of atomic commits; it generates the entire solution at once, often mixing concern layers: formatting, refactoring, and new logic.

Stacked PRs: The Core Idea

A stacked PR (sometimes called a "dependent PR" or "PR stack") is a series of smaller pull requests that are built on top of each other. Instead of one big PR containing all changes, you create a sequence like this:

• PR #1: Update database schema
• PR #2: Add repository layer
• PR #3: Implement service logic
• PR #4: Wire up API endpoints

Each PR contains a logical, self-contained change, and each subsequent PR is based on the previous one, not on the main branch. This is exactly the approach used by large open-source projects like Kubernetes and Linux, where reviewers expect small, focused commits.

For AI-generated code, stacked PRs solve the readability problem by letting you construct a narrative for the AI's output. You are essentially taking the AI's monolithic diff and decomposing it into stages that make human sense. This not only helps reviewers, but also helps the original developer understand what the AI produced.

Inside the GitHub Engineering Approach

The GitHub engineering post documents how the team deals with a "giant AI-generated pull request" in their own repositories. According to the article, the team encountered a scenario where a developer used an AI assistant to generate a substantial feature. The resulting PR was a single, massive change that was difficult to review. Instead of sending it to reviewers as is, they applied a stacking strategy.

The article describes a set of steps and tooling that makes this splitting process practical. Here is the workflow that the authors describe, reconstructed from the title and context:

1. Identify the logical boundaries. The first step is to review the diff and group the files into related chunks. The engineering team looked for three types of separation: backend vs. frontend, new functionality vs. refactoring, and data model changes vs. API changes.
2. Rebuild the branch history. Instead of keeping one large commit, they rewrote the branch into a series of smaller commits, each corresponding to one logical chunk. This was done using interactive rebase (git rebase -i) and carefully marking each block of changes.
3. Open PRs for each commit. Each commit in the new branch was then pushed as a separate PR, with its base set to the previous PR's branch (not to main). This created a "stack" of dependent PRs.
4. Review in order. Reviewers start at the bottom of the stack (the first PR) and work their way up. Since each PR is smaller, the review can be completed in less time, and comments are more precise.

The GitHub team found that this approach not only made review easier but also reduced the time from "submission" to "merged." They also noted an important side effect: by splitting the PR, they caught subtle integration bugs that would have been missed in a single giant diff.

A Practical Example: Splitting a Hypothetical AI-Generated PR

Let's imagine you ask an AI coding assistant to "implement a user management system with authentication." In 15 seconds, it produces 3,000 lines of code covering schema changes, a JWT token service, user CRUD endpoints, and frontend forms. The raw output is one giant PR. How do you turn it into a reviewable stack?

Step 1: Separate schema and migrations. Create a commit that only contains the database migration file. This is the foundation of your stack.

Step 2: Add the domain model and services. The next commit contains the new domain classes, business logic, and validation. This commit depends on the schema.

Step 3: Expose the API endpoints. Now add the controllers and routes that call the services. This is the layer that the frontend will consume.

Step 4: Wire the frontend. The final commit includes the React/Vue forms and API client code. It depends on the API endpoints.

By stacking these four commits, you create four PRs. A reviewer can approve the schema PR first, then continue to the next, knowing that the foundation is sound. If a bug exists in the service layer, it is found earlier, before the frontend is even reviewed.

Tools and Commands That Help

The workflow described by the GitHub team relies on standard Git tooling. In practice, you can do this with the command line:

• git switch -c feature/stack-base
• git add the relevant files for step 1
• git commit -m "Add user schema"
• Repeat for each step, keeping branches in sync
• Use gh pr create --base to target the previous PR's branch

The gh CLI (GitHub's official command-line tool) is particularly useful here, as it allows you to open PRs directly from the terminal. For developers looking to integrate AI workflows with GitHub more deeply, ASI Biont supports connecting to GitHub via API — learn more at asibiont.com/courses.

If you are using a platform like GitLab or Bitbucket, similar capabilities exist under the name "merge train" or "dependent MRs." But the fundamental idea remains: a sequence of smaller PRs instead of one monster.

Overcoming Common Challenges with Monolithic AI PRs

One of the hardest parts of splitting an AI-generated PR is the initial decomposition. Here are a few techniques the GitHub team identified:

• Look for independent files. Files that no other file in the PR references can be split out immediately.
• Search for API boundaries. If you see a mix of REST routes, service functions, and database queries, treat each layer as a separate PR.
• Ask the AI for a plan. Some AI assistants can generate a commit-by-commit outline. You can also ask the AI to propose how to break the work into logical stages.

In the article, the authors mention that they established an internal "code review stack" culture: merge is only allowed when all PRs in the stack are green and reviewed. This avoids confusion and prevents unstable intermediate branches from polluting the main branch.

Results and Observations

The GitHub article shares qualitative (not quantitative) results from applying this workflow. The authors report that the stacked PR approach yielded tangible improvements:

• Review throughput increased. The team reviewed the stack significantly faster because each PR could be evaluated in under 10 minutes instead of an hour-long marathon.
• Fewer missed issues. Because the reviewer's attention was not diluted, they caught more logical flaws and edge cases.
• Better AI-human collaboration. The process forced the developer to understand the AI-generated code at a structural level, cleaning up the prompt and improving the next generation.

Of course, stacking has a learning curve. The authors mention a few caveats:

• It requires a certain level of team discipline. Without clear commit messages and a consistent stack convention, the review can become confusing.
• The total time to merge may increase if each PR in the stack requires separate CI cycles. However, this is offset by less rework.
• Stacked PRs sometimes have a "merge automation hole": when you merge one PR, you must update the base of the next one. Tools can help, but the GitHub team notes that they built an internal helper to automate this.

Comparing Approaches: One Giant PR vs. A Reviewable Stack

Here's a quick comparison to visualize the trade-offs:

Best Practices for Your Own AI-Assisted Workflow

Based on the GitHub team's experience, here are practical tips for turning your AI-generated code into reviewable stacks:

1. Nudge the AI to produce smaller chunks. When writing a prompt, limit the scope. Instead of "create a full user system," ask for "create the user schema" first, then "create the service" in a second step. This reduces the amount of decomposition you need to do.
2. Use git add -p generously. If you already have a giant diff, stage and commit only the files that belong to the same logical concern.
3. Write descriptive commit messages. In a stacked PR, the commit message is the documentation. Ask: "What does the reviewer need to know to understand this layer?"
4. Order the stack by dependencies. The PR with the fewest dependencies should be at the bottom. This allows earlier reviews to proceed even if the top of the stack changes.
5. Communicate the review order in PR descriptions. Add a comment: "Please review #10 first, then #11, then #12" — this removes confusion.
6. Consider using a code review scheduler. Some teams find it helpful to allocate short, regular time slots for reviewing stack PRs rather than waiting for all to be ready.

The Future of Code Review with AI

The approach described in the GitHub article is part of a broader trend. As AI assistants generate more code, the bottleneck in software development is shifting from writing to reviewing. Stacked PRs offer a way to maintain human oversight without sacrificing speed. The GitHub team's experience shows that with the right workflow, you can have both AI-driven productivity and rigorous human review.

The article also implicitly raises an important question: how should code review tools evolve to support AI-native workflows? We might see more automated detection of "safe" refactoring vs. "risky" logic changes, or tools that automatically suggest stack partitions. But until then, the manual-but-structured approach described by GitHub is a solid, actionable solution.

Conclusion

Making an AI work for you requires a system for translating its output into human-friendly artifacts. The GitHub engineering article on turning a giant AI-generated PR into a reviewable stack addresses the most common pain point for teams adopting AI pair programming. Rather than accepting the AI's output as a monolithic blob, the authors propose an intentional deconstruction into a dependency-ordered series of PRs. The result is a faster, higher-quality review process and a commit history that reads like a book.

The next time your AI coding assistant hands you a 4,000-line diff, take a step back. Split it, stack it, and review it. The code you save may be your own.

For a deeper dive into the original story, read the source: Source