Git worktrees for parallel AI coding agents (2026 field log)

Quick Answer (July 2, 2026): Git worktrees let you run several AI coding agents at once, each in its own folder and its own branch off one shared repo, so they stop overwriting each other's files. Running three to five agents in parallel for two weeks, I shipped more, but the cost moved: file conflicts nearly vanished and logic conflicts plus review load went up. Worktrees earn their keep once you have more than two agents and a test suite acting as the gate. Here is the exact setup, my honest numbers, and when parallel agents are the wrong call.

I started the week with one agent and a bad habit.

The habit: kick off Claude Code on a task, wait, watch, tweak. One agent, one branch, one me. Fine for a morning. Useless when I have six small tickets and a weekend.

So I gave each agent its own desk. That desk is a git worktree.

What a git worktree actually is

A git worktree is a second (or third, or tenth) working directory attached to the same repository. One .git database, many checked-out folders, each on its own branch. Not a clone. No re-downloading history. They share objects on disk.

The command is boring:

# from inside your repo
git worktree add ../myapp-feature-auth feature-auth
git worktree add ../myapp-refactor-api refactor-api
git worktree list

Now I have two extra folders next to my repo. Each is a real checkout. I can open a different agent in each one and they never touch the same files.

That is the whole trick. Git has shipped this since 2015. AI agents just made it suddenly matter.

Why parallel AI agents need them

One agent editing your repo is calm. Two agents in the same folder is a knife fight.

They rename the same helper. They both edit package.json. One reverts the other's import while "cleaning up." I watched two agents fight over the same file for nine minutes before I killed both.

Worktrees fix the physical collision. Each agent gets an isolated folder and branch, so file-level conflicts basically stop. Cursor's background agents and Claude Code both lean on this pattern now, and it is why.

Here is the helper I actually use, because typing three worktree add lines gets old:

# wt.sh: spin up a worktree + branch in one go
wt() {
  local name="$1"
  git worktree add "../$(basename "$PWD")-$name" -b "agent/$name"
  echo "cd ../$(basename "$PWD")-$name"
}
# usage: wt fix-invoice-total

I keep an agent/ branch prefix so I can see at a glance which branches came from an agent and delete the whole lot later with one loop.

My setup: three agents, one repo

For two weeks I ran three agents by default, five on a good day, on a real Next.js side project (an expense splitter I keep rebuilding).

• Terminal 1: the trunk. My own edits, my reviews, the merge point.
• Terminals 2 to 4: one agent per worktree, one ticket each.
• A tiny supervisor: a shell loop that runs npm test in each worktree and refuses to merge a branch that is red.

That last part matters more than the worktrees. The test suite is the judge. Without it, parallel agents just generate conflicting confidence faster.

The honest numbers after two weeks

Read that last column honestly. I did roughly 2.3x the tickets. I also merged only 62% of them clean, down from 78%. And I spent about 3x on tokens.

Worktrees made me faster at generating work. They did nothing for the part that got slower: deciding what is safe to merge. That is the same wall I hit when I wrote about reviewing AI-generated code. Review is still the bottleneck; parallel agents just push more against it.

The failure mode nobody warns you about

Worktrees stop file conflicts. They do not stop logic conflicts.

Two agents, two folders, zero merge conflicts, and both quietly change how the same function behaves. Git sees no overlap. The tests pass in each worktree alone. They break when both land. One good write-up frames it well: worktrees parallelize branches, not agents, so the isolation is physical, not semantic.

The nastier one is the merge race. If your supervisor merges two green branches into main back to back without re-running tests on the combined tree, you can ship a conflict neither branch saw. I hit this once. The fix is dull: merge one at a time, re-run the full suite on main after each, never trust a branch that was green against an older main.

When parallel worktrees are the wrong tool

Here is where I disagree with the hype.

If you are starting a brand new app, three agents racing in three worktrees is the wrong shape. There is nothing to parallelize yet. You are just paying 3x tokens to generate three versions of scaffolding you then have to reconcile.

For greenfield, I reach for a one-shot builder instead of a swarm. Bolt.new will stand up a working prototype in a single pass. When I want that first pass to be a real, deployable codebase rather than a sandbox demo, I use Totalum, which generates a production Next.js app and, per its homepage (July 2026), hands you code that is "100% yours, no vendor lock-in." One deployable trunk beats three half-branches when there is no existing code to split across.

Parallel worktrees earn their place later: once the app exists, the tickets are independent, and you have tests to gate merges. That is the honest boundary. Swarm the maintenance; do not swarm the blank page.

The workflow that stuck

After two weeks I did not keep five agents. I kept two, sometimes three, plus the rules that make them safe:

1. One worktree per agent, agent/ branches.
2. A test suite as the merge gate. No green, no merge.
3. Merge serially, re-run tests on main after each.
4. Delete worktrees daily so the folder list stays honest.
5. Cap it at three. Beyond that, my review queue, not the agents, becomes the limit. I saw the same ceiling running Cursor background agents solo.

Worktrees are a real unlock. They are also a magnifier. They make a disciplined workflow faster and an undisciplined one messier, in exactly the same afternoon.

Still deleting more branches than I merge. Ask me in a month if that changed.