Merge Conflict Rates as a Software Factory Health Signal

Merge conflict rate has always carried information about the health of a software project, and that information has mostly gone unread. In the human era, large empirical studies of open-source projects found that nearly one in five merge attempts produced a conflict that needed manual intervention. It is a structural feature of how teams build software together, as predictable as the rhythm of a release cycle.

Build success rates dropped even as AI coding tools increased developer output because the agents producing that output work without any awareness of each other. Each agent reads the repository state in front of it, makes an independent architectural decision, and commits to it, meaning several agents can collide over the same files simultaneously. The AgenticFlict dataset found an overall agent conflict rate of 27.67%, already above the entire human-era range, and cross-agent conflict rate, different agents on the same repository, runs above two in five. Merge conflict rate is directly connected to build success because a pull request that cannot merge cleanly against whatever landed just ahead of it consumes a full CI run that produces nothing, and at cross-agent conflict rates of that magnitude, a meaningful share of CI capacity evaporates on runs that can never land. The bottleneck has moved: agents can now generate approved, test-passing pull requests faster than most merge strategies can absorb them, and conflict rate is the number that shows whether the gap between production speed and integration capacity is widening.

An empirical study of Java projects found that code touched by a merge conflict was twice as likely to carry a bug as code that merged cleanly. When a merge needed a developer to step in and resolve it by hand, the odds of a defect rose far past that already-elevated baseline. Conflicts, moreover, do not scatter randomly across a codebase. They cluster around files with high co-edit rates, large pull request churn, and infrequent integration. The pattern is regular enough that machine-learning classifiers built from simple Git metadata can separate safe merges from conflict-prone ones with real reliability.

None of this made conflict resolution feel like a factory-level measurement. Most engineering teams treated it as a personal cost, a tax an individual developer paid when two branches happened to collide, not a number worth tracking on a dashboard. The signal existed. It sat there, structurally embedded in every repository, waiting for a reason to matter more. Then the way code gets written changed.

AI coding agents pushed conflict rates into a new tier

AI coding agents have not nudged conflict rates up by a few points. They have put teams in a different tier of risk, well above anything the human-era numbers prepared anyone for. AgenticFlict, a dataset presented at AIware 2026 in Montréal, processed a large number of successfully simulated agent pull requests across tens of thousands of repositories and measured an overall conflict rate of 27.67%, already higher than the top end of the human-era range of roughly 10 to 20%.

An agent has no way to perceive the context cues a human developer picks up, such as a messaging thread about an upcoming refactor, a half-remembered conversation in a hallway, or a sense that a particular module is "someone else's" right now. An agent has none of that. It reads the repository state in front of it, reasons about the best way to solve its assigned task, and commits to an architectural decision independent of whatever else might be happening to the same code at the same time. Multiply that across several agents working the same codebase, and independent, confident, uncoordinated decisions converge on the same files.

Pull request size makes the effect worse. Small PRs, with a median churn of only a couple of lines, conflict at a rate near one in ten. Once churn climbs into the mid-range, conflict rates approach one in three and hold there. The location of those conflicts matters just as much as their frequency. More than four in five occur in source code files rather than dependency lockfiles. Agents are colliding over logic and architecture, not fighting over package-lock.json churn the way human-era intuition might suggest. The old assumption that conflicts are mostly noisy, low-stakes lockfile churn does not hold up in agentic pipelines. The agents are disagreeing about how the software should work.

Why cross-agent pairing is the dominant amplifier

The sharpest version of this problem appears when different agents, not the same agent working twice, operate on the same repository at the same time. Xu, Subramanian, and Karthik analyzed agent-authored pull requests across thousands of repositories and found that the large majority of all agent-generated PRs were competing with at least one other agent PR for the same merge target at the same moment. That overlap is now the normal condition of agentic development, not a rare scheduling accident.

The numbers separate cleanly along that line. Intra-agent conflict rate, meaning the same agent working on the same repository across different tasks, runs around one in five, consistent with the human-era baseline. Cross-agent conflict rate, different agents on the same repository, runs above two in five. The confidence intervals around those two figures do not overlap, which confirms the gap is a real structural difference and not sampling noise.

