Parallel Without Chaos: worktrees and the maker/checker split

The first time you run two agents on the same repository at once it looks like free throughput. It is not, and the reason is not subtle.

There is no clever prompting fix for this. Two processes editing the same file will always be two processes editing the same file. The fix is filesystem level, and Git has shipped it since 2015.

Worktrees: one repository, several checkouts

A worktree is an additional working directory attached to the same repository, on its own branch. Same history, same remotes, separate files. Made for exactly this.

# from the repo
git worktree add ../wt/fix-auth      -b fix-auth
git worktree add ../wt/fix-rounding  -b fix-rounding

# ... run an agent in each directory ...

git worktree list
git worktree remove ../wt/fix-auth

Claude Code can create and work inside an isolated worktree for you, and a subagent can be given one so its edits never touch the tree you are reading. The mechanic is worth understanding either way, because when something goes wrong you will be debugging Git, not the agent.

Two practical notes. Give a fresh worktree whatever it needs to actually run: dependencies, an env file, a database URL. A worktree that cannot run the checks is a worktree that cannot close its own loop, which puts you right back to reviewing prose. And clean them up, because a stale worktree is a checkout of an old branch that will confuse the next search you run.

Where parallel stops paying

The ceiling is not the tooling. Reports from teams running this in practice put the sustainable number somewhere around four to eight concurrent working trees per person, and the limit is not compute or context, it is that you become the bottleneck. Eight agents can produce eight branches an hour. You cannot review eight branches an hour, and unreviewed branches are not progress, they are inventory.

• Parallelise independent work. Three unrelated bugs in three areas: ideal.
• Do not parallelise a sequence. If B needs A’s refactor, running them together produces two conflicting refactors.
• Count your own capacity first. Start two. Add a third when two stopped feeling like enough, not before.

Keep the maker away from the checker

The second half of parallel work is not about speed, it is about honesty. An agent that has just spent forty turns building something is the worst possible reviewer of it: it knows what it meant, it remembers why each decision seemed reasonable, and it very much wants to be finished.

So give the review to a separate agent with a clean context, the diff, and the standards it should hold the diff to. It has no attachment to the approach and no memory of the dead ends, so it reads the change the way a colleague would: as an artefact, not as the end of a story.

---
name: reviewer
description: Reviews a diff against the project checks and conventions.
  Use before anything is merged. Reports findings, never edits.
tools: Read, Glob, Grep, Bash
---

You are reviewing a change you did not write. You have the diff and
the repository, and you do not have the reasoning behind it.

Report only what you can point at with a `file:line`. For each finding,
give the input that makes it fail. If the checks in CLAUDE.md were not
run, say so first and stop.

The tools line is doing real work there. A reviewer that cannot write cannot “helpfully” fix what it found, which keeps the review a review. Restricting a capability in configuration is a stronger guarantee than asking for restraint in a prompt, and it is the same instinct as the hook in the previous post.

This costs tokens, sometimes a lot of them. It buys the one thing an agent cannot give you on its own, which is a second opinion that has not already agreed with itself.