How to run multiple AI coding agents in parallel (without them stepping on each other)

One AI coding agent is a fast typist. Two or three, running at once, change how you work. You review one agent’s diff while a second is still thinking and a third opens a PR. You split a migration into four independent slices and hand each to its own agent. When you can’t decide between two approaches, you run both, compare the diffs, and keep the one that’s actually better. None of that works if the agents share a working tree, because the moment two processes edit the same files you get interleaved, half-applied changes and lost work.

So the real question isn’t whether to run agents in parallel. It’s how to give each one enough separation that they can’t corrupt each other, while keeping the whole fleet in view. Here is what people actually reach for, where each approach breaks, and the principles that hold up.

The DIY approaches, and exactly where they break

Multiple terminal tabs in one directory. The fastest thing to try: open three tabs, cd into the same repo in each, launch an agent per tab. It falls apart immediately. All three agents share one working tree and one .git. Agent A edits src/api.ts while agent B rewrites the same file from a different assumption; whoever writes last wins, and the loser’s changes are silently gone. Even when they touch different files, they trip over each other’s staged changes, branch checkouts, and half-finished edits. There is no isolation here at all. The shared checkout is the bug.

Copies of the repo with cp -r. The obvious fix is to give each agent its own directory: cp -r myrepo myrepo-agent-2. Now edits can’t collide. But a recursive copy duplicates everything, including node_modules, build artifacts, and the entire .git history, so on a large repo you wait, and you burn gigabytes per agent. Worse, a plain copy is a detached snapshot. You lose the connection to your branches and remotes, and you’re left hand-syncing changes back. It’s isolation bought at a price that scales the wrong way.

Git worktrees. This is the good instinct. A worktree gives each agent a separate working directory backed by one shared .git, so you get isolated files without copying history:

# one repo, three isolated working directories
git worktree add ../agent-auth   -b feat/auth
git worktree add ../agent-search -b feat/search
git worktree add ../agent-tests  -b chore/tests

# launch an agent in each
(cd ../agent-auth   && claude)
(cd ../agent-search && claude)
(cd ../agent-tests  && claude)

File edits can no longer collide, which solves the core problem. But two kinds of pain show up as you scale. The technical one: every worktree shares a single .git, so operations that touch shared git state still need care. The bigger one is human. After you’ve spawned five of these, you’re the process scheduler. Which agent is in which directory? Which branch was agent-search on again? Two agents both start a dev server on port 3000 and one silently fails. You alt-tab between terminals with no single place to see who’s working, who’s stuck, and who’s waiting on you. The mechanism works; the operations around it don’t. (A deeper worktree-vs-clone comparison is coming in a later post. Here the point is just that separate directories are necessary but not sufficient.)

The principles that actually matter

Strip away the tooling and three things determine whether parallel agents help or hurt.

Each agent needs its own checkout. This is non-negotiable. If two agents can write to the same file, collisions aren’t unlikely, they’re guaranteed the moment both are busy. Isolation has to be structural, not a convention you remember to follow. When every agent edits a different copy, divergence becomes an ordinary git problem (branches that merge at PR time) instead of a live filesystem hazard.

You need one place to see status and switch. Parallelism dies in overhead. If checking on four agents means four terminals and a mental map of which directory is which, you’ll stop spawning the fourth. You want a single view that tells you, at a glance, who is working, who is waiting for input, who finished, and who errored, plus a one-click jump into any of them.

Don’t parallelize past what you can review. Agents generate diffs faster than you can read them, and review is the real bottleneck. Ten agents you can’t keep up with is worse than three you can, because unreviewed code is a liability, not progress. Two concrete habits help. Scope each agent to a clearly separable task, so their diffs don’t overlap and you can review each in isolation. And when you’re genuinely unsure between two approaches, run both agents and compare finished diffs rather than debating in the abstract; a discarded attempt costs almost nothing, and reading two real diffs is faster than predicting which prompt was better.

How Fletch implements these principles

Fletch is a macOS app for running AI coding agents (Claude Code, Codex, Cursor Agent, OpenCode) in parallel, and it’s built directly on the three principles above.

Every agent gets its own disposable checkout. When you spawn an agent, Fletch gives it a private checkout of your repo under ~/.fletch/workspaces/<id>/, created with git clone --shared. Instead of copying history, it borrows your repo’s object store through git alternates, so spawning the tenth agent costs the same as the first: kilobytes and milliseconds, regardless of repo size. That sidesteps the cp -r tax while keeping full git history and branch tracking. The checkout starts from a pinned fork-point commit, and the agent gets its own writable .git; your repo’s real .git is never writable by an agent. Because every workspace is a different checkout, two agents can never edit the same file. The collision the terminal-tabs approach guarantees simply cannot arise.

A sidebar cockpit shows the whole fleet. Agents are grouped by project in a left sidebar, and each row carries live status: a name that shimmers while the agent works, cues for working, “waiting for your input,” “new results to review,” or error, a dev-server port chip when one is running, and a PR and diffstat sub-line. This is the single place to see status and switch that ad-hoc worktrees never give you. You spawn with a first task (⌘N), stop, archive, or discard from the same list, and the app icon badges how many agents finished while you were away.

Racing the same task is a first-class move. Because workspaces can’t collide and cost almost nothing, you can hand the same prompt to two or three agents, or the same task to different agents and models, then keep the winner and discard the rest. Discarding is just deleting a workspace directory. That turns “which approach is better” from an argument into an experiment.

The result is that parallelism stops being something you carefully manage and becomes the default way you work. You spend your time framing tasks, reviewing diffs, and deciding what ships, which is exactly where the principle about review being the bottleneck points you.

If you’re already juggling terminal tabs or a pile of worktrees, that’s the workflow Fletch is trying to replace.