How to Split Large PRs using AI: A Practical Guide

Large pull requests are review nightmares. They sit around for weeks, accumulate conflicts, and often get approved with only a superficial glance. The good news? You can use AI to split them systematically - without losing your sanity. 

When to Split a PR

• It has 50+ changed files

• It contains multiple unrelated (or semi-related) features

• It has been sitting around for weeks without review

Step 1: Understand Dependencies

Before starting any actual work, the most important part is mapping the dependencies between different components in you PR. This is the most crucial step! If you get this right, it'll save you a lot of time moving forward

What you need to discover in this phase:

• Which files define core types, interfaces, or base classes

• Which files import and use other files

• The dependency chain of the files in your PR

• Whether we have any circular dependencies between modules (although they shouldn't exist regardless of how big your PR is...)

How to discover that:

• Ask AI - “Show me all the files in this PR that define new classes, interfaces, or types.”

• To understand all the dependencies ask “Create a dependency graph of all the new files in the PR. For each new file, understand which files use each files” and then “Do the same for all new functions/types/etc that are used in existing files” 

Step 2: Design Your Split Strategy

This is a very important part. It'll probably take a few iterations to get it right, but it's a very good investment in your future self, trust me;)

You can let the AI create a few different design strategies, and iterate through them to get one final design you feel comfortable with

Initial split decisions

• Decide how many small PRs you want to create. Rule of thumb - Try to keep each PR to under 40 files and the total count to under 5 PRs if possible.

• You almost always want to have a "foundation" PR that includes all the new classes/interfaces/types etc, even if they're not used yet. That'll make it easier to handle the next PRs.

Choose Your Dependency Strategy

There are a couple of options on if and how your PRs relate to one another that you should consider.

• Parallel PRs:

  • All PRs depend only on the foundation PR. Can be reviewed simultaneously.

  • Only if dependencies are clean. If possible - use this option!

  • Dependencies look something like: PR 1 => PR 2 + PR 3 + PR 4

• Sequential PRs:

  • Each PR builds on the previous one.

    • Must merge in order

    • PRs are compared to the previous PR, and not to main/dev

  • Creates more overhead but in many cases it's inevitable

  • Dependencies look something like: PR 1 => PR 2 => PR 3 => PR 4

Actual planning

• After preparing a few different options, you need to consider the pros and cons of each, and choose the one you want to move forward with.

• After you have you're chosen design ready, ask "What could go wrong with this strategy? Which dependencies might be broken?" - that might save a lot of time later on

Step 3: Start implementing your design

Let AI create the branches for you according to the final design:

• According to the design, have the AI create your branches one at a time, starting with the foundation

• Branches that depend on other branches should use them as base

• Give the branches meaningful names, but keep them generic enough in case you make some changes later on

Step 4: Fix Issues Across PRs

Unless you're very lucky, your first attempt probably didn't work so smoothly. But don't loose hope, AI can fix it for you in no time.

Some of the issues you might encounter are

• Missing dependencies

• Test failures

• Import errors

How to Fix them?

• You can try to move files from other PRs if you see they're needed here

• Don't hesitate to fix issues by adding mocked code with a "will be implemented later" to avoid moving around a lot of files

Prompts I used

• "These are the errors in this PR, fix them by either moving necessary files from other PRs, or by adding mocks or unimplemented code to temporary resolve these issues. Choose the solution that would cause the minimal amount of changes and complexity"

How to handle breaking changes

• If you make a change to the base PR (that all other PRs depend on) then you need to merge the changes back

• What worked for me was solving all the issues with the first PR before moving to the next

• You can ask AI to do that for you: "Merge PR 2 into PR 3 and resolve the conflicts to match the original large PR"

Step 5: Validation Strategy

Before submitting, validate that your split works:

• For each PR individually make sure it:

  • Builds without errors

  • All tests pass

  • Linting/formatting passes

• If you have sequential PRs (PR 1 depends on 2 which depends on 3 etc) then make sure the last PR, when compared to develop, matches your original large PR. That'll make sure nothing was lost in the process.

• Ask AI if your PRs are safe to merge and deploy one by one, or will partial implementation might cause production issues.

General guidelines

Don’t:

• Split arbitrarily by file count or alphabet

• Create branches before mapping dependencies and creating a design

• Force parallel PRs when dependencies exist

• Fix everything at once across all PRs

Do:

• Spend time upfront mapping dependencies

• Invest time and effort iterating over your design until it's good enough

• Test each PR independently before moving forward

The Key Insight

The difference between a successful PR split and a frustrating mess comes down to one thing: understanding dependencies first.

AI is excellent at analyzing complex codebases and suggesting fixes - but only if you give it the right context and guide it with the right questions

Spend effort upfront mapping dependencies and designing the your split strategy rather than scrambling from issue to issue later. The architectural decisions are yours, but AI can guide the technical details.