How to run multiple coding agents in parallel without them fighting
Short answer: One coding agent in one terminal is easy to follow. Four at once is not, and the reason is rarely the models. It is that they share a checkout, they have no shared idea of what blocks what, and nothing chec
Short answer: One coding agent in one terminal is easy to follow. Four at once is not, and the reason is rarely the models. It is that they share a checkout, they have no shared idea of what blocks what, and nothing checks their claims before you read them. Fix those three and parallelism starts paying; skip them and you get four confident agents and one unusable diff.
What actually breaks when you add the second agent
The first agent is pleasant. The second one is where the workflow quietly stops being a workflow. Almost every failure falls into three buckets, and none of them are about model quality.
- They share a working tree: Two agents editing the same checkout will read each other's half-finished files, run tests against a tree somebody else is mid-edit in, and stage changes that are not theirs. The damage is not usually a dramatic conflict; it is a test run that passed for a reason nobody can reconstruct.
- Nothing knows what blocks what: A migration has to land before the endpoint that reads it. Told separately, two agents will cheerfully do both at once, and the second will write against a schema that does not exist yet, then explain convincingly why it works.
- The agent grades its own work: An agent reporting that it is done is a claim, not a result. Anyone who has read "all tests pass" above a red test run knows the gap. At one agent you catch it by reading. At four you do not read fast enough.
Isolation first. Of the three, the shared working tree is the one to fix first: the other two produce work you can still inspect, while a shared checkout produces a diff nobody can attribute.
Give every agent its own worktree
Git already ships the fix. git worktree add gives you a second working directory on its own branch, backed by the same repository and object store. It is not a clone, so there is no second copy of history to keep in sync and no remote round trip to create one.
One worktree per agent means an agent can only ever break its own branch. Its tests run against a tree only it is editing. Its dev server serves its own code. When it is done, what you review is a branch, which is a thing your existing review habits already work on.
The part people skip
Isolation has to cover the ports and the state as well as the files. Two agents both starting a dev server on 3000 is the same class of bug as two agents editing one file: the second one silently gets the first one's output.
Put the dependencies somewhere the agents can see
A list of tasks is not a plan. The useful structure is a graph: each job names what it depends on, and a job only becomes available when everything it depends on is genuinely finished. That single rule removes most of the coordination problem, because an idle agent can be handed the next ready job without anyone deciding whether it is safe.
- Write the work as jobs, not prose. One job is one unit of work for one agent, with enough context to start cold. If a job needs two agents, it is two jobs.
- Name the dependencies explicitly. Migration before endpoint; endpoint before the UI that calls it. The edges are the part you actually know and the agents do not.
- Hand out only what is ready. A job whose dependencies are unfinished should be unavailable, not merely discouraged in a prompt. Agents follow the structure you enforce, not the structure you describe.
- Let finishing unblock the next one. When a job is verified, everything waiting on it becomes available. This is where parallelism actually comes from: the graph widens on its own.
Have something other than the author check the work
The cheapest useful rule in multi-agent work: the agent that wrote the code does not get to decide whether it is done. A second, independent run (fresh context, read-only tools, ideally a different model) either reproduces the result or does not.
| Check | What it proves | What it misses |
|---|---|---|
| Run the tests | The suite passes in a clean tree the author was not editing | Nothing about whether the tests cover the change |
| Screenshot the page | It renders, and the console is clean at real viewport widths | Whether it renders the right thing |
| Independent reviewer run | A second model, given the diff and the evidence, agrees the job was done | Anything both models are wrong about in the same direction |
| Check the citations | Claimed sources exist and say what the agent says they say | Claims made with no source at all |
None of these is sufficient alone, which is the point: they fail in different directions. What matters more than the specific checks is that failure goes back to the agent with the evidence attached, and that there is a cap: after a few attempts, the job stops and a human is told, instead of an agent looping on the same wrong idea.
A worked example
We build this way, so we built the tool for it. Ninebrains is a free, open-source desktop app that runs Claude Code and OpenAI Codex agents side by side: every agent gets a lane with its own git worktree, terminal and browser, a central Brain holds the plan as a job graph and hands ready jobs to idle lanes, and verification gates run the tests, capture screenshots and spawn an independent reviewer before a job counts as done. A failed gate sends the feedback back to the lane with the evidence, three times, then blocks the job and tells you.
It runs the claude and codex CLIs you are already logged in to and never handles your credentials. It is Apache-2.0 and the source is public: ninebrains.runs-on.dev, and github.com/Advance-Labs/ninebrains. The latest release, v0.2.9, is out for macOS, Windows and Linux, but it is early and the builds are not yet code-signed, so treat it as something to read and try, not something to put in front of a client tomorrow. See Ninebrains
It is Apache-2.0 and every line of it is public, including the verification gates described above and the fake-agent harness the tests drive them with. Read the source on GitHub
You do not need our tool to do this
Worktrees, a written dependency graph and a rule that a second agent verifies the first will get you most of the way with the CLIs you already have. The tool is what happens when you get tired of doing it by hand.
FAQ
Can I run Claude Code and Codex at the same time on one repository?
Yes, as long as each one gets its own checkout. Both CLIs edit files in place, so two of them pointed at the same working tree will overwrite each other's edits and produce a diff neither of them intended. A git worktree per agent gives each a real branch and a real directory at almost no disk cost, and the merge happens once at the end where you can read it.
How do I stop two AI agents from overwriting each other's changes?
Isolation first, then ordering. Isolation means one working tree per agent so concurrent writes cannot collide. Ordering means writing the work down as jobs with explicit dependencies and only handing out a job whose dependencies are done, so an agent never starts against a half-built interface. Without the second part you get clean merges of work that was built on the wrong assumptions.
How many coding agents can I run in parallel?
The limit is rarely your machine. It is how many diffs you can actually read. Past roughly three or four concurrent agents, review becomes the bottleneck and the throughput you gained goes into catching mistakes. Raising that ceiling is what verification gates are for: another agent checks the work against a stated criterion before it reaches you.
Do I need a tool to run coding agents in parallel?
No. Worktrees, a dependency graph written by hand, and a rule that a second agent verifies the first will get you most of the way with the CLIs you already have. Ninebrains is the open-source version of that discipline made automatic. It is Apache-2.0, so if it is not what you want, the mechanics in this guide still are.
Originally published at advancelabs.dev, where the status table is kept current.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.