# how often AI coding agents cause merge conflicts.

how often AI coding agents cause merge conflicts depends on what is counted. AgenticFlict replayed 107,026 unmerged agent pull requests against their base branch; 27.67% hit textual conflicts. in one study, Xu, Subramanian and Karthik replayed one overlapping pair per repository: 19.8% of 601 same-agent pairs conflicted textually, and 41.7% of 115 cross-agent pairs; their follow-up claims no cross-vendor penalty.

a third study, *Passes Alone, Fails Together*, found that on tasks built to trigger it, 97% of runs (105 of 108) produced two changes that each passed alone and merged without a textual conflict, then failed together; its authors say that is not a real-world rate. a fourth, CooperBench, found that two agents given one feature each succeed less often than one agent given both. none of the four measured production breakage.

## the four studies side by side

| study | who and when | sample | what was measured | the number | the catch |
| --- | --- | --- | --- | --- | --- |
| [AgenticFlict](https://arxiv.org/abs/2604.03551) | Ogenrwot and Businge, UNLV; arXiv April 2026, AIware 2026 | 107,026 open or closed-unmerged agent pull requests that could be replayed | a textual conflict when each pull request is merged into its base branch | 27.67% (29,609) | unmerged only; the conflict can be with anyone’s change, human or agent |
| [Xu, Subramanian and Karthik](https://arxiv.org/abs/2607.04697) | Harvard Medical School, MIT CSAIL and DevRev; arXiv July 2026 | 33,596 agent pull requests in 2,807 repositories; 747 replayed pairs, 716 evaluable | pull requests open at the same time as another agent-written one, and a textual conflict between two of them | 79.4% overlapped; pairs conflicted 19.8% from the same agent (119 of 601), 41.7% from two agents (48 of 115) | cross-agent pairs were 0.50% of overlapping pairs, and the authors’ follow-up does not claim a cross-vendor penalty |
| [Passes Alone, Fails Together](https://arxiv.org/abs/2609.25396) | Xia, Wu and Park, UIUC and Columbia; arXiv September 2026, EXPRESS 2026 | 108 GPT-5.5 runs on constructed tasks over 12 Django helpers; 834 runs on 417 merged Django pull request pairs | tests that pass with each patch alone and fail with both, after a clean textual merge | 97% (105 of 108) on constructed tasks, and 82% (89 of 108) recovered with an oracle description of the other, finished change; 1 of 834 on real pairs | built to trigger it; the authors say the constructed rates don’t estimate real-world frequency |
| [CooperBench](https://arxiv.org/abs/2601.13295) | Khatua, Zhu, Yang and others, Stanford with SAP Labs US; arXiv January 2026 | 652 tasks from 12 libraries in Python, TypeScript, Go and Rust | task success when two agents build one feature each, against one agent building both | about 30% lower success together (the abstract’s figure) | a success rate, not a conflict rate; the features were chosen to overlap |

the figures are from the papers on arXiv, the coverage from Stanford HAI’s article, and what the page says about worktrees from git’s own docs, all checked on 2026-10-16.

## agenticflict: merge conflicts in unmerged AI agent pull requests

Daniel Ogenrwot and John Businge at the University of Nevada, Las Vegas built [AgenticFlict](https://arxiv.org/abs/2604.03551), accepted at AIware 2026. they started from the [AIDev dataset](https://arxiv.org/abs/2602.09185) of 932,791 pull requests by five agents and kept the 142,652 that were still open or had been closed without merging. another 35,626 couldn’t be replayed, because a commit was missing or the repository couldn’t be reached. the other 107,026 were merged locally into their base commit with `git merge --no-commit --no-ff`, and 29,609 of them conflicted: 27.67%.

for a closed pull request, the base is the branch as it stood when the pull request closed, so the replay approximates what its author would have met. the conflict is with the base branch, whoever changed it, a person or an agent.

the paper’s table breaks the rate down by agent:

| agent | replayed | conflicted | rate |
| --- | ---: | ---: | ---: |
| OpenAI Codex | 73,856 | 23,520 | 31.85% |
| Claude Code | 779 | 202 | 25.93% |
| Devin | 8,241 | 1,883 | 22.85% |
| Cursor | 7,196 | 1,421 | 19.75% |
| GitHub Copilot | 16,954 | 2,583 | 15.24% |

the paper’s prose gives slightly different per-agent rates (32.31% for Codex, 15.43% for Copilot); the table’s counts are the ones that add up to its totals of 107,026 and 29,609. the rates aren’t adjusted for repository, task or pull request size, and Codex alone is 69% of the replayed sample.

size shows the clearest pattern. with pull requests sorted into ten equal groups by lines added plus deleted, those with a median of 2 changed lines conflicted about 9.9% of the time, those with a median of 25 nearly 30%, and medium ones (a median of 46 to 185 lines) settled around 32% to 33%, then dipped slightly for the largest. since small pull requests conflict far less, an agent that opens larger ones would show a higher rate for that reason alone, and the paper doesn’t separate the two.

a conflicting pull request had conflicts in a median of 2 files (a mean of 4.36), with a mean of 11.36 conflict regions.

merged pull requests are left out by design. by the authors’ account, once a pull request merges, git keeps no record of a conflict someone resolved along the way, so a conflict fixed in review isn’t in the 27.67%. the counts are textual conflicts only; logical inconsistencies and post-merge defects are outside what the pipeline captures, by the authors’ own account. AIDev may overrepresent repositories that adopt AI tools, and there is no human baseline yet: comparing with human-written pull requests in the same repositories is the authors’ stated next step.

## xu, subramanian and karthik: how often overlapping agent pull requests conflict

George Xu (Harvard Medical School and Massachusetts General Hospital), Arjun Subramanian (MIT CSAIL) and Nithilan Karthik (DevRev) asked how often two agent pull requests open at the same time conflict with each other, in [AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates](https://arxiv.org/abs/2607.04697).

they used [AIDev’s curated subset](https://arxiv.org/abs/2602.09185) of 33,596 agent pull requests from 2,807 repositories with over 100 stars, opened between December 2024 and July 2025. OpenAI Codex wrote 21,799 of them, GitHub Copilot 4,970, Devin 4,827, Cursor 1,541 and Claude Code 459.

in this study, 79.4% of agent pull requests (26,691) were open at the same moment as another agent-written pull request in the same repository, and 40.2% of repositories had at least one such pair. allow a week either side and it is 95.0% of pull requests. nearly all of that overlap had the same tool on both sides. of 580,913 overlapping pairs, 2,896 (0.50%) came from two different agents, in 122 of the 2,807 repositories.

to measure conflicts, the authors replayed one overlapping pair per repository, so that a few busy repositories couldn’t dominate (the ten busiest held 91.4% of all pairs). that gave 625 same-agent pairs and all 122 cross-agent ones. each pair’s two heads were merged with `git merge-tree --write-tree` from their common ancestor, and 716 of the 747 pairs could be evaluated. pairs from the same agent conflicted 19.8% of the time (119 of 601), pairs from two different agents 41.7% (48 of 115).

the conflicts were mostly in code: 84.4% of the 1,646 conflicted files were source files, and 3.9% were dependency manifests or lockfiles. of the conflicts, 57.6% were two edits to the same region, 26.8% were modify/delete (one side edited a file the other deleted) and 15.1% were add/add (both created the same new file with different contents). the authors call their rates a conservative lower bound, since a build or logic conflict can only show up once the text merges.

### the cross-agent gap, rechecked

the 41.7% rests on 115 pairs, and the same authors have since weakened it. in a follow-up, [arXiv 2610.04779](https://arxiv.org/abs/2610.04779) (October 3, 2026), they compared both kinds of pair within the same 60 repositories: 28.3% (17 of 60) for same-agent pairs and 43.3% (26 of 60) for cross-agent pairs, with an exact McNemar p of 0.078. they write that they do not claim a cross-vendor penalty. treat the gap as early evidence.

the study groups pairs by tool and doesn’t report how many same-agent pairs were one developer’s parallel tasks and how many were teammates on the same tool.

## passes alone, fails together: clean merges that fail tests

Haocheng Xia and Yongjoo Park (University of Illinois Urbana-Champaign) and Eugene Wu (Columbia University) wrote [Passes Alone, Fails Together](https://arxiv.org/abs/2609.25396), a six-page paper accepted to the EXPRESS 2026 workshop. it counts two patches that each pass their tests and merge without a textual conflict, then fail together. a run counts as interference when a test passes with each patch alone and fails with both, on the same combined test suite.

on tasks built to trigger it, a scripted patch changed one of 12 real Django helpers: it removed the old name, added a required keyword-only argument, or changed what the helper returns. GPT-5.5, working from the base commit without seeing that change, wrote a new feature that called the helper. in 105 of 108 runs (97%) the two changes broke together, on all 12 helpers, after clean textual merges.

in the paper’s worked example the helper `phone2numeric` is renamed, the agent’s new function still calls the old name, and the merged code raises a `NameError`.

given a description of the other, finished change, generated from the scripted transformation, the agent recovered 89 of 108 runs (82%). the authors call this message an oracle, because it carries complete information that an agent working in parallel would usually lack.

on real, reviewed pull requests it almost never showed up. across 834 runs over 417 merged Django pull request pairs, with a GPT-5-class model driven through mini-swe-agent and OpenHands, one run showed interference once the grading was corrected. the authors suggest development and review may already have made those patches compatible, and say the constructed rates “do not estimate how often these problems occur in practice.”

two things are untested by the authors’ own account: recovery when the message is written while the other change is still in progress, and how a list of affected symbols compares with the completed edit at the same token budget.

## cooperbench: why AI coding agents fail at teamwork

[CooperBench: Why Coding Agents Cannot be Your Teammates Yet](https://arxiv.org/abs/2601.13295) comes from a team at Stanford and SAP Labs US, with Arpandeep Khatua and Hao Zhu as joint first authors. [Stanford HAI](https://hai.stanford.edu/news/ai-coding-agents-fail-at-teamwork) names Diyi Yang as senior author and reports it was presented at a workshop during ICLR in April.

its measure is task success. each of its 652 tasks, built from 12 libraries in Python, TypeScript, Go and Rust, gives two agents one feature each. the features are compatible but touch overlapping or interdependent code, and 77.3% of tasks have conflicting ground-truth solutions. the two patches are merged with `git merge-file`, a small model clears up trivial conflicts such as indentation style, and both features’ tests run on the result.

by the abstract’s figure, two agents working together had on average 30% lower success rates than one agent building both features. by raw success rates, GPT-5 and Claude Sonnet 4.5 agents reached 25% together, around half the one-agent rate. an appendix measure weighted by task difficulty, pooled across models, puts the loss at 41% of one-agent capability; on it, GPT-5 kept 64% and Claude Sonnet 4.5 60%. [Stanford HAI’s coverage](https://hai.stanford.edu/news/ai-coding-agents-fail-at-teamwork) (June 1, 2026) quotes Yang saying the best agents lose nearly half their capability when paired, which matches the raw success rates. in a smaller run on 46 tasks, success fell from 68.6% with two agents to 30.0% with four.

the paper also counted merge conflicts between the two patches. a messaging tool significantly cut them for Claude Sonnet 4.5, GPT-5, MiniMax M2 and the model the paper calls Qwen Instruct, while its effect on task success was not statistically significant. runs where an agent posted a plan in its first turn conflicted 29.4% of the time, against 51.5% for the rest.

the authors trace that split, fewer conflicts without more success, to two kinds of agreement. agreeing who edits which lines avoids merge conflicts; agreeing what each change does is what task success needs.

the benchmark pairs agents with no people involved, on tasks made to need cooperation. how often a team’s agents collide in day-to-day work is outside its scope.

## what the studies don’t measure

- **production breakage.** the two pull request studies count the conflicts git reports, and the two benchmarks run tests on tasks they constructed or replayed. none followed a merge into a running system, so a rate of agents breaking production is not measured.
- **a team of people, each with their own agents.** the pull request studies read public GitHub repositories, group work by tool and don’t report how much of it was one developer’s parallel tasks and how much was several teammates on one tool. the benchmarks have no people in the loop: CooperBench runs agents side by side, and in the constructed tasks of *Passes Alone, Fails Together* one change is scripted and an agent writes the other. Xu, Subramanian and Karthik note that proprietary codebases with stricter branching rules may differ.
- **a human baseline.** neither pull request study compares agent pull requests with human-written ones in the same repositories; AgenticFlict lists that as its next step. *Passes Alone, Fails Together* reports that the reviewed human patches of its 417 Django pairs merged without gold-test failures, a check on those pairs rather than a rate to set beside the agents’.
- **the cost.** CI compute, token spend and maintainer time appear only as hypotheses in Xu, Subramanian and Karthik. not measured.

## what a team can do with these numbers

each finding points at a different step; [how to prevent merge conflicts between AI agents](/guides/prevent-ai-agent-merge-conflicts) puts the steps in the order they act.

- **keep agent pull requests small.** among AgenticFlict’s unmerged pull requests, the conflict rate went from about 9.9% at a median of 2 changed lines to nearly 30% at 25.
- **give each of your own agents its own checkout.** when one developer runs several agents, a [git worktree](https://git-scm.com/docs/git-worktree) gives each one another working tree of the same repository on its own branch, so two agents on one machine stop writing the same files on disk. it doesn’t change what Xu, Subramanian and Karthik measured, a conflict between two branches at the merge; [git worktrees and agentmash](/vs/git-worktrees) says where each one stops.
- **test the combination.** a clean textual merge doesn’t show whether the combined code runs. *Passes Alone, Fails Together* counts only the failures that come after one, and on tasks built to trigger it found them in 97% of runs. build and test the merged result before it lands, in a merge queue or a CI run on the merged code. the guide to semantic merge conflicts, linked below, covers the clean merges that still break.
- **tell an agent before it edits.** in CooperBench, a plan in the first turn went with fewer conflicts, while the messaging tool did not significantly raise task success. in *Passes Alone, Fails Together*, on tasks built to trigger it, an oracle description of the other, finished change recovered 89 of 108 runs. agentmash’s advisory, below, carries less than that oracle, and how much it recovers is not measured.

agentmash works at this step for a team. before an edit, a developer’s agent is told when, in the last 30 minutes by default, a teammate’s agent changed the same file or, in JavaScript and TypeScript, an exported symbol the file depends on, on any branch and any machine. a symbol counts only when the teammate’s agent reported the names it changed, which Claude Code’s edits do and a Codex patch and Cursor’s edits don’t, or when a claim of theirs lists the names. a teammate’s branch that isn’t merged yet is remembered longer, by file, for up to a week, and [what counts as a conflict](/docs/conflicts) has the rules.

in Claude Code, Codex and GitHub Copilot the advisory is a note the agent reads. in Cursor (as login connects it) and the tools like it, it is a refused first edit, and the retry goes through; Cursor refuses once per conversation and file every ten minutes.

when alice’s Claude Code agent changed `createUser` in `src/models/user.ts` on a branch of her own, within the window, the check before bob’s agent edits `src/api/handlers.ts`, which imports it, raises `[AgentMash: PARALLEL EDIT]`. it says `Their version isn't in your working tree` and asks bob’s agent to write against the shape it can see and keep the change additive, so both sides survive the merge. in a checkout the two share, the same check raises `[AgentMash: ACTIVE COLLISION]` and asks bob’s agent to read `src/models/user.ts` before it finishes the edit, since `createUser` has moved; [semantic merge conflicts](/guides/semantic-merge-conflicts#what-agentmashs-symbol-overlap-covers) quotes one whole, from the docs’ two-terminal example.

the advisory carries who, when, which branch, up to 200 characters of the teammate’s prompt (none if they set `AGENTMASH_HINTS=0`), the line counts and the names touched. it doesn’t carry the change itself. the message in *Passes Alone, Fails Together* was a complete description of a finished change, and the paper’s 82% belongs to that message. how much an advisory like this one recovers is not measured, by that paper or by agentmash.

to try it on your own repository, [set up agentmash for your team](/setup), which has the steps for each agent. someone who can push connects the repository once, then each developer runs `npx agentmash login` once per machine and restarts their agent, since hooks load when a session starts. in Codex, they then approve agentmash’s hooks once in `/hooks`, since Codex runs no hook its user hasn’t approved; Antigravity also needs `npx agentmash tools add antigravity`.

## what agentmash doesn’t do

- it informs; it doesn’t lock. the edit goes ahead, in Cursor and the tools like it on the agent’s second try. `AGENTMASH_STRICT=1`, [strict mode](/docs/strict), is the setting that blocks.
- its notices never tell an agent to branch, commit, push or open a pull request, though a notice may suggest `git fetch origin` or a pull, to read a teammate’s side. the server can’t merge anything, so testing the merged result stays with your CI or merge queue.
- it doesn’t look back forever. a same-file or symbol match needs the teammate’s write inside the window, 30 minutes by default. past it, edits are remembered only for a teammate’s branch that isn’t merged yet, by file and never by symbol, said once a session, and a room’s admin can turn that off. a claim is separate: on the claimer’s own branch it stands until that branch merges, a week at most, and it can list symbols. after an advisory for a file, the next ten minutes are quiet about the teammates it named.
- it warns about teammates’ agents, never your own. two of your agents both report as you, so neither is warned about the other; when the overlapping work is all yours, keeping it apart is the worktree’s job.
- symbols are read from JavaScript and TypeScript only. files in other languages are matched by path, so a break across files in Python, Go or Rust goes unseen.
- not every coding agent hears the advisory before the edit. Cline hears it just after the edit, Antigravity at the start of each turn, and Continue and Zed only when they ask agentmash’s MCP tools; aider and plain editors are seen only when a commit lands, in a repository set up with `npx agentmash init` and `npx agentmash git-hook install` in each checkout. [the setup page](/setup) says how each agent hears it, Devin’s and Junie’s included.
- a check that runs past its budget, 1500 ms by default, lets the edit go ahead unwarned. [known limitations](/docs/limits) has the rest.