Run 5 AI Coding Agents at Once Without Breaking Anything

Get AI income methods before they spread.

Free weekly intelligence newsletter.

Running five AI coding agents simultaneously without file conflicts requires git worktrees to give each agent an isolated copy of the codebase. Cole Medin demonstrated this five-pillar system: worktrees for isolation, a fan-out pattern to spawn parallel agents from a single coordinator, fresh validation sessions so the agent cannot grade its own work, adversarial cross-review using Codex against Claude's output, and Neon database branching to prevent shared data corruption. The result is 5x implementation velocity with the same quality controls as a single-agent workflow.

Why do parallel AI coding agents fail without git worktrees?

When multiple Claude Code sessions run against the same working directory, they write to the same files simultaneously. One agent edits a component while another is mid-way through a refactor of the same file. The result is corrupted output, merge conflicts, and agents that cannot tell whether changes they see in the file were made by them or by another session.

Git worktrees solve this by giving each agent a separate local copy of the repository with its own working directory. The copies share the same git history but operate independently. Changes in one worktree have no effect on any other worktree until a deliberate merge step. Agents can run simultaneously without any awareness of each other.

How do you create a git worktree for a Claude Code agent?

The command is:

claude -w issue-10

This creates a new worktree named after the issue, opens a Claude Code session in that isolated directory, and lets the agent work on the task without affecting the main branch or any other active worktrees. The worktree is deleted after the agent's changes are reviewed and merged.

For parallel work on five issues simultaneously, the sequence is: create five worktrees with five separate claude -w commands, open each in a separate terminal window or VS Code instance, and let each agent run independently. There is no coordination required between the sessions at the implementation stage.

What is the fan-out pattern and how does it start parallel work correctly?

The fan-out pattern uses a single coordinator session to create all the work items before any implementation begins. The coordinator session reads the codebase, identifies the set of issues or features to implement, and writes each as a clearly scoped GitHub issue with acceptance criteria. Only after all issues exist does the coordinator fan out to parallel agents.

Without the fan-out step, parallel agents make overlapping decisions about scope. Two agents might both decide to refactor a shared utility while each is implementing a feature that uses it. The fan-out pattern eliminates scope overlap at the design stage rather than discovering conflicts during review.

The coordinator session does not implement anything. Its job is planning and scope definition only. This is the same principle as plan mode in Claude Code: a session that has done planning work should not also do implementation work in the same context window.

Why must validation use a fresh Claude Code session?

A Claude Code session that implemented a feature is compromised as a validator of that feature. The session has context showing the intent behind every decision and the reasoning used during implementation. It is structurally incapable of finding gaps between what was intended and what was built, because it cannot distinguish between the two.

The fresh session validator receives only the diff and a plain description of the user journey the feature should support. It has no access to the implementation conversation. This is the holdout pattern: the reviewer's only inputs are what a user would see plus what changed in the code. If the validator cannot reproduce the correct behavior from those two inputs alone, the implementation is incomplete.

End-to-end browser automation in the validation session strengthens this further. Rather than reading the code and reasoning about whether it should work, the validator runs real user journeys through the feature and observes the output directly.

How does adversarial cross-review with Codex work alongside Claude?

After Claude Code submits a pull request, run Codex as a reviewer of that PR. Codex and Claude have different training distributions and different blind spots. Issues that Claude's architecture makes it likely to miss are often caught by Codex, and vice versa.

The adversarial framing means Codex is explicitly instructed to find problems with Claude's implementation rather than confirm it is correct. A reviewer instructed to find issues catches more issues than a reviewer instructed to assess quality. The two-model review catches significantly more real bugs than either model reviewing its own work.

This step adds time but it is faster than a human reviewing five parallel PRs. The combined Claude implementation plus Codex review cycle is still faster than sequential single-agent development for the same feature set.

What is Neon database branching and when does it matter?

Neon is a serverless Postgres provider that supports database branching: creating an isolated copy of the database at a point in time, identical to how git branches work for code. Each worktree in the parallel agent system gets its own Neon database branch.

Without database branching, agents running integration tests share a database. One agent's test data pollutes another agent's test run. Race conditions in database writes cause tests to fail intermittently in ways that are hard to diagnose. Neon branches eliminate this entirely: each agent writes to its own data snapshot and test runs are fully isolated.

For projects without database dependencies, this step is not required. The worktree pattern alone handles file isolation. Database branching becomes necessary when agents are running integration tests that hit a real data layer.

What is the practical velocity improvement from this system?

The five-pillar system is not precisely 5x faster than a single agent on a single task. The velocity gain comes from eliminating the wait time between tasks. Instead of finishing issue 1, reviewing it, then starting issue 2, all five issues run simultaneously. The total clock time from fan-out to merged PRs shrinks to approximately the time required for the longest single issue, plus review overhead.

For an AI agency context, the implication is that a project requiring 5 implementation tasks that each take 30 minutes can complete in 30 minutes of elapsed time rather than 150 minutes. The billable scope stays the same. The delivery speed increases by the number of parallel agents.

Frequently asked questions

How many parallel worktrees can run at once before hitting system limits?

The practical limit is RAM and CPU on the local machine plus Claude Code rate limits on the API side. Three to five worktrees is the typical useful range. Beyond five, context management overhead and rate limiting reduce the marginal benefit of each additional agent.

Does this approach require Archon or does it work with Claude Code alone?

Git worktrees and the fan-out pattern work with Claude Code alone using the -w flag. Archon provides workflow orchestration that automates the fan-out step and manages the handoff between coordinator and implementation agents. The manual version without Archon works but requires more coordination between terminal windows.

What happens to a worktree if the agent session crashes mid-implementation?

The worktree persists after a session ends. The partial implementation remains in the isolated directory. A new Claude Code session can be opened in the same worktree with a brief context summary and continue from where the previous session stopped. No work is lost unless the worktree is explicitly deleted.

Is adversarial Codex review necessary for smaller projects?

For simple tasks, the fresh validation session alone is sufficient. The adversarial Codex review adds the most value for complex implementations where correctness is difficult to verify by inspection alone, such as authentication flows, payment processing, or anything with security implications.

Does Neon offer free database branching for small projects?

Neon has a free tier that includes database branching. The free tier supports a limited number of branches and compute hours per month. For development and testing on side projects, the free tier is typically sufficient to run the parallel worktree pattern.