GitHub Teaches AI to Split PRs

GitHub Takes Aim at the Hardest Second Half of AI Coding

On August 4, GitHub recently proposed a new workflow for AI coding agents: instead of having an agent produce a massive pull request containing dozens of files and thousands of changed lines in one shot, have it first break down the task, then generate an ordered set of individually reviewable stacked pull requests based on their dependencies.

This is not another feature designed to “make AI write code faster.” In fact, it points in the opposite direction—GitHub is applying the brakes to ever-faster code generation.

Over the past two years, improvements in coding models have mainly been reflected in the scope of tasks they can handle: from completing a single line of code, to modifying a function, to refactoring across directories, upgrading dependencies, adding tests, and updating documentation. An agent can work continuously in the background for dozens of minutes and ultimately deliver what appears to be a complete implementation. But the larger the deliverable, the harder it becomes for humans to determine exactly what it got right.

A massive PR that runs is not the same as a PR that can be reviewed.

The core of GitHub’s latest proposal is to change the unit of agent output from “complete the entire issue” to “generate a verifiable chain of changes.” For example, instead of squeezing an authentication system migration into a single PR, it could be split into:

1. Add new interfaces and data types;
2. Implement an adapter layer compatible with the old system;
3. Migrate callers in batches;
4. Switch the default implementation;
5. Remove old code and temporary compatibility logic.

Each layer builds on the previous one, and each PR shows only the changes added relative to the layer before it. Reviewers do not need to digest the entire migration at once; they can simply inspect the stack from the bottom up.

The Problem With Massive PRs Is Not Just That They “Look Exhausting”

Large AI-generated PRs are often attributed to a lack of team standards, but they are also a problem with the agent’s objective function. If the instruction is simply “complete this issue and submit a PR,” the model will naturally treat “task completed” as the sole endpoint. Whether the commit history is clear, each step can be tested independently, or reviewers can understand the changes is usually outside the scope of its reward function.

This delivery model creates at least five types of costs.

1. Reviewers’ Attention Is Quickly Exhausted

When renaming, formatting, interface changes, business logic, and test modifications are all mixed into the same diff, reviewers struggle to distinguish mechanical changes from those that alter runtime behavior. As the number of files grows, reviews often degrade from line-by-line verification into spot checks, eventually ending with little more than: “CI passed; looks fine.”

That is precisely the review approach AI-generated code should avoid. Models are good at generating implementations that appear locally reasonable, but they are also prone to mistakes involving cross-file constraints, error paths, and implicit business rules. The larger the diff, the easier it is for those mistakes to hide among otherwise normal code.

2. CI Can Only Tell You That “The Whole Thing Is Broken”

When a single PR modifies the database schema, service interfaces, and frontend calls at the same time, even a test failure may not quickly reveal which layer caused the problem. The agent may continue attempting patches, producing more overlapping changes and eventually creating a cycle of “fixing code just to make CI green.”

Stacked PRs, by contrast, contain failures within a smaller scope of change. Once the foundational interface PR passes, subsequent implementations can build on that foundation. If one layer fails, the boundaries of the investigation are much clearer.

3. Rollbacks and Bisection Become Difficult

Compressing a large volume of AI-generated code into a single commit may look clean, but it actually discards the evolution of the change. If a problem appears in production, the team can only roll back the entire change or reread thousands of lines of diff to find the most suspicious section.

Semantically meaningful atomic commits and stacked PRs naturally provide failure boundaries. The commit history can directly show which layer introduced a behavioral change and which merely migrated callers, making git bisect far more useful.

4. The Code Owner Mechanism Is Diluted

A large PR may simultaneously trigger review requirements from database, security, infrastructure, and business teams. Everyone gets pulled in, but no one truly owns the entire change. The result is often that each team reviews only the few lines it knows best, while no one verifies whether the cross-module combination works as a whole.

After splitting the work, different layers can be assigned to the appropriate owners: protocol changes can be reviewed by the platform team, permission logic by the security team, and business migrations by service owners. The boundaries of responsibility are far clearer than simply “@mentioning a group of people to take a look.”

