How to Use Multiple AI Coding Agents on One Repo

Run multiple AI coding agents on one repository by giving each independent task its own branch and working directory, agreeing on boundaries before starting, and reviewing each result before integration. Start with two tasks you can verify separately. Add more only when you can keep up with review.

You can use the same agent twice or mix providers. The useful unit is a reviewable task, not a particular model lineup. This guide covers task selection, worktree setup, shared resources, review, and integration.

Choose Tasks That Can Finish Independently

Before opening another session, write down each task’s expected result, allowed files, prerequisites, and verification command. For example:

Task	Boundary	Completion check
Fix a navigation layout	Navigation component and its styles	Check the affected desktop and mobile layouts
Add regression tests for an existing parser	Parser tests; preserve the current API	Reproduce the bug, then pass the relevant tests
Correct installation instructions	Installation documentation	Run the documented setup steps

These can run together if they do not depend on one another. By contrast, changing an API while another agent writes documentation for its unfinished shape creates a dependency. Agree on the contract first or finish the API change before assigning the dependent work.

Give one task ownership of shared changes such as dependency updates, lockfiles, and database migrations. Separate worktrees prevent ordinary edits from mixing, but two branches can still make incompatible changes. The task-splitting guide shows how to find those boundaries.

Prefer sequential work when the next task depends on an unresolved design decision, several changes reshape the same module, a risky migration needs close supervision, or you cannot review another branch yet. Parallelism does not make an unclear task clearer.

Why Use Multiple Agents?

Independent work can overlap while you wait for an agent to finish. It can also be useful to ask a second agent to review a change, although its review still needs verification.

For concrete ways to combine providers, the guide to using Claude Code and Codex together compares independent tasks, planning handoffs, cross-review, and competing attempts.

For an idealized timing illustration, five independent ten-minute tasks take fifty minutes in sequence and ten minutes of execution if all five start together. That assumes enough compute and provider capacity, no dependency waits, and no retries. Setup, review, tests, and integration add time. This is arithmetic, not a measured speedup or a delivery guarantee.

Choose agents using results on your own representative tasks: correctness, instruction following, review effort, latency, and total cost. Provider prices and model capabilities change; there is no permanent rule that one provider should handle every refactor or every documentation edit. The agent comparison provides dated context, and the cost guide explains how repeated context and retries affect spend.

What Goes Wrong in a Shared Directory

Two sessions editing one checkout can overwrite files or build on each other’s unfinished work. They also share the index and checked-out branch: one agent’s staging or branch switch affects the other session. Package installs and generated output can change while another task is testing.

Separate working copies reduce these collisions. They do not resolve overlapping requirements or authorize an agent to access everything on your machine.

The Manual Approach: Git Worktrees

Start from a repository with a committed base. Inspect git status and choose the commit both tasks should start from. The following example uses local main; use your project’s actual integration branch, and check that it contains the intended starting point.

# Run from the original repository; use unused paths and branch names.
git worktree add -b task/nav ../repo-nav main
git worktree add -b task/parser-tests ../repo-parser-tests main
git worktree list

Start your chosen agent from each new directory in a separate terminal. Before assigning work, confirm its location and branch:

# Terminal for the navigation task
cd ../repo-nav
git rev-parse --show-toplevel
git branch --show-current
git status --short
# Start your installed, authenticated coding agent here.

Repeat the checks in ../repo-parser-tests for the other task. Give each session its task boundary, acceptance checks, and a rule to report unexpected shared changes before proceeding. New worktrees start from committed content; uncommitted edits are not copied into an agent worktree.

Git worktrees explained covers the underlying setup and lifecycle. For provider-specific choices, use the guides to multiple Codex agents, multiple Claude Code agents, or Gemini CLI worktrees.

Isolate Runtime Resources Too

Each worktree has its own working files and index, but repository objects, branch refs, and much configuration are shared. Worktrees are not security sandboxes: filesystem and command permissions still determine what an agent can access. See agent isolation and permissions and sandboxing before granting broader access.

Install dependencies per worktree when tasks may change packages. Symlinking a mutable node_modules directory can reintroduce interference. Provide each task with the environment files it needs, without copying production secrets into a test setup.

