AI-conflictoplossing op Salesforce pull requests: waar AI zich bewijst

Kort gezegd: een merge-conflict is twee concurrerende wijzigingen aan hetzelfde deel van een bestand die versiebeheer niet zelf kan verzoenen. In Salesforce zijn de meeste niet echt: het is XML-volgordelawaai dat een metadatabewuste merge zonder tussenkomst hoort af te handelen. De interessante vraag is wat er gebeurt met de conflicten die dat filter overleven, en dat is de eerste plek in een releasepijplijn waar AI zich echt terugverdient.

Waarom produceert Salesforce zoveel merge-conflicten?

Twee structurele redenen, en beide zijn niemands schuld.

Ten eerste zijn de bestanden enorm. Een Profile beschrijft rechten over de hele org, dus twee developers die twee ongerelateerde objecten aanraken kunnen aangrenzende wijzigingen in een bestand veroorzaken. Profiles, permission sets, page layouts, Lightning pages en custom labels zijn de gebruikelijke verdachten.

Ten tweede is de volgorde van elementen in die bestanden niet stabiel. Haal hetzelfde Profile twee keer op en de lijstelementen kunnen in een andere volgorde terugkomen. Git ziet herschikte regels en noemt dat een wijziging, ook als de rechten qua betekenis identiek zijn. Zo besteedt een team een donderdagmiddag aan een conflict dat niet bestaat.

Wat is het verschil tussen een vals en een echt conflict?

Dit onderscheid is het hele artikel, dus laten we het expliciet maken.

• Vals conflict. De twee branches wijzigden verschillende dingen en alleen de tekstweergave botst. Twee developers voegden elk een veldrecht toe aan hetzelfde Profile. Het juiste antwoord is deterministisch: behoud beide.
• Echt conflict. De twee branches wijzigden hetzelfde ding naar verschillende waarden. De ene branch geeft leesrecht op een veld, de andere trekt het in. Geen algoritme weet welke klopt, want het antwoord staat in de tickets, niet in de XML.

Deze twee als een probleem behandelen is precies waarom conflicttooling een slechte naam krijgt. Ze vragen om verschillende machinerie.

Waarom lost semantisch mergen het eerste op en het tweede niet?

Een metadatabewuste merge parseert de XML naar elementen met stabiele sleutels en merget element voor element in plaats van regel voor regel. De open source Salesforce git merge driver is een goede publieke referentie voor die aanpak: hij identificeert unieke sleutels binnen metadata-elementen, merget losse entries in plaats van hele arrays, handelt deterministische herordening af voor echt geordende types zoals picklist value sets en record type-toewijzingen, en valt pas terug op een ruw conflict als hij een sleutel niet herkent. Commerciele tools doen hetzelfde; Gearset beschrijft een metadatabewust semantisch merge-algoritme om precies deze reden.

Dit is geen AI en moet dat ook niet zijn. Het is parsen, en parsen hoort deterministisch, snel en saai te zijn. Goed uitgevoerd verwijdert het de grote meerderheid van Salesforce-conflicten voordat een mens ze ziet.

Wat het niet kan, is beslissen. Als beide branches dezelfde sleutel op verschillende waarden zetten, weigert een correcte deterministische merger, en dat weigeren is terecht.

Waar verdient AI zich echt terug in een releasepijplijn?

Precies daar, bij die weigering. Conflictoplossing is een opvallend goede eerste klus voor AI in delivery, om vier redenen.

1. De taak is begrensd. Drie bekende inputs: de gemeenschappelijke voorouder, onze versie, hun versie. Geen open generatie.
2. De context die het oplost is machineleesbaar. Het ticket, de PR-beschrijving, de commitberichten en de omliggende metadata vertellen welke wijziging bedoeld was.
3. De uitkomst is verifieerbaar. Een voorgestelde oplossing valideert wel of niet tegen de doel-org. Dat is een echte test, geen gevoel.
4. Het is omkeerbaar. Een fout antwoord wordt in validatie gevangen of teruggedraaid, anders dan een foute architectuurkeuze die live gaat en doorwerkt.

Vergelijk dat met een model Apex laten schrijven, waar de input onbegrensd is, de context dubbelzinnig en verificatie het dure deel. Conflictoplossing heeft de tegenovergestelde vorm, en daarom is het de verstandige plek om te beginnen.

Hoe ziet een veilige AI-conflictoplossing eruit?

1. Ze leest metadatasemantiek, geen tekstregels. Krijgt het model conflictmarkeringen aangereikt, dan faalde de pijplijn al een stap eerder.
2. Ze toont voorouder, onze en hun versie naast elkaar, zodat een reviewer de redenering kan controleren en niet alleen de conclusie.
3. Ze geeft een reden, met verwijzing naar het ticket of de commit die een kant opzettelijk maakt.
4. Ze valideert het samengevoegde resultaat tegen de doel-org voordat de merge landt, niet erna.
5. Ze vereist menselijke goedkeuring. Altijd, en zeker bij rechtenmetadata, waar een stille automerge de toegang van elke gebruiker aan een Profile kan veranderen.
6. Ze schrijft een audittrail: wat is voorgesteld, wat is geaccepteerd, door wie.

Convergeert het ecosysteem hierop?

Ja, en snel. Salesforce' eigen DevOps Center levert nu conflictoplossing via MCP-tools, waarbij large language models conflicten analyseren, ze in natuurlijke taal uitleggen en oplossingen voorstellen vanuit de IDE. Als de platformleverancier LLM-conflictanalyse in de doos stopt, is de discussie of dit in een pijplijn hoort voorbij.

Serpent benadert het vanuit dezelfde richting. Het is de enige native MCP-server in Salesforce DevOps, met resolve_metadata_conflict naast plan_deploy, create_pull_request en trigger_pipeline, dus dezelfde oplossing is aan te sturen vanuit Claude, Cursor, Windsurf of Agentforce, met preflight-checks en verplichte menselijke goedkeuring. AI-codereview draait op elk plan, ook het gratis plan, omdat de review en het conflict hetzelfde gesprek over dezelfde wijziging zijn.

FAQ

Mag AI Salesforce-conflicten automatisch mergen zonder review?

Nee. Voorstellen en uitleggen, daarna menselijke goedkeuring verplichten, zeker bij Profiles en permission sets waar een slechte merge de toegang van elke toegewezen gebruiker verandert.

Maakt semantisch mergen AI overbodig?

Integendeel. Het verwijdert de valse conflicten, dus wat overblijft zijn precies de afwegingen waar extra context helpt.

Waarom zijn Profiles de grootste boosdoeners?

Het zijn enkele enorme bestanden over de hele org, dus ongerelateerd werk landt op aangrenzende regels, en hun lijstvolgorde is niet gegarandeerd stabiel tussen ophaalacties.

Welke context heeft een AI-resolver nodig?

De driewegdiff, het gekoppelde ticket, de commitberichten en de staat van de doel-org. Zonder die gokt hij zelfverzekerder dan een mens zou doen.

Hoe weten we dat een oplossing klopte?

Valideer het samengevoegde resultaat tegen de doel-org voordat de merge landt, en houd een auditrecord bij van wat is voorgesteld en wie het goedkeurde.