Parallel Coding Agents: Fan-Out, Fan-In Without Clobbering

The daydream is intoxicating: point ten agents at your backlog, let them work in parallel, and collect ten finished features by lunch. Then you actually try it, and the codebase fights back — two agents edit the same file, a third builds on a function a fourth just renamed, and you spend the afternoon untangling a merge no human would ever have created. Running parallel coding agents is real and worth doing, but it obeys rules that parallel research doesn’t. Get those rules right and fan-out/fan-in is a genuine force multiplier. Get them wrong and you’ve built an expensive machine for generating conflicts.

This is a Create-pillar deep-dive in our agentic loops series. It assumes you already know the orchestrator-worker pattern in general; here we’re after the specific discipline of parallelism — when to fan out, how to isolate writers, and why the ceiling isn’t the model.

Parallel coding agents working in isolated worktrees that fan back in to a single merged branch

🧬 Why Coding Parallelizes Worse Than Research

Start with the uncomfortable truth, because it saves you from the most common mistake. Anthropic’s own writeup of their multi-agent research system is candid about two things: multi-agent runs burn roughly 15× the tokens of a single chat, and coding parallelizes far less cleanly than research. Research fans out beautifully — “investigate these eight companies” splits into eight independent read-only jobs that never touch each other. Code doesn’t. Code has tight write-write dependencies: change a function signature here and three call sites over there must change too, in a specific order.

So the first design question isn’t “how many agents can I run?” It’s “how much of this work is actually independent?” That number is usually smaller than it feels, and honesty about it is the whole skill. Parallelism you don’t actually have isn’t free — you pay the 15× token multiplier and the merge-untangling tax, for no wall-clock win.

🔀 The Fan-Out/Fan-In Shape

Fan-out/fan-in is one specific pattern in the orchestration toolkit, distinct from a serial pipeline. The orchestrator splits an independent set of tasks across workers that run concurrently, each in its own fresh context window, then merges their results back together. Two phases, two different kinds of risk:

Fan-out is a decomposition bet: you’re asserting these subtasks don’t depend on each other. If that bet is wrong, everything downstream corrupts.
Fan-in is a reconciliation problem: you have N finished pieces of work that must become one coherent change. This is where conflicts surface and where most of the real engineering lives.

One structural note that trips people up: the agents don’t coordinate with each other mid-flight. LLM agents aren’t yet good at real-time peer negotiation, so the orchestrator runs workers synchronously and reconciles between rounds — it’s a hub-and-spoke, not a group chat. The workers are isolated by design; the orchestrator is the only thing that sees the whole picture and merges it.

The fan-out/fan-in shape: an orchestrator splits independent tasks to concurrent workers, then merges the results

🌳 Git Worktrees: The Isolation Substrate

Here’s the mechanism that makes parallel writing safe. A git worktree lets you check out multiple branches of one repository into separate directories simultaneously, all sharing a single git history. Give each parallel agent its own worktree — its own directory, its own branch — and they physically cannot overwrite each other’s files, because they aren’t editing the same files. Their work only meets at the merge, where git’s normal conflict machinery (which humans already understand) takes over.

Without worktrees, “parallel writes” means concurrent agents editing the same working directory, silently clobbering each other into corrupted state. With worktrees, the filesystem itself becomes the durable shared state between an implementor and a reviewer, and fan-in becomes a series of branch merges rather than a prayer. Field reports converge on 4–8 concurrent worktrees per developer as the reliable range — not because the model can’t handle more, but because of what happens at fan-in.

Git worktrees give each parallel agent its own directory and branch on a shared history, preventing clobbering

🧭 What Actually Parallelizes (and What Must Serialize)

The judgment call — parallelize or serialize — comes down to a single test: do these tasks touch the same files? If no, fan out. If yes, serialize them into a pipeline.

Good fan-out candidates (genuinely independent):

The same mechanical change across many isolated units — “apply this new lint rule to all 12 packages,” where each package is its own directory.
Parallel read-only investigation — several researchers mapping different subsystems, returning condensed findings. This is the research-shaped part of coding, and it fans out cleanly.
Generating N candidate designs for the same problem, to compare and pick from.

Serialize instead when:

