The challenge of merge conflicts at agent scale.

Executive summary

The version control market is experiencing a structural disruption. Git, the incumbent with 94 percent market share, was designed in 2005 for human developers editing text files. Two decades later, AI agents generate 41 to 46 percent of all new code, and one in four AI-generated pull requests produces merge conflicts that Git's line-level architecture cannot resolve without human intervention.

This assessment evaluates whether next-generation version control systems, specifically Atomic VCS, represent a credible market opportunity or a niche technical curiosity. Findings are based on primary research including direct codebase inspection of 233,000 lines of Rust across 6,423 automated tests, peer-reviewed academic datasets, regulatory landscape analysis, and architectural evaluation against Git's data model.

The conclusion is straightforward. The market opportunity is real. The technology is sound. Git has a structural inability, not merely a feature gap, to address the two problems that matter most in AI-native development: provenance integrity and fine-grained merge resolution.

Key findings

• One in four AI-generated pull requests hits a merge conflict in Git (27.67%, n = 107,026 PRs). That rate will increase as AI-generated code volume grows.
• Git's core workflow operations (squash merge, rebase, cherry-pick) systematically destroy provenance metadata. This is not a feature gap. It is a data model incompatibility. Git's identity model ties commit SHA to parent hash. Any operation that changes the parent produces a new identity, orphaning any provenance attached to the original.
• Workarounds exist but are fragile by design. Diff-hash-indexed sidecars, git-notes standards, and replace refs can approximate provenance preservation, but all require explicit opt-in configuration, external tooling, and platform-level enforcement. None are default, automatic, or tamper-evident.
• Atomic VCS provides provenance integrity structurally. Its architecture separates immutable changes, content-addressed and Blake3-hashed, from mutable views, which are perspectives on which changes are active. No operation in Atomic can orphan provenance because no operation rewrites change identity.
• Token-level merge reduces Git's conflict surface by an estimated 36 percent. Microsoft's MergeBERT study across 220,000 real-world conflicts found that token-level diff3 auto-resolves 36.1 percent of line-level conflicts without any AI model, purely through finer granularity.
• No enacted regulation currently mandates AI code provenance. However, the trajectory is clear. The EU AI Act (August 2026), evolving FDA software validation requirements, and emerging DoD AI contractor frameworks point toward mandatory attribution within 18 to 36 months.

Market context: the structural shift

The scale of AI code generation

The shift from AI-assisted development to AI-generated development occurred between 2024 and 2025. It was not a gradual trend. It was a phase transition. The toolchain infrastructure built for human-authored code is now carrying a fundamentally different workload.

Git's merge architecture as a scaling bottleneck

The AgenticFlict study (arXiv:2604.03551, April 2026) provides the first large-scale empirical measurement of merge conflicts in AI-generated contributions. The dataset covers 107,026 pull requests across 59,412 repositories.

The data reveals a compounding negative dynamic. As AI generates more concurrent changes, merge conflicts increase. Longer integration cycles produce longer-lived branches. Longer-lived branches produce more conflicts. Git's line-level three-way merge cannot break this cycle because it reports a conflict whenever two branches modify the same line, regardless of whether the actual edits overlap at the character or token level.

Git's absence of AI awareness

Git's data model stores commits as snapshots of a file tree. A commit records author name, author email, timestamp, parent hash, tree hash, and message. There is no field for AI model or provider identity, token usage or inference cost, session provenance or decision chain, confidence score or verification status, or delegation scope or authorization.

The Co-authored-by: Copilot convention is prose in a free-text message field. It is not structured data, not queryable, not cryptographically signed, and not preserved through standard Git workflows. It is a naming convention, not a provenance system.

The provenance integrity problem

Git's core workflow operations (squash merge, rebase, and cherry-pick) systematically orphan any provenance metadata attached to commits. This is not a feature gap. It is a data model incompatibility: Git's commit identity includes the parent hash, so any operation that rewrites history produces new commit SHAs and silently severs any external provenance indexed to the originals.

Proposed solutions (new ref types, git-notes standards, and diff-hash sidecars) address the durability of the provenance record but not the integrity of the audit trail. As long as Git permits history rewriting by default, a provenance system built on top of it cannot guarantee that its records accurately describe the canonical history an auditor will inspect.

A new ref type solves durability. It does not solve integrity. An audit trail that might be accurate is not an audit trail.

