The Silent Conflict Problem

The worst version control bug is a merge that succeeded when it should have failed. Aura would rather stop and ask.

"In a real-time collaborative system, the only thing worse than a conflict is a conflict that nobody noticed."

The Concern

The sharpest critique of real-time collaborative coding runs like this: you have two developers (or two AI agents) editing the same codebase. Their edits are being merged continuously in the background. Sooner or later, their changes will overlap. When that happens, you have three possible behaviors:

Stop and ask a human. Safe, but defeats the point of "real-time."
Auto-merge using text-level heuristics. Fast, but produces silently broken code when the heuristics are wrong.
Auto-merge using semantic or AI reasoning. The holy grail, but still an open research problem, and when the AI is wrong, it is wrong in ways that are hard to detect.

Option 2 is the default of every "real-time code editing" tool that has ever shipped. Option 3 is what a lot of recent AI-first tools are quietly attempting. Option 1 is what a senior engineer wishes everyone would do.

The data suggests the fear is justified. The AgenticFlict study (2024) found that when multiple AI agents work on the same repo in parallel, 26.86% of their interactions produced a merge conflict of some kind. Not 3%. Not 10%. Roughly one in four. If your tool's answer to "what do we do with conflicts?" is "auto-merge them, the AI is smart enough," you are about to ship a lot of subtly broken code.

How Aura Handles It

Aura's answer is option 1, on purpose, with a specific definition of "conflict" that is narrower than text-based VCS.

The operating principle:

Aura refuses to guess. If two edits touch the same function in different ways, we stop and surface the choice. We do not auto-merge.

That is the simplest one-line description of our conflict model. The rest of this page is the consequences of that principle.

What counts as a conflict

Aura's merge logic works at function granularity. The rules:

| Scenario | Aura's behavior | |---|---| | Two peers edit different functions in the same file | Auto-merge. Zero conflict. | | Two peers edit different files | Auto-merge. Zero conflict. | | Two peers edit the same function, same AST | No-op. Zero conflict. | | Two peers edit the same function, different ASTs | Conflict raised. Interactive picker. | | One peer deletes a function, other edits it | Conflict raised. Interactive picker. | | Both peers add a new function with the same name and signature | Conflict raised. Interactive picker. | | One peer renames a function, other edits it | Auto-merge (Aura tracks identity across renames). | | One peer changes a function's signature, other changes its body | Conflict raised if the body depends on the signature. |

The pattern: when the AST clearly shows two orthogonal edits, we merge. When the AST shows semantic overlap, we halt. See AST merge for the full algorithm.

This is narrower than Git's text-based conflict detection. Git flags a conflict whenever two edits touch overlapping line ranges, even if they are semantically independent (e.g., both of you added an import at the top of the file). Aura's AST-aware view correctly merges those cases. But where Git would attempt a three-way text merge and produce a file with conflict markers, Aura raises an explicit structured conflict and surfaces it through the interactive picker.

The interactive picker

When a same-function conflict occurs, Aura does not attempt to auto-merge the function bodies. It presents you with:

CONFLICT in compute_tax (src/billing.rs)
  Local  (yours):        12 lines, added rounding
  Remote (alice@team):   14 lines, added region parameter

  [1] Keep local
  [2] Keep remote
  [3] Keep both (as new function)
  [4] Open in editor and author a merge
  [5] Defer (mark as unresolved)

Option 4 is the honest path: a human reads both versions, understands the semantic intent of each, and writes the merged function. Option 5 marks the conflict unresolved in Aura's state, keeps your local copy on your machine, and notifies the other developer via team messages that coordination is needed.

We did not implement "option 6: ask Claude to merge." We have prototyped that. It works well, until it doesn't, and when it doesn't, the merge is wrong in ways that are not obvious. We are keeping it in research until we have a way to bound its errors.

The AUTO-Merge Strategies Aura Refuses to Offer

We get asked for these regularly. Here is what we refuse and why.

Union merge for same-function conflicts. Taking the union of two function bodies (local lines + remote lines) is what Git can be coaxed into doing with merge=union in .gitattributes. For code, it produces functions that contain both old and new logic and typically do not compile. We will not ship this as a default.

"Ours" or "theirs" auto-resolution at the repo level. Picking a side silently is exactly the silent-conflict failure mode. We will not ship this. You can of course do it manually by choosing option 1 or 2 in the picker, but that is a deliberate act.

LLM-driven auto-merge. We have experimented. When the conflict is cosmetic (renamed variable, slightly different formatting) the LLM is reliable. When the conflict is semantic (two different bug fixes for the same issue, two different refactors of the same function) the LLM produces plausible-looking code that is subtly wrong in about one in five cases in our internal testing. That is an unacceptable failure rate for a silent operation. The LLM can be invoked explicitly via aura merge --suggest, which surfaces the suggestion for human review but does not apply it.

Eager real-time merge during typing. We have discussed this every few months since the project started. The conclusion every time: the correct moment to merge is when a function parses and is stable, not while someone is mid-keystroke. The cost of waiting five seconds is small. The cost of broadcasting broken intermediate states is catastrophic. See code is not Figma.

Why the 26.86% Number Matters

The AgenticFlict result is not surprising to anyone who has watched two AI agents work on the same file. Agents do not coordinate implicitly the way humans do. A human pair programmer will say "I'll take the parser, you take the validator." Two agents, given the same task, will each try to take the parser.

Aura's answer to this, specifically:

Zone claims: agents can reserve files or functions. A second agent trying to edit a claimed zone sees a BLOCKED response and must either wait or negotiate via Sentinel messages.
Agent collision detection: if two agents edit the same function anyway, Aura raises a SENTINEL COLLISION event immediately, not at merge time.
Function-level sync debounce: agents see each other's completed functions every ~5 seconds, reducing the chance of simultaneous independent work on the same code.

None of these eliminate conflicts. They reduce the rate and, when conflicts do occur, they are flagged early rather than allowed to compound. In internal testing across multi-agent workflows, conflict rates drop substantially with zones enabled — but we are not going to print a specific number because the comparison depends heavily on workload, and we would rather underclaim.

What Aura Does Not Solve

Semantic conflicts across functions. If you edit compute_tax to return cents and I edit render_invoice (which calls compute_tax) to expect dollars, Aura's function-level merge is clean — no same-function conflict — but the program is wrong at runtime. This is a cross-function semantic conflict. Impact alerts catch many of these by tracking callers of modified functions and flagging the affected call sites, but the analysis is not complete. A type system catches some. A test suite catches some. Nothing catches all of them.

Semantic drift in interfaces. If two peers independently refactor the same trait, with different philosophies, and each migrates some callers, you end up with a half-refactored codebase. Aura shows you the partial state honestly. It does not repair it.

Conflicts between Aura and Git. If a teammate without Aura installed does a git merge that Git's text-level logic resolves in a way Aura would not have chosen, Aura respects the Git result (the file on disk is the source of truth) and updates its semantic state accordingly. We do not override text merges that the team has already accepted. This is a correctness tradeoff in favor of compatibility.

The human who clicks "keep theirs" to make the picker go away. No tool fixes this. We can make the picker clear and informative. We cannot make people care.

The Honest Tradeoff

The tradeoff of refusing to auto-merge is friction. When a conflict is raised, somebody has to pause and make a decision. That decision is, in the short term, slower than a silent auto-resolution. In exchange, you do not ship subtly broken code and have to debug it later.

We think this tradeoff is right for code. We would not make the same choice for a Figma file, because a broken Figma file is a cosmetic problem. A broken function is a production incident.