Assign distinct server ports and separate test databases. Check shared caches, containers, and external test accounts as well. More worktrees do not increase provider quotas; if requests queue or fail, reduce concurrency and handle rate limits.

A Small Reproducible Isolation Check

This example uses deterministic file edits in place of agents, so you can check the Git behavior without a model subscription. Run it in Bash on Linux or macOS with Git installed. It creates a disposable repository under a new temporary directory. The subshell stops if setup fails and leaves your original working directory unchanged.

(
set -eu
worktree_demo_dir=$(mktemp -d)
git init -b main "$worktree_demo_dir/repo"
cd "$worktree_demo_dir/repo"
git config user.name "Worktree Example"
git config user.email "worktree-example@example.invalid"
printf 'Original instructions\n' > README.md
git add README.md
git -c commit.gpgsign=false commit -m "Seed example"
git worktree add -b task/docs ../docs main
git worktree add -b task/styles ../styles main
printf 'Revised instructions\n' > ../docs/README.md
printf 'body { color: navy; }\n' > ../styles/style.css

git status --short
git -C ../docs diff -- README.md
git -C ../styles status --short
# Expected failure: docs still contains an uncommitted edit.
if git worktree remove ../docs; then
  printf 'Unexpected removal; stop and inspect the example.\n'
  exit 1
else
  # Recovery: review the diff above, then preserve it in a commit.
  git -C ../docs add README.md
  git -C ../docs -c commit.gpgsign=false commit -m "Revise instructions"
  git worktree remove ../docs
fi
git show task/docs:README.md
git worktree list
)

Expected results: the main checkout’s status is empty; the docs diff contains only the instructions change; the styles checkout reports ?? style.css. Removing the dirty docs worktree fails. After committing its change, removal succeeds, and git show still prints Revised instructions from the retained branch. The styles worktree and its untracked file remain for review.

Checked on 2026-10-11 with Git 2.43.0 and Bash 5.2.21 on Linux. This verifies isolation, dirty-worktree refusal, and preserving a branch through removal; it does not test AI output or measure performance. Example maintainer: Johannes Millan. Recheck when these commands change or a supported Git version changes their behavior.

Review Strategy for Multi-Agent Output

Limit concurrent tasks to the number of results you can review while their context is still fresh. If finished branches accumulate, stop dispatching new work and clear the review queue.

For every result:

Ask for the intended behavior, files changed, checks actually run, and unresolved concerns.
Inspect uncommitted and staged changes as well as branch commits. An agent’s completion message is not evidence that everything was committed or tested.
Read the diff and enough surrounding code to understand its effects. Check error paths, permissions, and interactions outside the edited lines.
Run the relevant tests or manual checks yourself. Use the AI code review guide for a fuller checklist.

For the navigation branch in the earlier setup, committed changes can be inspected from the original checkout with:

git log --oneline main..task/nav
git diff main...task/nav
git -C ../repo-nav status --short
git -C ../repo-nav diff
git -C ../repo-nav diff --cached

Review untracked files shown by status separately; ordinary git diff does not include them. If the solution is wrong, preserve any useful work and narrow or revise the task before retrying. Retries cost time and may incur provider charges.

Integrate in Dependency Order

Land a prerequisite before the branches that rely on it. For independent changes, start with a small result you can validate quickly. If a broad refactor overlaps other branches, decide the order before merging so you do not repeatedly resolve the same conflict.

Integrate one reviewed branch at a time using your repository’s normal pull-request or local integration process. Then update the remaining branch as needed and rerun relevant checks against the combined result. Passing tests on two isolated branches does not establish that they work together, and a conflict-free merge does not establish semantic compatibility.

The parallel-branch merging guide covers integration order and conflict handling; updating a worktree from main covers bringing the next branch up to date. Only clean up finished worktrees after accounting for local files and branch-only commits.

Where Parallel Code Fits

I built Parallel Code to bring this workflow into one desktop interface. It creates task branches and worktrees, shows live agent sessions together, and provides diff review and integration controls. The project README describes its setup behavior.

You still choose task boundaries, check shared resources, and decide which changes are ready. Whether you use separate terminals or Parallel Code, start with two independent tasks, review the results, and integrate them one at a time before increasing concurrency.