Cap the size before the agent writes a single line.
TL;DR: Tell your AI to split work into small reviewable pull requests before it writes any code.
Common Mistake ❌
You ask your AI agent to build a feature.
The agent opens a 2,000-line pull request that touches twelve files across the backend, the frontend, and the tests.
You stare at the diff and you have no idea where to start reviewing.
Reviewer attention is the scarcest resource on your team today and a bottleneck.
You skim, you trust the tests, you click approve.
That pull request ships with defects you never saw.
Problems Addressed
Reviewers procrastinate on reviewing or skim huge AI-generated pull requests.
AI co-authored code already contains roughly 1.7 times more issues per change than human-only code, so large diffs hide more defects.
Merge conflicts multiply while the pull request sits open.
You lose the ability to revert one logical change without ripping out the rest.
A failing continuous integration run on a giant change blocks every other branch behind it.
You sacrifice the second pair of eyes guarantee that code review provides.
Human reviewers are the scarcest resource on your team.
Every oversized pull request drains the attention they can never get back.
How to Do It ️
Write a short spec before you prompt the agent.
Ask the AI to read the spec and propose a plan that splits the work into small reviewable pull requests.
Give the agent a concrete size cap, for example 100 lines per pull request.
Tell the agent each pull request must do one logical thing and stand on its own.
Review the plan first and reject any step that mixes refactoring with new behavior.
Let the agent open each pull request immediately so continuous integration starts running early.
Reference related past pull requests as context for the agent.
Reject any pull request that grows beyond the cap and ask the AI to split it again.
Benefits
Reviewable code: A human can finish reading the diff without losing focus.
Faster feedback: Smaller pull requests get reviewed in hours, not days.
Easier rollbacks: You revert one small commit instead of untangling a megachange.
Fewer merge conflicts: Short-lived branches rarely collide with main.
Earlier continuous integration signals: Each pull request triggers its own pipeline as soon as it opens.
Higher review quality: Reviewers stay engaged on small diffs and catch real defects.
Cheaper context: The agent loads a focused task instead of the whole codebase.
Context
Michael Bolin, the Tech Lead for the Codex CLI repo at OpenAI, recently described his workflow for building a permissions system.
The first thing he asked Codex was to create a plan and break the work into right-sized pull requests.
The initial output was about six pull requests.
He explicitly reminded the agent that a human still has to review the code.
A 2025 CodeRabbit study analyzed 470 open-source pull requests and found that AI co-authored pull requests contain roughly 1.7 times more issues per change than human-only pull requests.
Critical issues rose about 40 percent.
Major issues rose about 70 percent.
Big AI pull requests hide more defects per line than big human pull requests do.
Salesforce reported that AI-assisted coding pushed their average pull request past 1,000 lines and 20 files.
Review latency went up.
Worst of all, review time for the largest pull requests started to plateau, a clear signal that reviewers had stopped engaging.
Reviewer attention is finite and scarce.
Once it's depleted, no tool can restore it.
Small pull requests solve the math.
A SmartBear study of 2,500 pull requests found smaller PRs ship with fewer defects.
Teams that keep pull requests near 50 lines ship roughly 40 percent more code than teams who routinely exceed 200.
Small PRs are a form of functional slicing.
Each slice cuts vertically through the feature so it compiles, tests, and deploys on its own.
A spec-driven approach naturally produces sliceable work: the spec defines the boundary, and the AI splits the implementation into shippable increments.
Incrementalism and baby steps keep main green at every commit.
The AI doesn't practice incremental delivery by default.
Prompt Reference
Bad Prompt
Build the complete user authentication feature: login,
registration, password reset, email verification, OAuth
with Google and GitHub, session management, rate limiting,
and all the tests. Make it production-ready.
Good prompt
Here is the spec for the user authentication feature:
[spec content]
Before writing any code, read the spec and propose a
plan that splits the work into pull requests of at most
100 lines each.
Each pull request must do one logical thing and pass CI
on its own.
Keep refactoring and new behavior in separate PRs.
Show me the plan only. Don't write any code until I
approve the plan.
Considerations ⚠️
A 100-line cap is a guideline, not a law.
A trivial rename across 50 files can be longer and still trivial to review.
Never mix a refactor with a functional change in the same pull request.
A reviewer can't tell if a behavior change is intentional or a side effect of the refactor.
Keep structural changes and behavior changes in separate pull requests, even when the AI wants to bundle them, to avoid divergent change.
Some features have tight internal coupling and resist clean splits.
Be honest about that limit instead of forcing artificial splits that confuse reviewers.
Avoid long-lived feature branches.
A branch that lives for weeks drifts from main and accumulates merge conflicts.
When the feature isn't ready to ship but the code is ready to merge, use a feature toggle instead.
Each pull request merges to main behind the toggle and the feature activates when all pieces are in place.
Stacked pull requests work well when one change depends on another.
Each layer should compile and pass tests on its own.
If your team takes two days to review a small pull request, the workflow collapses.
Fix the review service level agreement before you push smaller pull requests on people.
Type
[X] Semi-Automatic
Limitations ⚠️
Some agents resist splitting and try to ship everything in one pull request even after you ask.
You may need to repeat the cap or paste it into your project skill file or AGENTS.md harness so the rule survives a fresh context.
Level
[X] Intermediate
https://coderlegion.com/9922/ai-coding-tip-003-force-read-only-planning
https://coderlegion.com/11538/ai-coding-tip-006-review-every-line-before-commit
https://coderlegion.com/13837/ai-coding-tip-013-use-progressive-disclosure
https://coderlegion.com/19374/ai-coding-tip-022-give-ai-a-harness-to-work-with
Conclusion
Your AI doesn't care how big the pull request is.
You do.
Human reviewers are the scarcest resource in your pipeline.
The AI can write code all day.
Reviewers can't review all day.
Set the size cap before the agent starts, and ask for the split plan first.
That single instruction protects the human who has to read the code.
https://newsletter.eng-leadership.com/p/how-openai-codex-tech-lead-does-ai
https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
https://engineering.salesforce.com/scaling-code-reviews-adapting-to-a-surge-in-ai-generated-code/
https://www.swarmia.com/blog/why-small-pull-requests-are-better/
https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
https://www.infoq.com/news/2026/04/github-stacked-prs/
Also Known As
- Right-Sized-AI-PRs
- AI-PR-Budgeting
- Reviewable-AI-Commits
- Pre-Coding-PR-Plan
- Codex CLI
- GitHub Stacked PRs (gh-stack)
- Graphite
- CodeRabbit
Disclaimer
The views expressed here are my own.
I am a human who writes as best as possible for other humans.
I use AI proofreading tools to improve some texts.
I welcome constructive criticism and dialogue.
I shape these insights through 30 years in the software industry, 25 years of teaching, and writing over 500 articles and a book.
This article is part of the AI Coding Tip series.
https://coderlegion.com/12469/ai-coding-tips