Running multiple coding agents in parallel
Technical · 8 min read · Updated 2026-09-20
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_breaks
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.
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.
## isolation
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 — 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.
## plan
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.
01Write 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.
02Name 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.
03Hand 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.
04Let 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.
## verification
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.
## worked_example
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. It is pre-release — v0.1 is being built in the open and the builds are not yet signed — so treat it as something to read and try, not something to put in front of a client tomorrow.
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.