Atomic eliminates this problem structurally by separating change identity from change ordering. Changes are content-addressed and parent-independent. No workflow operation in Atomic rewrites change identity, which means no workflow operation can orphan provenance. The full technical and architectural case for this distinction is documented in Atomic Code Intelligence: The Evolution of Version Control for the Age of Agents.

The merge granularity gap

Quantifying the conflict surface

Git's merge algorithm operates at line granularity. If two branches modify the same line, Git reports a conflict regardless of whether the actual edits overlap at the character or token level. Atomic's hierarchical CRDT operates at token granularity.

Git:    Line-level
        "same line modified" → CONFLICT

Atomic: Token-level
        "same token modified"          → CONFLICT
        "different tokens on same line" → AUTO-MERGE

Estimated conflict reduction

The most rigorous available proxy is Microsoft's MergeBERT study (FSE 2022, Svyatkovskiy et al.), which applied token-level diff3 to 220,000 real-world merge conflicts.

The Brindescu et al. (2019) conflict taxonomy, covering 6,979 conflicts across 143 Java projects, provides a complementary framework for understanding where finer granularity provides structural advantage.

The estimated reduction for Atomic's token-level CRDT is consistent with the MergeBERT finding at approximately 36 percent. The unique contribution beyond what formatting tools already handle, the disjoint category, accounts for approximately 14.5 percent of conflicts.

Implications at enterprise scale

Applied to the AgenticFlict baseline, the productivity impact is material.

For an enterprise running 100,000 AI-generated PRs per year, this represents approximately 10,000 merge conflicts that would require human attention under Git but resolve automatically under Atomic. At an estimated 30 to 60 minutes per conflict resolution, the productivity impact is 5,000 to 10,000 developer-hours annually.

Technology maturity assessment

Architecture and implementation

Atomic is implemented in Rust and built on production-grade infrastructure. The codebase comprises 233,000 lines of Rust across 454 source files with 6,423 automated test functions. The change format is at V3, indicating multiple design iterations. This is not a research prototype.

Current capability gaps

An honest assessment requires acknowledging the gaps that enterprise adoption will require closing.

The absence of AI-mediated conflict resolution is a deliberate design choice, not a gap. Atomic minimizes conflicts algorithmically through finer granularity rather than resolving them with an LLM.

Regulatory landscape

Current state

No enacted regulation in any jurisdiction currently mandates AI code provenance or attribution in source code. The regulatory environment is one of trajectory, not immediate mandate.

The 18–36 month horizon

The regulatory trajectory is consistent across multiple jurisdictions and frameworks. The EU AI Act's framework is designed for iteration. As AI-generated code becomes the majority of new software, the assistive editing carve-out faces increasing pressure. The FDA already requires detailed development documentation for software in medical devices. The DoD NDAA FY2026 AI framework is actively defining requirements for AI tools used by defense contractors.

Organizations that invest in provenance infrastructure now will be positioned to meet these requirements as they materialize. Organizations that defer will face retrofit costs against a Git history that has already squashed away the records they will need.

Competitive dynamics

The limits of GitHub's incremental approach

GitHub has taken initial steps toward AI provenance. The Copilot Coding Agent (March 2026) embeds an Agent-Logs-Url: trailer in commits and marks every Copilot-authored commit with Co-authored-by: Copilot. These are meaningful first steps with four structural limitations:

• Coverage is partial. Only GitHub's own agent is tracked. Claude Code, Cursor, Devin, OpenCode, and any agent running in CI are invisible.
• Durability is not guaranteed. Trailers are commit-message text. They survive squash only if GitHub's UI explicitly preserves them, a platform decision, not an architectural guarantee.
• Depth is shallow. No model version, no token counts, no cost metadata, no decision chain. Session logs are stored on GitHub's servers, making them platform-locked and non-portable.
• Portability is absent. Moving a repository from GitHub to GitLab severs the Agent-Logs-Url link entirely.

Atomic's structural position

Atomic does not face this tension because it does not rewrite history. Changes are immutable. Views provide the clean history experience, showing only what is relevant to current work, without destroying the underlying change records. This is a consequence of the data model, not a feature built on top of it.

The competitive moat is not that Atomic can do things Git cannot. The moat is that Atomic does these things automatically, by default, with zero configuration, and with cryptographic guarantees, while Git requires opt-in tooling, platform enforcement, and careful maintenance to approximate the same outcome.

Strategic recommendations

For technology investors

