Watched someone’s coding-agent demo last month. Six “agents” working in parallel on the same codebase, supposedly. Three of them were stepping on the same files. One was waiting on the other’s edit to compile. Two were debating whose change to keep. The aggregate throughput was lower than one engineer running quietly.
What was missing was the cheapest piece of plumbing in git: git worktree add. A worktree gives each agent an independent checkout of the same repo on the same disk, sharing the object store, isolated in everything that matters. Nothing about the tooling around AI coding has caught up to this yet, even though the primitive is twenty years old.
What changes when each agent owns a tree
Three things, in order of how often they break a swarm:
- No file-level conflicts. Two agents can edit the same file in different trees and the merge happens at PR time, not at edit time.
- No build-state interference. One agent’s
cargo builddoesn’t poison another’starget/. Test runs don’t race. - No “did I save?” doubt. Each tree is a real branch. The agent’s work is a commit in its own history, not a guess at what’s currently on disk.
The merge step is the actual product
The reason most parallel coding setups underperform is not the agents. It’s that nobody built the merge. Three independent worktrees that all open three independent PRs and then sit there waiting for a human is not a swarm — it’s a backlog.
If you want parallel coding agents to be more than a demo, the missing piece is an automated merge agent. It reads the three PRs, identifies overlap, asks the model to resolve textual conflicts, runs the test suite, and either merges or hands you one synthesised PR with the open questions surfaced.
Until that exists, three agents in three worktrees are the same throughput as one agent that knows how to commit.