Git Worktrees + Parallel Agents: My Claude Code Setup

The first time I ran two coding agents in the same repository at the same time, they fought over the same files and I spent an hour untangling the result. The problem was not the agents. It was me, giving two workers one desk.

Git worktrees fixed it, and they ended up changing how I structure an entire workday.

The setup

A worktree is a second working directory attached to the same repository. Same Git history, different checked-out branch, different files on disk. One command:

git worktree add ../project-feature-a feature-a
git worktree add ../project-fix-b fix-b

Now I have three directories: the main repo and two worktrees, each on its own branch. I open a Claude Code session in each one. Each agent has its own isolated filesystem, its own branch, its own running dev server on its own port. They physically cannot conflict.

My actual layout on a typical day:

• Main repo: where I work manually, review, and merge.
• Worktree 1: an agent building a feature from a written spec.
• Worktree 2: an agent on a smaller task, a bug fix, a refactor, test coverage on a module I touched last week.

Two agents running is my comfortable maximum. I have tried three. The limiting factor is not compute, it is my attention. More on that below.

What actually changed in my workflow

The naive version of this story is "I write code three times faster now." That is not what happened.

What happened is that writing code stopped being the unit of work. The unit of work became the spec. Before launching an agent on a worktree, I write a short brief: the goal, the constraints, which files matter, what done looks like, what not to touch. Ten minutes of writing. The quality of that brief determines almost everything about the output, which means the skill that got sharper this year is not coding, it is specifying.

Then the day looks like this: launch agent one on the feature, launch agent two on the fix, do my own work in the main repo. Every 20 to 30 minutes, context-switch: check on an agent, answer its questions, redirect it if it drifted, review a chunk of diff while it is still small.

The honest downside: context-switching has a real cost. Three parallel streams of work means three mental models loaded at once. Some days it feels like being a tech lead for a team of very fast, very literal juniors. Productive, but tiring in a different way than deep work is tiring.

The review bottleneck

Here is the part nobody puts in their setup threads: when agents write most of the code, review becomes the bottleneck, and your review habits decide your code quality.

Rules I now follow, learned the hard way:

Review in chunks, not at the end. An agent that has been running unattended for an hour produces a diff too big to review honestly. I check in at logical milestones. If the diff is more than a few hundred lines, I stop the agent and review before letting it continue.

Never merge from the worktree. Everything goes back through a branch and a PR, even my own solo projects. The PR diff is where I actually read the code, away from the conversation that produced it. Reading code next to the chat that generated it makes you too generous. The agent's explanation primes you to see what it intended, not what it wrote.

Tests are non-negotiable. Not because agents write more bugs than I do (debatable), but because without tests I cannot tell whether a confident-looking diff is correct. The agent writes the tests too, but I review the tests with twice the attention I give the implementation. A wrong test that passes is worse than no test.

Keep a cleanup ritual. Worktrees accumulate. Run git worktree list every Friday, prune what is merged:

git worktree remove ../project-feature-a
git worktree prune

Where it shines, where it doesn't

Worth running in parallel: well-specified features, mechanical refactors, test backfills, migrations with a clear pattern, anything where the spec fits on one page.

Not worth it: exploratory work, architectural decisions, anything where I do not yet know what I want. Running an agent on a fuzzy problem just produces confident code for the wrong problem, in parallel. I keep that work in the main repo, with me driving.

What I would tell myself at the start

Worktrees are the easy part: one command, no magic. The real shift is organizational. You become a manager of parallel work, and the skills that matter are writing good briefs and reviewing diffs honestly. If your specs are vague and your reviews are rushed, parallel agents just help you produce bad code faster.

Start with two. Write the brief before you open the terminal. And review the tests harder than the code.