The market opportunity is real and growing. AI-generated code is not a trend. It is the new default. Atomic is the most advanced implementation in this space: 233,000 lines of Rust with 6,423 tests, a working AI agent integration, cryptographic attestation, a semantic knowledge graph built on RDF triple patterns, and a principled CRDT-based merge engine.

The primary risk is execution, not technology. The architecture is sound. What remains is building a hosted platform, achieving ecosystem integration, growing a team and community, and executing go-to-market against a deeply entrenched incumbent.

For enterprise technology leaders

• Begin tracking AI code provenance now, even within Git. Adopt the git-ai standard or AIIR diff-hash sidecar as an interim measure.
• Evaluate Atomic for greenfield AI-native projects where provenance requirements are anticipated: regulated industries, government contracts, safety-critical systems.
• Quantify your actual merge conflict cost. Run the AgenticFlict simulation pipeline against your own repositories. If it approaches 28 percent, the ROI case becomes concrete and measurable.
• Do not assume GitHub will solve this at the foundation. A multi-vendor AI development strategy requires vendor-neutral provenance infrastructure.

For the Atomic team

• The hosted platform is the single highest-priority investment. Mercurial's technical superiority did not overcome GitHub's network effects. Technical merit without a hosted collaboration layer does not convert into adoption.
• Publish benchmarks. Running Atomic against Git on the Linux kernel, Chromium, and at least one large enterprise monorepo is required for enterprise credibility.
• The regulatory wedge is the go-to-market entry point. Defense, finance, and life sciences are the highest-priority verticals.
• GitHub integration is the bridge strategy. Adoption at the margin is more achievable than adoption as a migration.

Conclusion

Git's dominance is not threatened by a better version of Git. It is threatened by a change in what version control must do. When AI generates the majority of code, version control must answer questions Git was never designed to answer: who wrote this, human or machine, which model, at what cost, with what reasoning, and can you prove it.

Atomic Code Intelligence provides structurally sound answers to those questions. Its architecture (immutable content-addressed changes, hierarchical CRDT merge, causal provenance graphs, and cryptographic attestation) addresses the AI era's requirements not as features bolted onto an existing system but as consequences of its data model.

The technology is mature. The market need is demonstrated by data. The competitive moat is structural, not feature-wise. What remains is execution.

Sources & methodology

Primary research

1. github.com/atomicdotdev/atomic, 233K lines of Rust · 454 source files · 6,423 test functions (Codebase)
2. docs.atomic.dev, Architecture & reference documentation review (Docs)

Academic sources

1. AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests, arXiv preprint · 2604.03551 (Apr 2026)
2. MergeBERT / DeepMerge, Svyatkovskiy et al. · Microsoft Research · 220K real-world conflicts; token-level diff3 auto-resolves 36.1% (FSE 2022)
3. Merge conflict taxonomy, Brindescu et al. · 6,979 conflicts, 143 Java projects (2019)
4. Conflict-free Replicated Data Types, Preguica et al. · arXiv 1805.06358 (2018)
5. A Categorical Theory of Patches, Mimram & Di Giusto · arXiv 1311.3903 (2013)
6. CodeCompass: Graph-Structured Dependency Navigation Outperforms Retrieval in Architecture-Heavy Tasks, arXiv preprint · 2602.20048 (Feb 2026)

Industry sources

1. Copilot adoption & AI-generated code share, GitHub / Microsoft · 20M+ active users · 46% of code written by AI (2025)
2. The State of AI-Generated Code, FinishKit · 41% of all code globally AI-generated (2026)
3. AI-authored merged code share, DX Research · 22% of merged code AI-authored (2025–26)
4. VCS market share, CheckThat.ai · Git at 93.87% (2026)
5. Patch theory & CRDT foundations, Pijul Manual · pijul.org (Reference)

Provenance tooling referenced

1. AIIR: diff-hash-indexed provenance receipts, Invariant Systems · github.com/invariant-systems-ai/aiir (Project)
2. git-ai, Git AI Standard v3.0.0, refs/notes/ai with line-level attribution (Spec)
3. squash-tree, logical squash graph, widefix/squash-tree (Feb 2026)
4. Copilot Coding Agent provenance trailer, GitHub · Agent-Logs-Url: commit trailer (Mar 2026)

Regulatory

1. EU AI Act, Article 50, Consumer-facing AI content marking · assistive-editing carve-out · enforceable August 2026 (Aug 2026)