How to Stop Two AI Agents Editing the Same File

Quick answer
Two agents writing the same file at the same time do not merge — the later write wins and the earlier work is gone. Partition before you parallelise.
Give each agent its own git worktree and branch, so the filesystem itself separates them.
Assign ownership by file or module, not by task description, because task descriptions overlap and file paths do not.
Merge sequentially, one branch at a time, resolving conflicts between agent outputs as a normal review step.
Keep the shared surface small: shared interfaces, schemas, and configuration are where parallel agents collide most.

Why do two agents conflict?

Because they are two processes editing one filesystem with no coordination. Unlike two humans sharing a repository, an agent does not see another agent’s uncommitted changes and will not ask before overwriting. If both are asked to improve the same area, the second to write removes the first’s edits without noticing. Git does not help here, because the loss happens before either change is committed.

The overlap is often subtler than ‘the same file’. Two agents working on different features may both need to add a route to the same router file, extend the same schema, or update the same configuration. The instructions differed but the file did not, and the file is what the conflict is about.

Step 1 — give each agent a worktree and a branch

A git worktree is a separate working directory attached to the same repository, with its own checked-out branch and its own index. Two agents working in two worktrees are editing different files on disk even when they are editing the same paths in the repository, so nothing is destroyed in the moment. When each finishes, its changes exist as an ordinary branch that can be merged and reviewed.

This is the single change that makes parallel agents safe, and it costs one command. Create one worktree per agent, keep them out of the main checkout, and clean them up when the branch is merged. The sandboxing guide uses the same primitive for a different reason: confining each agent’s blast radius.

# One worktree + branch per agent, created from the same base commit.
git worktree add ../agent-a -b agent/a-auth
git worktree add ../agent/b -b agent/b-billing

# Agent A runs in ../agent-a, Agent B in ../agent/b. They never share a file.

# When a branch is done, review and merge one at a time.
git switch main
git merge --no-ff agent/a-auth
git merge --no-ff agent/b-billing   # resolve conflicts here, deliberately

# Clean up.
git worktree remove ../agent-a
git branch -d agent/a-auth

Step 2 — assign ownership by path, not by task

Worktrees stop destructive overwrites but do not stop merges from colliding. Reduce the chance of collision by giving each agent an exclusive area: one owns the authentication module, another owns the billing routes, and neither edits the others’ files. Ownership expressed as paths is checkable, which is what makes it different from ownership expressed as a task description.

The seams to watch are the shared files. A router, a schema definition, a dependency manifest, and a configuration file are all common to many features, so parallel agents will each want to touch them. Decide up front who owns each shared file, or handle the shared edits yourself after both branches are in. One person adding two routes to a router takes a minute; two agents colliding in it can produce a broken file that neither of them reported.

Step 3 — merge one at a time and review the seams

Merge sequentially and treat each merge as a review point. The first branch merges cleanly; the second may conflict in exactly the shared files you predicted. Resolve those conflicts deliberately, by looking at both intents, rather than by taking one side. Conflicts between two agents are usually not textual — each change is individually sensible — and the resolution is a judgement about which combination is correct.

Then verify the combination, not the branches. Run the test suite on the merged result, since the interesting failures are integration failures: both agents added a migration that assumes a different ordering, both registered a handler for the same event, or both created a database column with the same name. A test run after the second merge catches what neither branch’s own suite could.

Step 4 — keep the shared surface small

Parallelism is bounded by how much the work shares. If two features both require touching the same schema, the same configuration, and the same base component, the honest conclusion is that they are one unit of work and should be done in sequence. Splitting them across agents buys you nothing and costs you a merge conflict.

Where the work genuinely does not overlap — different modules with a stable interface between them — parallel agents are a real speed-up. The precondition is a clear interface that both can rely on and neither needs to change. Establishing that interface first, even as a stub, is what turns overlapping work into independent work. Journey: Run Two Coding Agents Without Losing Work is that process start to finish, including the merge and the verification.

Where this bites vibecoders
The usual setup is two terminal windows on the same checkout, which is the one configuration guaranteed to lose work. It looks fine because each agent reports success — the agent whose edits were overwritten has no way to know. Setting up worktrees before starting the second agent is a five-minute habit, and the alternative is discovering the loss during review, after both agents have built on top of the missing change.

Where AI coding assistants get this wrong

Running multiple agents in the same working directory on the same branch.
Assigning tasks by description and assuming the file overlap will work itself out.
Letting both agents edit shared route, schema, or configuration files.
Merging both branches at once instead of one at a time.
Resolving a conflict by taking one agent’s side without reading both intents.
Testing each branch separately and not the merged result.

Checklist

Create a worktree and branch per agent before starting either.
Assign every file an owner, and list the shared files explicitly.
Establish interfaces between parallel work as stubs first.
Merge one branch at a time and review each conflict.
Run the full test suite on the merged result.
Remove the worktrees and branches once merged.

FAQ

Can two AI agents work on the same repository at once?

Yes, if each has its own worktree and branch so they never share files on disk. The conflicts then arrive as ordinary merge conflicts, which you resolve deliberately, instead of as silent overwrites. Running both in the same checkout is the configuration that destroys work, because the second writer wins and neither agent reports a problem.

What is a git worktree and why does it help?

A worktree is an additional working directory attached to the same repository, with its own branch checked out. Each agent gets its own directory, so their edits never touch the same files on disk. Creating one is a single command, and it is the cheapest way to make parallel agent work safe.

How do I split work between agents?

By file or module ownership, not by feature description, because different features frequently need the same files. Give each agent an exclusive set of paths, and handle shared files such as routes, schemas, and configuration yourself, or assign them to one agent. If two tasks both require extensive changes to the same files, run them sequentially instead.

What should I do when the merge conflicts?

Read both sides and decide what the combined behaviour should be, rather than choosing one agent’s version wholesale. Conflicts between agents are usually both-intents-valid situations in shared files. Then run the tests on the merged result, because the failures that matter — duplicate registrations, conflicting migrations — only appear once both changes are present.