AI conflict resolution on Salesforce pull requests: where AI earns its place

TL;DR: A merge conflict is two competing changes to the same part of a file that version control cannot reconcile on its own. In Salesforce, most of them are not real: they are XML ordering noise that a metadata-aware merge should settle without asking anyone. The interesting question is what happens on the conflicts that survive that filter, and that is the first place in a release pipeline where AI genuinely earns its keep.

Why does Salesforce produce so many merge conflicts?

Two structural reasons, neither of which is anybody's fault.

First, the files are enormous. A Profile describes permissions across the whole org, so two developers touching two unrelated objects can produce adjacent edits in one file. Profiles, permission sets, page layouts, Lightning pages and custom labels are the usual suspects.

Second, element ordering inside those files is not stable. Retrieve the same Profile twice and the list entries can come back in a different sequence. Git sees reordered lines and calls it a change, even when the permissions are byte-for-byte equivalent in meaning. That is how a team ends up spending a Thursday afternoon resolving a conflict that does not exist.

What is the difference between a false conflict and a real one?

This distinction is the whole article, so it is worth stating plainly.

• False conflict. The two branches changed different things, and only the text representation collides. Two developers each added a field permission to the same Profile. The correct answer is deterministic: keep both.
• Real conflict. The two branches changed the same thing to different values. One branch grants read access to a field, the other revokes it. There is no algorithm that knows which one is right, because the answer lives in the tickets, not the XML.

Treating these as one problem is why conflict tooling gets a bad name. They need different machinery.

Why does semantic merging solve the first and not the second?

A metadata-aware merge parses the XML into elements with stable keys and merges element by element instead of line by line. The open-source Salesforce git merge driver is a good public reference for the approach: it identifies unique keys inside metadata elements, merges individual entries rather than whole arrays, handles deterministic reordering for genuinely ordered types such as picklist value sets and record type assignments, and only falls back to a raw conflict when it does not recognise a key. Commercial tools do the same thing; Gearset, for example, describes a metadata-aware semantic merge algorithm for exactly this reason.

This is not AI and should not be. It is parsing, and parsing should be deterministic, fast and boring. Done properly it removes the large majority of Salesforce conflicts before a human ever sees them.

What it cannot do is decide. When both branches set the same key to different values, a correct deterministic merger refuses, and it is right to refuse.

Where does AI actually earn its place in a release pipeline?

Right there, on the refusal. Conflict resolution is an unusually good first job for AI in delivery, for four reasons.

1. The task is bounded. Three known inputs: the common ancestor, our version, their version. No open-ended generation.
2. The context that resolves it is machine-readable. The ticket, the PR description, the commit messages and the sibling metadata all say which change was intentional.
3. The output is verifiable. A proposed resolution either validates against the target org or it does not. That is a real test, not a vibe.
4. It is reversible. The wrong answer is caught in validation or rolled back, unlike a wrong architectural decision that ships and compounds.

Compare that with asking a model to write Apex, where the input is unbounded, the context is ambiguous and verification is the expensive part. Conflict resolution is the opposite shape, which is why it is the sensible place to start.

What does a safe AI conflict resolution look like?

1. It reads metadata semantics, not text lines. If the model is being handed conflict markers, the pipeline already failed a step earlier.
2. It shows the ancestor, ours and theirs side by side, so a reviewer can check the reasoning rather than the conclusion.
3. It states a reason, referencing the ticket or commit that makes one side intentional.
4. It validates the merged result against the target org before the merge lands, not after.
5. It requires human approval. Always, and especially on permissions metadata, where a silent auto-merge can change access for every user attached to a Profile.
6. It writes an audit trail: what was proposed, what was accepted, by whom.

Is the ecosystem converging on this?

Yes, and quickly. Salesforce's own DevOps Center now ships merge conflict resolution through MCP tools, using large language models to analyse conflicts, explain them in natural language and suggest solutions from inside an IDE. When the platform vendor puts LLM conflict analysis in the box, the argument about whether this belongs in a pipeline is over.

Serpent has approached it from the same direction. It is the only native MCP server in Salesforce DevOps, with resolve_metadata_conflict alongside plan_deploy, create_pull_request and trigger_pipeline, so the same resolution can be driven from Claude, Cursor, Windsurf or Agentforce with preflight checks and mandatory human approval. AI code review runs on every plan, including the free tier, because the review and the conflict are the same conversation about the same change.

FAQ

Should AI auto-merge Salesforce conflicts without review?

No. Propose and explain, then require a human approval, particularly on Profiles and permission sets where a bad merge changes access for every assigned user.

Does semantic merging make AI unnecessary?

The opposite. It removes the false conflicts, so the ones left are exactly the judgement calls where extra context helps.

Why are Profiles the worst offenders?

They are single enormous files covering the whole org, so unrelated work lands in adjacent lines, and their list ordering is not guaranteed to be stable between retrievals.

What context does an AI resolver need to be useful?

The three-way diff, the linked ticket, the commit messages and the state of the target org. Without those it is guessing more confidently than a human would.

How do we know a resolution was correct?

Validate the merged result against the target org before the merge lands, and keep an audit record of what was proposed and who approved it.