Running multiple coding agents at once without merge hell

You can run several coding agents in parallel, but the ceiling is your review capacity, not compute. If you push more pull requests than you can review, the queue grows and velocity stalls. The real failure mode is not file-level conflicts but interface-level conflicts: two agents changing the same public API in incompatible ways, which no file isolation prevents.

Decide how many agents to run in parallel.

Start by estimating your review throughput. If you can comfortably review four pull requests a day, run at most four agents in parallel. Running five or six only increases the review backlog and delays feedback. Agents finish work faster than you can review it, so the bottleneck shifts from execution to review.

Your review capacity changes with project size and complexity. A small refactor with clear acceptance criteria may allow more parallel runs, while a large architectural change with many dependencies may halve your throughput. Measure your average review time per pull request over the last two weeks and divide it into your available hours to set the parallel limit.

Measure the right metric.

Track the number of pull requests in the needs review state at the end of each day. If the queue grows by more than one per day on average, reduce the number of parallel agents. If the queue shrinks or stays flat, you have room to increase the count.

Split work so pieces do not touch.

Agents work best when their tasks have no shared interfaces or data contracts. If two agents must touch the same module, assign one agent to refactor the public API first, then let the second agent build on the new contract. Never let two agents change the same interface at the same time.

Example: Splitting a feature across two agents.

Imagine a new payment flow with a PaymentService interface and a PaymentController. Split the work so one agent owns the PaymentService refactor and another owns the controller and frontend changes. The service agent changes the interface, the controller agent adapts to the new contract. If the interface change is large, the controller agent waits until the service agent’s pull request merges.

Example: Avoiding shared state in a data pipeline.

If two agents must process the same data, split the pipeline vertically. One agent transforms the raw data into an intermediate format, the second agent consumes the intermediate format. The intermediate contract becomes the boundary that prevents conflicts.

Use separate checkouts to reduce interference.

Each agent should run in its own git checkout. A shared checkout lets agents see each other’s uncommitted changes and creates merge conflicts when both try to commit. Separate checkouts keep the working state isolated until you intentionally bring changes together in a feature branch or pull request.

How to set up separate checkouts.

Clone the repository once, then create a branch for each agent. Use a naming scheme like agent-feature-a and agent-feature-b. Each agent works in its own branch, so their changes do not mix until you merge the branches later.

If you use a monorepo, the same rule applies. Each agent gets a separate working copy of the monorepo so they do not interfere with each other’s builds or tests.

Watch for interface conflicts before they break the build.

File isolation prevents file-level conflicts, but it does nothing for interface-level conflicts. Two agents can edit different files that both depend on the same public function. If one changes the function’s signature and the other does not update its call sites, the build breaks. You only discover this at review time, which costs much more to fix than catching it early.

Signs of an impending interface conflict.

How to prevent interface conflicts.

Before an agent starts editing, it should declare what it plans to change and what it depends on. If another agent has already claimed a dependency, the first agent either waits or chooses a different module. This is not a file-level check; it is a module and interface-level check.

Agents can also surface their assumptions and findings as they work. If an agent discovers that a planned change will break another agent’s code, it logs the finding so you can coordinate a fix before the build fails.

Bring changes together without merge pain.

When each agent finishes its task, bring their changes into a single branch or pull request. Use a merge strategy that keeps the history clean, such as a merge commit or squash merge. Avoid rebasing the combined branch, because rebasing can hide the fact that two agents touched the same interface.

Example: Merging two agents’ work into one feature branch.

Assume agent A changed the PaymentService interface and agent B updated the controller and frontend. Create a new branch feature/new-payment-flow and merge agent B’s changes first. Then merge agent A’s changes. The merge will succeed because the controller already adapts to the new interface. If the review finds interface conflicts, the failure is due to conflicts you should have caught earlier.

Use automated checks to catch interface drift.

Run API compatibility checks in your CI pipeline. If a pull request changes a public function signature without updating all call sites, fail the build immediately. This prevents interface conflicts from reaching review, where fixing them is costly.

You can also lint for exposed internal types or functions that should remain private. Automated checks enforce the boundaries you define and reduce the chance that two agents accidentally touch the same interface.

What to do when conflicts still happen.

If two agents produce incompatible changes, you have to choose one plan or reconcile them. The earlier you detect the conflict, the cheaper it is to fix. If you only learn about it at review time, you may need to rewrite one agent’s work or manually reconcile the changes.

Reconcile incompatible interface changes.

If both agents changed the same function signature, decide which change is correct. If the changes are both necessary, introduce a new function instead of modifying the existing one. Keep the old function as a wrapper that calls the new one, so existing call sites continue to work.

Revert one agent’s work if needed.

If the conflict is severe and reconciliation is risky, revert one agent’s pull request and let that agent redo the work against the merged state. This is a last resort, but it is better than merging broken code.

Running multiple coding agents at once speeds up execution, but it does not speed up review. Plan your splits around review capacity, isolate work at the interface level, and automate checks that catch drift before it breaks the build.