plottypusSign inStart free trial
Guides

What happens when two coding agents edit the same file?

by Lay Shethupdated 4 min read

Quick answer

In one working folder, the last write wins and the earlier edit is gone without a warning. In separate branches or worktrees, nothing is lost but you get a merge conflict later. A study of 33,596 pull requests written by agents found that work from two different agents conflicted 41.7% of the time, about twice the rate for two pull requests from the same agent.

Setup What happens How you find out
Same folder, same file Last write wins Often you don’t
Separate worktrees or branches Merge conflict At merge time
Different repos, shared API Both pass alone, break together In integration, or production

How often does it really happen?

More than I guessed. Two pieces of research put numbers on it.

The pull-request study. Xu, Subramanian and Karthik looked at 33,596 agent-written pull requests across 2,807 repositories, from December 2024 to July 2025. Daniel Vaughan wrote up the results. The ones that stuck with me:

  • 40.2% of repositories had agent pull requests open at the same moment.
  • Two pull requests from the same agent conflicted 19.8% of the time.
  • Two from different agents conflicted 41.7% of the time.
  • 84.4% of the conflicts touched source code, not config or docs.

The teamwork benchmark. CooperBench, from a Stanford group in January 2026, gave pairs of agents more than 600 tasks that needed cooperation. Pairs did about 30% worse than the same agents doing both tasks alone. The authors’ reasons were not about coding skill: agents communicated poorly, didn’t keep the commitments they made, and guessed wrong about what the other one was doing.

I read both the same way. The agents aren’t bad at the work. They’re bad at knowing about each other.

Why do different agents clash more?

The study doesn’t prove a cause, so this part is my guess. Two sessions of the same tool tend to share habits: the same instructions file, the same way of splitting a task, sometimes a shared task list. Two tools from two vendors share none of that. Add a second person, and they don’t even share a terminal.

What cuts it down?

Roughly in order of effort:

  1. Give each agent its own worktree. This turns silent loss into a visible conflict. It’s the floor, not the fix.

    bash
    git worktree add -b payments ../app-payments
git worktree add -b auth-refactor ../app-auth
git worktree list                 # see what's checked out where
git worktree remove ../app-auth   # after the branch lands

    Never point two agents at the same folder. There, the last write wins and you lose work with no warning.

  2. Split by files, not by features. Two agents on “checkout” and “refunds” will both open order.ts. Say which paths each one owns, in the instructions file.

  3. Merge one at a time. Land the first branch, rebase the second, then let its agent fix what moved.

  4. Check early. git merge-tree can tell you two branches will conflict before either is finished. With --write-tree, it exits 0 for a clean merge and 1 when there are conflicts, so it works in a script. Vaughan suggests running it from a hook after each edit.

    bash
    git merge-tree --write-tree payments auth-refactor > /dev/null \
  || echo "these two branches will conflict"

  5. Tell the other agent what you changed. This is the one the tools barely help with. Within one person’s Claude Code sessions it now exists: the docs describe cross-session messaging that lets “the sessions you run yourself pass findings to each other.” Across tools or across people, it’s still a human typing.

How many agents before it stops helping?

I don’t have a number, and I’d distrust anyone who gives one. Count overlapping files, not agents. What the two studies suggest is that the cost isn’t in the count. It’s in the overlap. Three agents on three separate areas are fine. Two agents that both need order.ts are already one too many. If you’re adding a fourth and the work touches the same files, you’re buying conflicts.

Is it different solo and on a team?

Yes, the problem moves.

Solo, with several agents. Your problem is keeping track. Name every session, keep one short handoff note per branch, and run the merge check before you merge, not after. You’re the only person who knows what each agent is doing, so anything that saves you a copy and paste is worth setting up.

A small team, one agent each. Your problem is the gap between people. Your agent has no idea what your teammate’s agent did an hour ago, and less if you use different tools or work in different time zones. That’s where the 41.7% figure lives: different agents, no shared habits. Today that gap gets closed by people typing to each other, so the file-ownership rule in the instructions file matters more here than anywhere.

Where plottypus fits

A merge conflict is one way a “done” stops holding after the agent stops. Each agent finished its task and reported success, and both reports were true, until the branches met. The same thing happens without a conflict: the tests passed, then another edit landed, and nobody reran them.

plottypus is a second agent that follows your Claude Code session while it works, checks every “done” against what actually ran (did the tests run after the last edit?), and sends the agent back when it won’t hold, while it can still fix it. How we test it, including what it misses, is on the evals page. For the single-agent version of this problem, see your coding agent said done, here’s how to check, and for using one agent to check another, should one coding agent review another’s work?. If two agents have collided in your repo, start a free trial.

Sources

plottypus is independent and not affiliated with any company or project named here. Claude Code is a trademark of Anthropic. Names belong to their owners. This is our research and opinion, dated above; details may have changed.