
One coding agent isn't slow because the model is slow — it's a queue with a single server. Four independent tasks sit WAITING behind one that's running. Nothing blocks them but scheduling. The bottleneck is a decision, not the model.

Everyone's first idea: point ten agents at one folder. It half-works for a few minutes. Then two agents open the same file and one write silently erases the other. Shared index, HEAD, and lockfile turn parallelism into a race — no clean error, just damaged work.

You cannot win a race by adding runners. Pointing more agents at one working tree just multiplies the collisions. The missing primitive isn't speed — it's isolation. And git already ships it: worktrees.

The conductor pattern gives one orchestrator exactly three jobs: split, dispatch, merge. Each is a judgement a worker can't make. Splitting the backlog into non-overlapping slices is where a swarm lives or dies — and if the conductor ever edits code, it becomes a hidden fourth worker.

Branch switching mutates one set of files, so agents serialize on it. Worktrees flip the model: many branches, many working directories, one shared object store. Same history, N desks — one clone's worth of objects, N places to actually work.

A worktree isolates four things — working tree, index, HEAD, checked-out branch — and silently shares the rest. Three agents set identity via shared git config; two hit lock errors yet all three commit. Result: the same wrong author on every commit — the exact field you'd use to audit. Never write shared config from a worker.

Setup is four commands: one worktree per task, no re-clone, no second copy of history. Three agents in three trees advanced three features in the wall-clock time one agent takes for one. Fan-out is trivial. The real work is the fan-in.

Linking a shared .venv or node_modules is what makes a swarm affordable. But run 'git worktree remove --force' and it can follow that link outward — deleting the target's contents while cheerfully exiting 0. Silent success, real data loss.

Fan-out is parallel; fan-in must be serial. Merge one branch at a time and every conflict points to exactly the branch that caused it. Use --no-ff so each agent keeps a merge commit and the graph still shows who did what. Two clean merges and one conflict is a healthy result.

You came with one agent and leave with a fleet. Isolation covers four things and withholds four — and now you know both. Parallelize only work that shares no write surface; let humans gate the split before and the merged result after. Isolation, disjoint splits, human gates: that's the whole game.