Running AI coding agents in parallel without them colliding

The first time you try this you open three terminals in the same folder, give each agent a job, and watch them destroy each other's work over the next ten minutes. Two agents editing one file system is not parallelism. It is a race with no referee.

Why one folder cannot hold two agents

An agent reads a file, decides what it should say, and writes it back. The gap between the read and the write is where everything goes wrong.

Agent A reads parser.ts. Agent B reads parser.ts. Agent A writes its version. Agent B writes its version, built from a copy that no longer reflects what is on disk, and A's change is gone. Neither agent did anything wrong and neither one can tell that anything happened.

It gets worse than lost edits. Agents run commands. Two of them running a build in the same directory produce one set of artifacts that neither one can trust. Two of them running tests read each other's half-written files and report failures that are not real. One of them checks out a branch and the other one's whole working tree changes underneath it mid-task.

You cannot fix this with coordination. Locks turn parallel work sequential, which is the thing you were trying to avoid.

One working copy per agent

The fix is not to make agents cooperate. It is to give each one somewhere that belongs to it alone.

Git has had the mechanism for this for years. A worktree is a second checkout of the same repository, on its own branch, in its own directory, sharing one object store. Create three of them and you have three real working copies of your project that cannot see each other's uncommitted state.

• Real, not a copy. It is the same repository. Branches, history and remotes are shared, so nothing has to be synced back afterwards.
• Cheap. No second clone, no duplicated object store.
• Isolated where it matters. Each worktree has its own index and its own working tree, so simultaneous edits and simultaneous builds do not touch.

Three agents, three worktrees, three branches. Now they can genuinely run at once.

Splitting the goal is the part that needs judgement

Isolation stops agents corrupting each other. It does not stop them doing the same job twice.

If you give three agents the same instruction they will produce three variations of one change on three branches, and you will spend longer choosing between them than doing it yourself. The work has to be divided before it goes out.

A good split has properties you can check:

• No two tasks name the same files.
• Each task is independently verifiable, so an agent can tell whether it finished.
• The tasks do not depend on each other's output, or the parallelism is fake and you have built a pipeline with extra steps.

Deciding the split is a judgement call about a codebase, which is exactly the kind of thing a model is good at and exactly the kind of thing that is not guaranteed. It is usually right. Design the process so that when it is wrong you find out at review rather than at merge.

Bringing it back

At the end you have three branches with three sets of changes. Three branches is not a result. It is homework.

What you want is one branch containing everything, including whatever an agent left uncommitted when it finished, with genuine conflicts reported as conflicts. The failure mode to design against is a merge that silently half applies something and looks clean.

You do the merging into your own project. The value is in getting from three separate piles of work to one reviewable branch, not in something deciding on your behalf that the work was good.

Doing this by hand

You can. It is:

1. 01A worktree per agent, created and cleaned up per run.
2. 02A split of the goal into non overlapping tasks.
3. 03A terminal per agent, and an account per terminal if you want more than one plan working.
4. 04Watching all of them.
5. 05Merging the branches back and dealing with the leftovers.

People do build this. The scripts work. What they usually do not survive is the fifth step, because output in five terminals is not something you can read, and the sixth, because the cleanup is fiddly and gets skipped until worktrees pile up.

Or not by hand

Nuvoa is that loop as a macOS app. Each pane is an account with its own sign-in, its own worktree and its own branch. You give one goal to the pane you put in charge, it splits the work across every account you have open, the panes run at the same time where you can see them, and everything comes back on one branch.

Your own copy of the project is never touched and nothing is pushed. What arrives is a branch, and the reading is still yours to do.

Join the waitlist if you are already running more than one of these.