5. Having AI Review AI Cannot Rescue a Poor Structure

GitHub Marketplace already offers many large-model-based automated code review Actions that can summarize diffs, identify common defects, and leave line-level comments. But if the input itself is a massive PR mixing multiple intentions, using another model to review it will not solve the underlying problem.

Long diffs create difficulties for AI reviewers similar to those faced by humans: context is consumed by irrelevant changes, cross-file relationships are hard to track, and comments become repetitive and poorly prioritized. Automated review can fill gaps, but it cannot replace a well-structured change.

How Stacked PRs Actually Work

Stacked PRs are not simply about “creating a few more PRs,” nor are they about randomly cutting a large diff into several pieces. The key is dependency order.

Suppose an agent needs to complete three stages:

• PR A: Add new types and interfaces, targeting main;
• PR B: Implement the interfaces, targeting the branch associated with PR A;
• PR C: Migrate business callers, targeting the branch associated with PR B.

From the perspective of Git history, B contains A, while C contains both A and B. But on GitHub’s PR pages, B shows only the implementation added relative to A, while C shows only the caller migration added relative to B. Reviewers always see the net change for the current layer rather than repeatedly reviewing the entire body of code.

A simplified command-line workflow looks like this:

git switch main
git switch -c agent/auth-01-contract
# Modify interfaces, types, and tests
git commit -am 'add new authentication contract'
gh pr create --base main --head agent/auth-01-contract

git switch -c agent/auth-02-adapter
git commit -am 'implement compatibility adapter'
gh pr create --base agent/auth-01-contract --head agent/auth-02-adapter

git switch -c agent/auth-03-migration
git commit -am 'migrate service callers'
gh pr create --base agent/auth-02-adapter --head agent/auth-03-migration

The point most likely to be misunderstood here is that having more commits does not necessarily make a change reviewable.

If an agent first modifies all the code and then mechanically splits it into ten commits based on file paths, the review experience will still be poor. A well-formed stack must satisfy three conditions: each layer has a single intent; each layer can be tested or statically verified; and each subsequent layer’s dependency on the previous one can be clearly explained.

In other words, what is being stacked is not files, but decisions.

Agents Must Learn to Plan Before They Learn to Write Code

What this approach truly changes is the coding agent’s execution loop. A traditional agent workflow typically looks like this: read the issue, search the codebase, make changes in bulk, run tests, and create a PR. The new workflow should add “change planning” before any code is modified and perform local validation after each layer is completed.

Teams can encode delivery constraints into agent instructions or repository rules, for example:

change_policy:
  delivery: stacked_pull_requests
  rules:
    - one_behavioral_intent_per_pr
    - separate_refactor_from_behavior_change
    - every_layer_must_have_validation
    - document_parent_pr_and_dependency
    - keep_each_layer_independently_revertible
  stop_conditions:
    - public_api_change_requires_human_approval
    - database_migration_requires_owner_review
    - security_boundary_change_requires_threat_review

These constraints are more effective than simply requiring that “each PR must not exceed 500 lines.” A line-count limit can prevent extreme cases, but it cannot determine whether a change is semantically complete. An automatically generated client may contain thousands of lines but embody only one logical change; a 30-line permission update may alter multiple security boundaries at once.

More appropriate criteria for splitting changes include:

• Whether a new public interface or data contract is introduced;
• Whether runtime behavior changes;
• Whether the change includes migration steps that can be independently verified;
• Whether approvals from different Code Owners are required;
• Whether the change can be rolled back independently;
• Whether mechanical refactoring is separated from business changes.

Agents also need to maintain stacks, not merely create them. After a lower-level PR receives review feedback, upper-level branches may need to be rebased. If a foundational interface changes, subsequent implementations and callers must be updated accordingly. If one layer is rejected or redesigned, the PRs above it cannot continue pretending they are mergeable.

