Running Multiple AI Coding Agents in Parallel
Running several coding agents at once sounds like a straight multiplier. It is not, until you solve isolation and task splitting. Here is the setup that works.
Running multiple AI coding agents in parallel is not a straight multiplier on your output, and the first attempt usually makes things worse. Two agents editing the same working directory will overwrite each other's changes within minutes, and you will spend longer untangling the result than either task would have taken alone. The fix is boring and mechanical: give each agent its own copy of the repository, split work so the copies do not overlap, and accept that review becomes the bottleneck.
The problem is shared state, not the models
An agent works by reading files, deciding on a change, and writing files. Two agents in the same directory are two processes doing read-modify-write cycles on the same data with no coordination at all. One agent reads a file, thinks for thirty seconds, and writes it back, silently discarding the edit the other agent made during those thirty seconds.
This is not a limitation anyone will fix with a better model. It is the oldest concurrency problem there is, and the solution is the same one it has always been, which is to stop sharing the mutable thing.
Isolation: one working copy per agent
Git worktrees are the cleanest mechanism, because they give you multiple working directories backed by a single repository and a single object store. Each agent gets a real directory to work in, on its own branch, with no duplicated history and no second clone to keep in sync.
# one worktree per agent, each on its own branch
git worktree add ../repo-agent-a -b feature/export-csv
git worktree add ../repo-agent-b -b fix/session-timeout
git worktree add ../repo-agent-c -b chore/dependency-bump
# when a branch is merged, remove its worktree
git worktree remove ../repo-agent-aPoint each agent at one of those directories and the overwrite problem disappears entirely. What remains is ordinary merge conflict resolution at the end, which is a problem you already know how to solve and which happens once rather than continuously.
Two practical caveats. Anything not tracked by git is still shared, so local environment files, build caches and databases need either duplication or a plan. And services that bind to a fixed port will collide, so each worktree needs its own port assignment if agents run the application while working.
Splitting work so the branches do not fight
Isolation prevents corruption. It does not prevent three agents writing three incompatible versions of the same helper function. The split has to be along real seams in the code.
Split by | Works well | Watch for |
|---|---|---|
Feature area | Different modules, different directories, different tests. The safest default. | A shared type or utility that all three need to change. |
Layer | One agent on the API, one on the interface, one on tests, against an agreed contract. | The contract drifting, which turns into three correct implementations that do not fit together. |
Task type | One writing a feature, one writing tests, one upgrading dependencies. | The dependency upgrade breaking the other two mid-flight. |
Same task, different approaches | Genuinely hard problems where you intend to throw two away. | Expensive, and only worth it when you cannot pick an approach up front. |
Write the interface between parallel tasks down before starting, in whatever form your project uses. The function signature, the endpoint shape, the table schema. Agents are good at implementing to a stated contract and unreliable at inventing the same contract independently, which is the same failure a team of people would have.
Review is the actual bottleneck
Three agents working for twenty minutes produce roughly three times the diff, and your reading speed has not changed. This is where parallel agent workflows fall apart in practice, because the constraint moves from generation to verification and most people do not notice until they are approving code they have not read.
Keep each parallel task small enough that its diff is reviewable in one sitting. If a task will produce a thousand-line change, run it alone.
Require tests as part of each task rather than as a follow-up, so review starts with evidence rather than with reading everything.
Review branches one at a time and merge before starting the next batch. A queue of five unreviewed branches is not progress.
Run the same checks you would on a human contribution. The failure modes in
get more likely, not less, when volume goes up.
Where background agents change the calculation
Agents that run detached from an interactive session make this pattern considerably more usable, because you are no longer babysitting three terminals at once. Meta's Muse Code, announced on 5 August 2026, shipped with background agents and a local event log as headline features, which is a reasonable signal about where this category is heading. An event log matters more than it sounds: reconstructing what three agents did over an hour is impossible from memory and straightforward from a record.
The version of this you can build today with any agent is a per-agent log file plus a per-agent branch. The branch tells you what changed and the log tells you why, and between them a review that would otherwise be archaeology becomes ordinary reading.
When not to bother
Parallel agents pay off on breadth: several independent, well-specified, small-to-medium tasks that touch different parts of a codebase. Dependency bumps, a batch of similar endpoints, test coverage across separate modules.
They pay off badly on depth. One hard problem does not go faster with three agents; it goes slower, because you now have three partial explorations to reconcile and no more understanding than you started with. If you are still deciding what to build, running one agent and thinking is faster than running three and choosing.
Cost is the other constraint worth naming. Three agents cost roughly three times as much per unit of wall-clock time, and agents left running on a vague task will happily spend tokens exploring. The controls in how to reduce AI API costs apply with more force here, and the same discipline that keeps a single agent focused, described in stopping AI from changing code you did not ask it to, is what keeps three of them from wandering.
Running several agents at once is a throughput problem. Keeping a single agent coherent inside one large codebase is a different one, covered in how to keep an AI coding agent from losing context.
FAQ
How many agents can I realistically run at once?
Two or three for most people, bounded by review capacity rather than by tooling or cost. If you cannot read the output of three agents as fast as they produce it, adding a fourth makes your queue longer, not your delivery faster.
Do I need git worktrees, or will separate clones work?
Separate clones work and are simpler to explain. Worktrees are preferable because they share one object store and one set of remotes, so you avoid duplicating history and keeping several clones in sync.
What happens when two agents change the same file?
On separate branches you get an ordinary merge conflict, which you resolve normally. In a shared directory you get silent data loss, with no conflict marker and no record of what was overwritten. That difference is the entire argument for isolation.
Can one agent review another agent's code?
It can be a useful first pass for finding obvious problems, and it is not a substitute for a human approving the merge. A reviewing agent shares the failure modes of the writing agent, so the things it misses tend to be the same things.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