Tasks share files or have ordering dependencies (rename-then-update-callers is inherently sequential).
The change is small and well-understood — a serial research → implement → test → review pipeline is cheaper, more debuggable, and doesn’t pay the 15× tax for parallelism you don’t need.

The anti-pattern to name and avoid is over-decomposition: spawning subagents for work that isn’t independent. It multiplies cost and coordination overhead while delivering zero parallelism gain. When in doubt, serialize — it’s the cheaper mistake.

🚧 Review Is the Ceiling, Not Model Capacity

This is the counterintuitive part that reorganizes how you think about scaling. When people cap parallel agents at 4–8, it’s tempting to assume that’s a model or tooling limit. It isn’t. The bottleneck is review. Ten agents can produce ten diffs in parallel; one human can’t meaningfully review ten diffs in parallel. Fan-out scales the generation; fan-in — specifically the human judgment at the PR boundary — does not scale the same way.

Which means the real constraint on your parallel-agent throughput is your review capacity, and the highest-leverage investments are the ones that make review faster and safer: a reviewer agent doing a first pass, tight PR sizes, and tests that catch defects before a human ever opens the diff. Add agents past your review ceiling and you don’t go faster — you just grow a queue of unreviewed branches, which is inventory, not progress.

🛠️ A Practical Fan-Out/Fan-In Recipe

Putting it together into something you can actually run:

Decompose by file-independence, not by task count. Group work so no two parallel units touch the same files. If you can’t, that’s your signal to serialize.
One worktree per parallel worker. Isolated directory, own branch, shared history. This is the non-negotiable that makes parallel writes safe.
Bound the parallelism to your review capacity — start at 3–4, not 10. The limit is how many diffs you can actually reconcile, not how many the model can emit.
Give each worker a complete delegation contract. Nothing crosses the worktree boundary automatically: spell out the objective, the exact file paths, the acceptance criteria, and the branch to write to.
Reconcile deliberately at fan-in. Merge branches in a sensible order, run the full test suite on the integrated result, and treat conflicts as expected work, not surprises.
Keep the human at the PR gate. Fan-in ends at a reviewable pull request, not a direct push. That gate is the whole point of the isolation.

⚠️ Pitfalls

Parallelizing writes without isolation. The cardinal sin. No worktree, concurrent edits, corrupted state. Never fan out writers into a shared directory.
Assuming coding fans out like research. It doesn’t. Most implementation work has few truly parallel parts; only read-only or file-disjoint work fans out cleanly.
Context poisoning at fan-in. Dumping each worker’s full transcript back into the orchestrator defeats isolation and blows the token budget. Workers return condensed results — a diff plus rationale — not raw logs.
Unbounded fan-out. More agents than you can review isn’t throughput; it’s a backlog of unmerged branches masquerading as progress.

❓ Frequently Asked Questions

What’s the difference between fan-out/fan-in and the orchestrator-worker pattern? Orchestrator-worker is the general shape (a lead agent delegating to specialists). Fan-out/fan-in is the specific case where the delegated subtasks run concurrently because they’re independent — the parallel special case, with git worktrees as its enabling infrastructure.

How many parallel coding agents can I realistically run? Field reports cluster at 4–8 worktrees per developer, but the true limit is your review capacity, not the model’s. Start low (3–4) and only scale up as your review pipeline (reviewer agents, tests, small PRs) can keep pace.

Do I need git worktrees, or can agents just use branches? You need the physical directory isolation worktrees give you. Branches alone still share one working directory, so concurrent agents editing files still clobber each other. Worktrees give each agent its own checkout.

When should I just serialize instead? Whenever tasks share files or have ordering dependencies, or the change is small and well-understood. A serial pipeline is cheaper, more debuggable, and avoids paying the ~15× token multiplier for parallelism you don’t actually have.

📚 Further Reading

The Orchestrator-Worker Pattern for AI Coding Agents — the general delegation pattern this parallelizes.
The Agentic Development Loop, Explained for Engineers — the control-system foundation for the whole series.
Serena MCP: Give AI Coding Agents a Real Memory — keeping each parallel agent’s context cheap so the token math works.
Anthropic, How we built our multi-agent research system (June 2025) — the source for the 15× token cost and the “coding parallelizes poorly” caveat.

📚 Recommended Resources

Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.