Make AI coding agents open smaller pull requests

How do I make an AI coding agent open smaller, reviewable pull requests

Make the agent work in slices, not in open-ended tasks. Give it one goal, one branch, one reviewer-facing pull request, then stop it when that slice is done. GitHub’s own guidance says smaller pull requests are faster to review and easier to merge, and it also recommends splitting large changes into smaller pull requests that each serve one purpose.

The part people get wrong is asking for the full feature and hoping the agent will naturally self-limit. It usually does the opposite: it finds nearby cleanup, incidental refactors, and extra edits that make the diff harder to review. VS Code’s agent guidance notes that an AI agent can misunderstand the goal, repeat an unsuccessful action, or change more files than expected, so the job needs a hard boundary before the first edit starts.

Start by defining the slice in a way the agent can obey. Write the task as one user-visible change, one bug fix, or one internal refactor. Add the exact files or folders it may touch, and name the stop condition in plain language, such as “open a draft PR after the tests for this behavior pass.” GitHub supports draft pull requests specifically for work in progress, so you do not need to pretend unfinished work is review-ready.

A good prompt sounds like a checklist, not a brainstorming session. For example: “Fix the login error message in auth/, add one test for the new message, do not touch styling, do not refactor unrelated helpers, and open a draft pull request when done.” That kind of prompt narrows the blast radius. It also gives you a clean way to reject scope creep without debating whether the extra work was useful.

Use branch structure to enforce the cut line. Put each slice on its own branch, and if the work is still growing, create a stacked chain of dependent pull requests instead of one giant branch. GitHub documents stacked pull requests as a way to break large code changes into smaller, dependent pull requests that can be reviewed and merged independently.

Draft pull requests are the safest default for an agent. A draft PR lets the agent expose its work, trigger CI, and collect feedback without asking for final review too early. GitHub documents both the web flow and the gh pr create --draft flow, and it also allows you to convert an open pull request back to draft later if the scope is still moving.

Commit discipline matters more than most people expect. GitHub recommends small, meaningful commits, and that advice becomes more important with an agent because every commit is a checkpoint you can inspect. If the agent makes one correct change and one questionable change, you can split or revert the questionable part before the pull request becomes someone else’s review problem.

A practical rule is one commit per idea, one PR per reviewer decision. If the agent has to update tests, keep those tests tied to the same behavior change. If it has to adjust a helper, only do that when the helper is part of the same failure path. The moment the diff starts mixing product work, cleanup, and opportunistic refactoring, the review becomes harder and the pull request stops being small even if the file count looks modest.

Put a stop signal in the workflow. Tell the agent to pause after each meaningful milestone, then review the plan before it continues. VS Code’s agent recovery guidance describes resending a request to revert later changes from that request and following requests, which is useful when the agent runs past the intended slice. That is the inconvenient part: you need to interrupt the agent early, not after the diff is already messy.

Use tests as a boundary, not as an excuse to expand scope. Ask for the minimum test that proves the slice works. If the agent proposes extra “nice to have” coverage, treat that as a separate pull request unless the extra test is required for the same behavior. GitHub’s pull request guidance emphasizes that review is about the proposed change, so every additional behavior increases the review surface.

Review the plan before code appears. In the VS Code agent workflow, you can review the plan, then commit the intended changes and open the pull request. That is the right order when you care about size. Once the agent has written code, it is much harder to argue that a second idea belongs in the same pull request.

If the change is already too large, split by dependency, not by file count. One pull request can add the interface, the next can wire the implementation, and a third can clean up call sites. GitHub’s stacked pull request guidance exists for exactly this case, where each pull request depends on the previous one but still stays reviewable on its own.

When the agent goes wrong, do not keep negotiating with the diff. Revert the unrelated edits, restart from the smallest useful branch, and tighten the prompt before the next run. The failure mode is not usually that the agent cannot code, it is that the task gave it too much room to keep going after the first correct answer.

A simple operating pattern works well: plan, constrain, draft, review, then either merge or split. Put the agent on a branch with one narrow objective, ask for a draft pull request, and require a human to approve any expansion before the next slice starts. That keeps the pull request reviewable and stops the AI from turning one decision into five.

If you are building this into a team workflow, make the default path small by design. Use branch protection for required checks and review, then let the agent work inside that structure. GitHub documents branch protection rules for enforcing passing status checks and required review on protected branches, which supports the same goal: keep the merge gate strict so the agent cannot smuggle a large change through as a convenience.

For teams that want a concrete operating rule, this is the one to use: every agent run must end with either a draft pull request or a single reviewed commit, and any new idea becomes a new branch. That rule is boring, but it is what keeps AI output readable instead of turning review into archaeology.