Running Five Coding Agents on One Repo, No Collisions

Running one coding agent at a time is slow. You wait for it to finish a change, review it, then start the next thing. Running several agents on the same repo at once is faster, but only if they are not all editing the same working copy, because two agents writing to identical files at the same time is not parallelism, it is a race condition with your codebase as the prize.

Where the parallel habit actually came from

This is not a workflow I invented in the abstract. One of the real project templates I have shipped and registered is infinite-loop-modern, built directly on IndyDevDan's Infinite Agentic Loop and modernized for the current version of Claude Code. The description I wrote for that repo says exactly what it does: parallel agent waves, spec-driven generation. That is a repo sitting in my own registry, not a hypothetical pattern I am describing after the fact.

Parallel agent waves only work in practice if each agent in the wave has somewhere isolated to work. That is the job a git worktree does. One repo, one set of git history, but multiple working directories checked out against different branches, so five agents can each be mid-edit on their own copy of the code without stepping on each other's uncommitted changes. When a wave finishes, you merge the branches that earned it and throw away the ones that did not.

This is not a one-off pattern

I know it is a real, recurring workflow because I mine my own Claude Code and Codex sessions for exactly this kind of signal. One mined record from an actual working session carries the tag set claude-code, agent-view, goal-command, multi-agent, subagents, skills, agentic-coding, workflow-templates. Those tags did not get invented for a blog post, they came out of a real chat file from a real build session, run through a mining pipeline built specifically to surface what workflow topics actually came up, not what topics I think should come up.

Multi-agent and subagents showing up together in a real, tagged session is the evidence that this is not a technique I use once and write up as if it were routine. It is routine, and the tagging system exists precisely so I can point at that and not just assert it.

The routing rule that keeps it from turning into chaos

Parallel agents without a trigger and a rule set is just noise generation. I run a standing, versioned routing config, injected into every Codex and Claude session, that defines things like the autonomous build-loop workflow triggered by a phrase like "ralph this." That block is not a one-time note I wrote and forgot. It shows up byte for byte across independently dated real session records, which tells me it is an active rule the fleet is actually following, not a stale doc nobody rereads.

The reason that matters for worktrees specifically is that parallel work only stays manageable if there is a consistent trigger for when to fan agents out and a consistent place for their output to land. Without that, you end up with five worktrees, no idea which one was for what, and a merge process that takes longer than doing the work sequentially would have.

What actually makes this worth the setup

The payoff is not that parallel agents are five times faster in some clean theoretical sense. It is that the waiting time disappears. Instead of one agent finishing a task before the next one starts, I get a wave of attempts landing roughly together, each in its own worktree, each committable or discardable on its own. I pick the branch that did the job well, merge it, and the rest get deleted without ever having touched the branch I actually cared about.

If you are setting this up yourself, do not start with the tooling. Start with the trigger. Decide what phrase or event kicks off a wave, decide how many agents go into it, and only then wire up the worktrees to give each one a clean, isolated place to work. The isolation is what makes parallel safe. The routing rule is what makes it repeatable instead of a one-time trick.