The root cause is architectural rather than a matter of carelessness. Two agents given related problems will often choose different solutions: one refactors a function in place, while another deletes that function and writes a replacement. The result is a modify/delete conflict, among the most expensive categories to resolve because it cannot be settled mechanically. It requires a human or a very capable resolver to make a judgment call about which direction was correct. Agents have no way to avoid this collision ahead of time. They cannot see each other's branches, cannot claim a file the way a human might flag it in a stand-up, and have no protocol for detecting that another agent is already headed in a different direction.

Some environments carry more of this exposure than others. Go repositories show the highest co-activity rates among agents, followed by Ruby and Python, which puts infrastructure-heavy codebases running several automated agents at once in the highest-risk category. High-throughput repositories also show far more co-activity than low-throughput ones, so as PR volume rises, conflict rate rises with it. The repositories under the most delivery pressure, the ones a team most wants to move fast, are exactly the ones accumulating the most coordination debt.

Call it that deliberately, because coordination debt is the right frame for what's happening. It is the accumulated cost of running multiple independent decision-makers against a shared codebase with no shared protocol for who owns what, and that debt compounds the same way technical debt does, quietly, until it interrupts something important. The strongest caveat applies here too: textual conflict rate is a lower-bound measure. Build conflicts and semantic conflicts that pass a clean textual merge go uncounted, so the real integration friction sits higher than any of these figures show. That undercount is itself informative. It means conflict rate catches coordination failure early, before semantic breakage has a chance to reach production, which is what makes it a leading indicator rather than something that only confirms damage after the fact.

Why does a rising conflict rate cause build success rates to fall even when agents are shipping more?

A sustained rise in conflict rate is a throughput story, and every additional point of elevation represents waste that compounds across the whole delivery pipeline: burned CI compute, inflated token budgets, and a merge queue that eventually sets the ceiling on how fast a team can ship.

Follow one pull request through the pipeline to see why. It passes its checks, enters the merge queue, and then fails because it can no longer merge cleanly against whatever landed just ahead of it. That PR has already consumed a full CI run for nothing. At the cross-agent conflict rates described above, you lose a meaningful share of CI capacity on cross-agent runs that can never land. Add in the automated resolution attempts, whether handled by the agent that wrote the original code or by a separate resolver agent, and token budgets absorb a second layer of cost on top of the wasted compute.

The merge queue itself becomes a useful diagnostic instrument once you start watching it this way. When time-in-queue drifts upward and a growing share of runs exceed whatever bound a team considers acceptable, conflict rate is very often the upstream cause rather than a coincidence running alongside it. Uber's SubmitQueue is a useful real-world anchor for what a disciplined response looks like: it uses speculative builds and machine-learning predictions of change success to sequence merges intelligently, and Uber's main branch reached a 99% success rate with meaningfully faster time-to-land as a result. That is what it looks like when a factory treats merge sequencing as an engineering problem instead of a queue to be endured.

The quality dimension still matters, even in a section about throughput, because the two are connected rather than separate concerns. Roughly three in five conflict resolutions involve semantic changes to the underlying abstract syntax tree, and code that comes out of those semantic conflicts carries sharply elevated bug risk. A factory tolerating a high conflict rate is injecting defects into the codebase at an elevated rate while it moves slowly. The bottleneck in agentic development has moved. Agents can now produce approved, test-passing pull requests faster than most merge strategies can absorb them, and conflict rate is the number that shows whether that gap between production speed and integration capacity is widening or holding steady.

Where conflict rate breaks down as a signal

Conflict rate has a real limitation, and the argument for watching it closely is stronger, not weaker, once that limitation is named directly. Conflict rate measures textual disagreement, the places where two sets of changes could not be mechanically reconciled. It cannot see disagreements that survive a clean merge and only turn into broken behavior downstream.

Picture the failure mode concretely. An agent finishes a task, the diff looks reasonable, tests pass, and the merge completes without incident. Three days later, a downstream service starts failing because it still expects a function shape that no longer exists. No merge-conflict metric captures that failure, because nothing conflicted at the text level. Xu, Subramanian, and Karthik are explicit that their textual conflict measurements are conservative lower-bound estimates, and they identify build conflicts and semantic conflicts as two further layers of integration friction their numbers do not capture.

