--- title: "The Merge Tax: Why Adding Coding Agents Is Making Teams Slower · Cork" description: "Agent authored pull requests conflict at roughly double the human rate, and the worst failures are the ones version control reports as clean. A look at the coordination gap in agentic development." canonical: "https://corkcli.com/blog/the-merge-tax-why-adding-coding-agents-is-making-teams-slower" last_updated: "2026-09-18" published: "2026-09-18" author: "Kevin Vera" --- # The Merge Tax: Why Adding Coding Agents Is Making Teams Slower Agent authored pull requests conflict at roughly double the human rate, and the worst failures are the ones version control reports as clean. A look at the coordination gap in agentic development. By Kevin Vera · September 18, 2026 · [Engineering](https://corkcli.com/blog/c/engineering) · 4 min read Nine agents did a week of work in an afternoon, and the codebase went backwards. That is the part the demos leave out. Every agentic coding video ends at the diff. The interesting hour is the one after, when three finished branches meet one main branch and somebody has to decide which version of reality survives. ## Adoption is settled. Coordination is not. The adoption argument is over. Roughly 90% of professional developers now use AI coding agents at least weekly, and 68% use them daily. Capital has followed, and the agentic category is one of the strongest funding stories of the last two years. Almost all of that money went to generation: better models, better editors, better autocomplete over larger context windows. Nobody funded the merge. The numbers on what happens when agents write concurrently are worse than most teams assume. Research across more than 142,000 agent authored pull requests puts the conflict rate at 27.67%, against a 10 to 15% baseline for human authored PRs. A separate analysis of 33,596 agent PRs found that 79.4% of them overlapped in time with another agent PR aimed at the same merge target, with cross agent conflict rates near 41.7%, roughly double the rate seen when a single agent works alone. Put two agents on one cooperative task and measured success drops about 30% compared to either agent working solo. Read that last one again. Cooperation is currently a tax, not a multiplier. ## The dangerous conflict is the green one Red conflict markers are annoying and they are also fine. Git caught it, a human looks at it, the work continues. That failure mode is loud, and loud failures get fixed. The expensive failure is silent. Two agents edit different files on different lines. Version control reports a clean merge. The build compiles. The tests that exist still pass. And the semantics contradict each other, because one agent refactored an interface while the other kept writing against the old contract. Nothing in the standard toolchain catches that, and the reason is structural. Version control reasons about text. Agents reason about intent. A merge algorithm comparing line ranges has no way to know that a function signature moved underneath a caller it never looked at. Human teams paper over this gap with awareness: standups, code review, a Slack message saying do not touch the auth module today. Agents have none of that. They have a prompt and a working directory. ## Isolation defers the cost, it does not remove it The common advice right now is worktree isolation. Give every agent its own branch, its own checkout, its own sandbox, let them run wide. That advice is correct and incomplete. Isolation prevents agents from corrupting each other mid write. It does not prevent them from building on assumptions that went stale five minutes ago. Every isolated branch is a deferred merge, and resolving one of them invalidates assumptions in all the others. Two agents is manageable. Nine and they spend more time reconciling each other than producing anything, which is exactly the shape of the slowdown teams keep reporting but rarely measure. Sequential merging is the other common answer, and it works by simply moving the cost onto the human doing the landing. That is not a solution, it is a queue with a person at the front of it. ## Coordination is infrastructure, not discipline The pattern here is familiar to anyone who has built distributed systems. When several writers act on shared state without a protocol, you do not get speed. You get inventory: work that is finished but not landed, holding value that decays the moment anyone else commits. Distributed systems solved this a long time ago and the primitives are not exotic. Declare the write before making it. Carry the version you read so a write against a moved symbol gets rejected instead of silently landing. Detect staleness at the level of the symbol rather than the file, because file granularity is far too coarse when a single module holds forty functions. Keep enough shared memory that the second agent does not have to rediscover what the first one already learned. None of that is a modeling problem. It is a protocol problem, and protocol problems get solved once and then become invisible. ## Where this goes Two predictions, held with different confidence. The high confidence one: enterprise adoption of multi agent development stalls at two or three concurrent agents until coordination stops being a workflow tip and starts being infrastructure. Teams will keep hitting the ceiling, attributing it to model quality, and buying a better model that does not fix it. The lower confidence one, and the more interesting bet: the next durable category in developer tooling is not generation. Generation is already commoditizing, which is visible in the pricing pressure across every provider. The unsolved layer is arbitration, the shared write protocol that makes concurrent agents safe. It is a smaller surface than a code editor and a much stickier one, because whoever owns the protocol owns the workflow. The industry spent three years selling generation speed. It is about to spend three years paying integration cost. The 10x claims were measured at the diff, not at production, and the gap between those two numbers is where the next set of tools gets built. ## Related reading - [How to review pull requests from several AI agents at once](https://corkcli.com/blog/review-pull-requests-from-multiple-ai-agents): Review pull requests from several AI coding agents at once: triage with gh, review for cross-PR conflicts, use CODEOWNERS, AI review passes and a merge queue. - [Semantic merge conflicts: when the merge is clean but the code breaks](https://corkcli.com/blog/semantic-merge-conflicts): A semantic merge conflict is a clean git merge that breaks the program. Why git misses them, examples with AI agents, and how to catch and prevent them. - [Cork vs Graphite: coordinating agents before the PR, or reviewing after it](https://corkcli.com/blog/cork-vs-graphite): Cork vs Graphite: Graphite stacks, reviews and merges pull requests; Cork keeps parallel AI coding agents from colliding before a PR ever exists. - [How to run multiple Claude Code agents on one repo without conflicts](https://corkcli.com/blog/run-multiple-claude-code-agents-one-repo): Run several Claude Code agents on one repository safely: worktrees, subagents, agent teams, cross-session messaging, and a clean landing routine, step by step. [All articles](https://corkcli.com/blog.md) · [Cork in Markdown](https://corkcli.com/index.md) · [llms.txt](https://corkcli.com/llms.txt) This page in HTML: https://corkcli.com/blog/the-merge-tax-why-adding-coding-agents-is-making-teams-slower