This means a stacked workflow transfers some complexity from the reviewer to the agent. That transfer is reasonable: organizing branches, updating dependencies, and rerunning tests are repetitive tasks that machines handle well, while determining whether a design is correct and whether its risks are acceptable should remain the responsibility of humans.

It Is More Useful Than “Having AI Automatically Write PR Descriptions”

Many coding products currently focus on optimizing the presentation layer of PRs: automatically generating titles, summarizing changes, flagging risky files, and answering reviewers’ questions. These features are valuable, but they address “how to explain a diff that has already been generated.”

GitHub’s proposal goes one step further: control the structure of the diff before it is created.

The difference is similar to generating a summary for a poorly structured long-form article versus organizing the argument into chapters from the outset. A summary can help readers skim quickly, but it does not make the original text itself easier to verify. Structure is especially important for code because review is not about understanding the general idea; it is about confirming that every behavioral change satisfies its constraints.

Our assessment is that stacked PRs will become an essential capability for coding agents handling long-running tasks, but they will not be suitable for every change.

Forcing a stack onto a boundary-condition fix, a single configuration update, or an added unit test would only increase branch-management overhead. Stacking is truly suitable for cross-module refactoring, framework upgrades, database migrations, API evolution, large-scale caller replacements, and changes that require sequential approval from multiple teams.

When Adopting This Workflow, Teams Should Not Pursue Full Automation Immediately

Allowing an agent to determine every split boundary automatically still carries risks. A model may confuse what is convenient to generate with what is convenient to review, or it may create intermediate states that cannot run independently merely to satisfy PR size limits.

A safer implementation approach consists of three stages.

Stage One: The Agent Proposes a Plan, and Humans Approve the Boundaries

The agent first outputs a plan for the PR stack, including each layer’s purpose, parent PR, expected files, validation method, and rollback strategy. Once humans confirm the sequence, the agent begins modifying the code. This stage adds little cost but can prevent an incorrect architecture from being generated all the way to completion.

Stage Two: The Agent Automatically Maintains the Stack

Once the plan is approved, the agent takes responsibility for creating branches, making commits, opening PRs, updating dependencies, responding to review feedback on lower-level PRs, and rerunning CI. Humans focus primarily on design and behavior rather than manually cleaning up Git history.

Stage Three: Use Metrics to Constrain Delivery Quality

Teams should not merely count how many issues an agent completes. They should also track:

• Whether the time to first PR review decreases;
• How many rounds of changes each PR requires;
• Which layers attract the most review comments;
• Whether post-release rollbacks can target a single layer precisely;
• Whether humans frequently recombine or further split the PRs created by the agent;
• Whether the time from the bottom of the stack to full merge remains manageable.

If the number of PRs doubles but total review time increases, the split may be too fine-grained. If every layer still contains a large number of unrelated changes, the agent has only completed the split as a formality.

The Bottleneck in AI Coding Is Shifting From Generation to Acceptance

As coding models continue to improve, code output is no longer a scarce resource. What is truly scarce is the attention of humans who can take responsibility for that code, along with engineering processes capable of proving that changes are safe, correct, and maintainable.

By emphasizing stacked PRs, GitHub is sending a clear signal: the next phase of competition among AI coding tools will not be determined only by which one can modify more files at once, run for longer, or close more issues. It will also depend on which tool can organize machine-generated work into a form that humans are willing to merge.

The problem with massive PRs has never simply been that they are “too long.” It is that they compress multiple engineering decisions that need to be evaluated separately into a single “accept or reject” button. Stacked changes unfold those decisions again, allowing interfaces, implementations, migrations, and cleanup to be verified layer by layer.

Agents are responsible for producing code; humans are responsible for its consequences. For that division of labor to work, the former must deliver something the latter can review—not a wall of code that merely appears to run.

References

• AI Code Review Action: An example of an automated code review Action on GitHub Marketplace, demonstrating a typical use case in which a large language model comments on PR diffs and provides suggestions.
• pr-commit-ai-agent: A CLI agent project for organizing code commits and creating pull requests, which can serve as an implementation reference for automated commit workflows.