Do I need Conductor, or are git worktrees enough?

If you're spawning 2-3 agents a few times a week, raw git worktrees plus a script alias are fine. If you're running 4+ agents daily and want each one in its own editor instance with shared MCP config, Conductor saves you 15 minutes of yak-shaving per session.

How many parallel agents is too many?

Your review bandwidth is the bottleneck, not your machine. Most devs hit diminishing returns at 3-4 concurrent agents — beyond that you're reviewing faster than you can think, and the value of agent-generated work goes to zero.

Won't parallel agents create merge conflicts?

Only if you route them poorly. The rule: each agent owns a directory, not a feature. If two agents touch the same file, you scheduled wrong. Conductor and similar tools enforce this with workspace isolation; raw worktrees rely on your judgment.

Does parallel coding actually save money or just time?

Both, usually. Four small focused contexts cost less in total tokens than one bloated 'do all four things' context, because each parallel context loads fewer files and finishes faster. The wall-clock win is the obvious benefit.

Running 4 Agents at Once Without Losing Your Mind

TL;DR

One agent per directory, not per feature. Physical isolation prevents 90% of collisions.
Sweet spot is 3–4 concurrent agents. Past that, you become the bottleneck.
Conductor for daily parallel work, raw worktrees for occasional.
Review in the diff, not in chat. A 4× parallelism gain is wasted if you re-read every transcript.

CH 01

The mental model.

Parallel AI coding feels like managing a team. It is, sort of. The agents are ICs who don't sleep, don't get bored, and don't ask why. You're the engineering manager whose job is task selection, code review, and unblocking. Get any of those three wrong and parallelism makes everything worse.

Three rules borrowed straight from how senior EMs actually work:

Surface area, not throughput. The agents finish faster than you can. The constraint is how many open diffs your brain can hold.
Independent work only. If task B depends on task A, you don't have parallelism — you have a serial flow with a fancy queue.
Same model per task type. Don't run 1 Opus, 2 Sonnet, 1 Codex. The review effort to context-switch between models is brutal.

CH 02

Setup: worktrees and Conductor.

Git worktrees give you N working copies of one repo, each on its own branch, sharing one .git directory. Each agent gets its own worktree. No collisions on the filesystem, no shared node_modules drama, no "wait who's editing this".

$ raw worktree setup (no extra tooling)

# From your main repo
git worktree add ../app-agent-1 -b feat/agent-1
git worktree add ../app-agent-2 -b feat/agent-2
git worktree add ../app-agent-3 -b feat/agent-3

# Each gets its own node_modules
cd ../app-agent-1 && pnpm install
cd ../app-agent-2 && pnpm install
cd ../app-agent-3 && pnpm install

# Open three Cursor windows, one per worktree
cursor ../app-agent-1
cursor ../app-agent-2
cursor ../app-agent-3

# When done
git worktree remove ../app-agent-1

That works. It's also tedious. Conductor exists to make this disposable. You click "new agent", it spins up a worktree, opens an editor instance pre-wired with the same MCP servers and skills, and gives you one dashboard for all of them. For daily use this saves real time.

You don't need both. Use raw worktrees if you spawn parallel agents occasionally; switch to Conductor when "occasionally" becomes "twice a day."

CH 03

Routing tasks without collisions.

Most "parallel agents fought" stories trace back to a routing failure. The fix is a routing rule, applied before spawning the agents.

Routing strategy	Works for	Collision risk
By directory	Monorepos, well-modularized code	Low
By route / page	Web apps with isolated routes	Low
By concern (UI / API / tests)	Cross-cutting work on the same feature	Medium
By "vibes"	Disasters	High

Before you spawn agent N, write down in plain English which files it owns. If you can't, don't spawn yet. Split the task differently.

CH 04

Reviewing N diffs efficiently.

Four agents finishing simultaneously gives you four diffs to read. If you read them like you'd read a colleague's PR, you'll be there until midnight. The trick is a different review shape:

Diff first, transcript second. Open the diff in your editor (or git diff main...feat/agent-1). Scan for shape: file count, size, structure. If it looks wrong, kill it before reading the transcript.
Read only the transcript's tool-call results, not the agent's narration. The narration is for the agent, not for you.
Run the tests once per branch. If they fail, send the agent back to fix; don't fix yourself unless it's faster.
Merge in a fixed order. Lowest-risk first (tests, docs, small UI tweaks). Save the structural one for last so you absorb its conflicts.

"I'll just clean it up myself"

The fastest way to lose all parallelism gains. If two of the four diffs need significant human cleanup, you spawned wrong — the tasks were too taste-heavy for autonomous agents. Roll those back into your own queue and adjust which work you delegate.

PITFALLS

Common pitfalls.

Parallel running tests

If three agents are running pnpm test in three worktrees, your CPU is on fire and tests start failing for "system" reasons. Either route test runs to one agent at a time, or use a shared test cache (vitest's --isolate=false with care).

Forgetting database state

Each worktree's app talks to the same dev database. If two agents are running migrations, you'll get conflicts the test runner can't explain. Use separate database URLs per worktree, or designate one worktree as "owns the DB."

Spawning when you should be planning

Sometimes the right move is one agent in Plan mode for 20 minutes, not four agents doing speculative work. Spawning is the answer when the work is well-defined; planning is the answer when it isn't.