The right response is not to discard conflict rate as a metric but to pair it with earlier and deeper detection. Running git merge-tree inside PostToolUse hooks catches conflicts during development, while an agent is still working, rather than waiting for the moment a pull request reaches the queue. That shifts discovery to the point where resolution is cheapest, before a second agent has built further work on top of the colliding change.

Transcript analysis supplies a second layer. Reading how an agent actually used its available tools during the work that produced a conflict tells you whether the collision was unavoidable, because two agents genuinely needed to touch the same function, or avoidable, because one agent invoked a capability it didn't need and touched a file it had no real reason to modify. That distinction matters operationally: unavoidable conflicts call for better task partitioning, while avoidable ones call for tighter scoping of what an agent is allowed to touch.

The VS Code team's practice of running offline benchmarks before shipping and then following up with production A/B tests and weekly reporting illustrates the same principle from a different angle. What a benchmark or a pre-merge evaluation shows and what accumulates in production over time are different observables, and neither one substitutes for the other. The same holds for conflict signal. Textual conflict rate measured at the PR boundary, transcript-level analysis of why agents collided, and production monitoring for semantic drift together cover more of the failure surface than any one of them alone.

Merge queue design: keeping conflict rate a signal, not a bottleneck

A merge queue sequences pull requests so each one merges against an up-to-date main branch, which is what prevents integration conflicts from compounding and keeps the main branch stable. At the PR volumes agentic pipelines now generate, that queue is what stands between a team and conflict-driven throughput collapse. GitHub's own monorepo offers a sense of scale: hundreds of engineers merge thousands of pull requests a month there, and the merge queue has processed tens of thousands of PRs across millions of CI executions.

The conventional approach, queue everything and run the full test suite at every position in line, is safe but expensive, and it gets more expensive as PR volume rises. Microsoft's APM project explored a two-tier alternative: a lightweight suite that runs on every PR push, paired with a heavier integration suite that runs only once, at merge time, rather than being repeated at every position in the queue. That split cuts redundant compute without giving up correctness.

A more contested idea pushes further. When a pull request's footprint does not intersect with whatever has recently landed, merging it directly to main without routing it through a queue lane sacrifices nothing in terms of correctness, while eliminating serialization latency that was never buying any real safety. That is the strongest operational argument against treating a merge queue as mandatory for every single change, agent-authored or otherwise.

Base Power Company ran a high volume of parallel-agent pull requests each week, and what happened there shows what happens when merge strategy can't keep pace with agent output. CI-passing pull requests arrived at record speed, then sat for hours or days before reaching production, because the merge strategy in place was never built for the volume of CI-passing PRs that agent-driven development can generate, and serialization became the bottleneck. The design raises which pull requests genuinely need serialization and which can be judged safe on footprint intersection alone, and conflict rate, broken down by PR type and by which agents are involved, is the instrument that answers that question with evidence instead of guesswork.

An agent-operated merge queue, one that handles conflict detection, triages CI failures, and reorders the queue on its own, escalating to a human only when a genuinely ambiguous architectural decision is at stake, changes the underlying economics of the whole system. Humans stop paying a small tax on every single conflict and start spending their judgment only where judgment is actually required.

Reading the conflict rate trend over time as a factory health dashboard

A single reading of conflict rate tells a team where its factory stands today. Tracked over time, broken out by agent and by PR type, and tied to the downstream metrics it predicts, that same number tells a team whether coordination debt is piling up or getting paid down. That trend line is the version of the signal worth building a practice around.

Connect conflict rate to merge queue throughput: time spent in queue, the share of CI runs that pass on the first attempt, the fraction of runs that exceed whatever time bound a team has set as acceptable. Put those together: a rising conflict rate starts predicting queue degradation before the queue's own metrics show any strain. That lead time is the entire value of treating conflict rate as a dashboard instrument rather than a number checked occasionally out of curiosity.

Most teams already have the infrastructure this practice requires. CI/CD is standard once a team is past the earliest stage of adoption, and GitOps principles are close to universal once a team is more advanced. The pipeline instrumentation needed to track conflict rate at the queue level, disaggregated and connected to the metrics it predicts, is already sitting in most environments that need it. What has been missing is the discipline to read conflict rate as a factory signal rather than a nuisance that developers are simply expected to absorb.