Running coding agents in parallel

One coding agent working through a backlog is fast. Several working at once are faster, until two of them edit the same file, share a database, apply each other's stashed changes or open more pull requests than anyone can review. Running agents in parallel is an isolation problem first and a review-capacity problem second.

This article covers how to isolate agents from each other, what git worktrees do and do not isolate, how to split the backlog so parallel work does not collide, and how to merge the results safely. Most of the failure modes below are ones we have hit running agents in parallel on Stride's own repository.

Start with one reliable loop

Parallelism multiplies whatever your single-agent loop produces, defects included. Before running several agents, get one to the point where its stories are well specified, its checks are real and its pull requests pass review without major rework. The articles on writing stories, test-first work and review cover that loop.

Then add agents one at a time, and watch the review queue rather than the agents. The limit is almost always the number of changes a person can review properly, not the number of sessions a machine can run.

Give each agent its own checkout

Agents sharing one working directory overwrite each other's files and break each other's builds. The standard fix is a git worktree per agent: a separate directory with its own branch and files, sharing one repository history.

Claude Code has this built in. Starting it with claude --worktree feature-auth creates a worktree under .claude/worktrees/feature-auth/ on a new branch and starts the session there. You can also create one yourself:

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

A new worktree is a fresh checkout: it has no installed dependencies and none of your git-ignored files, such as local environment files. Install dependencies in each one. Claude Code can copy listed git-ignored files into each new worktree through a .worktreeinclude file at the repository root.

What a worktree does not isolate

A worktree isolates files. It shares almost everything else with the main checkout, and the shared parts are where parallel agents collide.

• The repository's references. Branches, tags and the stash live in the shared repository. A branch can be checked out in only one worktree at a time, and the stash is a single stack across every worktree, so an agent that runs git stash pop can apply another agent's changes. Tell agents never to use a bare stash: commit work in progress to the branch instead, or stash with a unique message and apply that entry by its reference.
• Configuration and hooks. Repository configuration and git hooks apply to every worktree, so a hook that runs on commit runs for every agent.
• Links on disk. Some Windows setups share node_modules between worktrees through a directory junction. A recursive delete of the worktree can follow the junction and delete the shared folder. Remove the link itself first, then the worktree. Recent versions of Claude Code delete only the link when they clean up a worktree they created, but a manual rm -rf will not be so careful.

Give each agent its own runtime

Files are only part of the environment. Parallel agents also collide on:

• Ports. Two development servers cannot both listen on the same port. Give each worktree its own.
• Databases. Two agents running migrations or integration tests against one database corrupt each other's state. Give each agent its own database, and make any destructive test setup refuse to run against anything that is not a disposable test database: a suite that truncates tables truncates whatever the connection string points at.
• Caches and generated files. Build caches, code generators and lock files written from two places at once produce confusing, intermittent failures.
• Rate limits. Services usually limit requests per user or per key, not per session. We have tripped our own per-user limit by running several agent-driven browser checks at once under one login, and every page after that showed an error state that looked like a real bug. Give each agent its own credentials where the service allows it, with only the access its story needs.

Split the backlog so agents do not collide

The best isolation is work that does not overlap. When you choose stories to run in parallel:

• Prefer stories that touch different files. Git reports a conflict when two branches change adjacent lines, not only the same line, so two small edits next to each other in one file are enough to collide.
• Serialise work on shared registries. Migration sequences, translation catalogues, route tables, lock files and generated clients attract conflicts from every story. Let one agent at a time change them, or batch those changes.
• Claim a story before work starts, so that a second agent, or a person, does not pick it up. In Stride, the MCP call an agent uses to take its next staged story claims it atomically, so two agents asking at the same moment never receive the same one.

Merge one at a time

Parallel branches still land in sequence. Merge one, bring the next up to date with main, re-run its checks, then merge it. A merge with no textual conflicts can still be wrong: two changes that are each correct can combine into one that is not. Re-run the tests after every rebase rather than trusting a clean merge.

When a conflict does appear, resolve it with both stories' acceptance criteria in front of you. Whoever resolves it, person or agent, should know what each side was for, not only what each side changed.

Keep work in progress small

Agents make it easy to start work, and a WIP limit keeps the team finishing it. Cap the number of open agent pull requests at what your reviewers can clear in a day, and let the review queue, not the number of agents, set the pace.

Checklist for running agents in parallel

• One agent's loop is reliable before a second one starts.
• Each agent has its own worktree, dependencies and git-ignored files.
• No agent uses a bare git stash.
• Each agent has its own port, database and credentials.
• Stories running at the same time touch different files, and shared registries change one story at a time.
• Each story is claimed before work starts.
• Branches merge one at a time, with checks re-run after each rebase.
• Open agent pull requests never exceed what reviewers can clear in a day.