AI-gestuurde integratietechniek met Claude Code: een echte debugsessie

De meeste verhalen over "AI heeft mijn code geschreven" zijn demonstraties met een duidelijke prompt en een duidelijk resultaat. Dit is anders. Dit is een echte sessie met een echt APIANT-integratieproduct, inclusief de daadwerkelijke prompts, de foute keuzes, de correcties en het moment waarop een menselijk geheugen de machine te slim af was.

Het gaat er niet om dat AI indrukwekkend is. Het gaat erom hoe de samenwerking er in de praktijk uitziet wanneer je samen aan de slag gaat.

De opstelling

Het product is een van onze CRMConnect-integraties. Mindbody naar HubSpotEen klant meldde dat verkopen die met meerdere betaalmethoden waren betaald, niet correct werden gesynchroniseerd. Een verkoop van $8.400, verdeeld over drie betaalmethoden, werd in HubSpot weergegeven als één enkele deal van $400. De overige $8.000 ontbrak in de verkooppijplijn.

We volgen de technische werkzaamheden in GitHub Issues. Het klantgesprek vindt plaats in HubSpot Service Hub. De sessie begon met de ontwikkelaar die de AI aan het werk zette.

Snel: “Kijk naar het betalingsprobleem”

De AI doorzocht de GitHub-issues van de repository, vond het openstaande incident, haalde de volledige code op en las deze voor: een bug in de verkoop met meerdere betaalmethoden, met twee productie-uitvoerings-ID's als bewijs. Geen verdere uitleg nodig. Vervolgens vroeg de AI in duidelijke bewoordingen naar de volgende stap, in plaats van te gissen.

Snel: “Wat doet de logica en welke automatisering/acties worden er uitgevoerd?”

De AI laadde de relevante automatisering van het platform, doorliep de structuur stap voor stap en legde de fout nauwkeurig uit. De automatisering genereert een deduplicatiesleutel voor elke HubSpot-deal. Bij verkopen met meerdere betaalmethoden retourneert Mindbody één rij per betaalmethode, waarbij alle rijen dezelfde sleutel delen. Hierdoor botsten rij twee en drie met de deal die door rij één was aangemaakt, waardoor de bedragen daarvan stilzwijgend werden verwijderd.

Nuttig. Maar de aannemer had al een grotere voorsprong.

De aanwijzing die alles in een andere richting stuurde.

Snel: "Vergelijk deze unieke identificatiecode voor de deal met hoe we het doen bij het crmconnect-mindbody-zoho-project. Ik dacht dat we het daar al hadden opgelost. Doe een zeer gerichte vergelijking."

Deze ene zin veranderde de hele opzet van het werk. De aannemer beschreef geen oplossing. Hij wees naar een verwant product en zei in feite: lees dat maar eens.

Dus dat deed de AI. Het opende de Mindbody naar Zoho Integratie, een volledig apart product, lokaliseerde de automatisering die historische verkoopgegevens verwerkt en las deze uit. Vervolgens vond en las het de subroutine die betalingsgegevens schrijft. Geen samenvattingen. De daadwerkelijke automatiseringslogica, stap voor stap.

Het resultaat was een gerichte vergelijking. De Zoho-integratie had dit inderdaad opgelost, maar met een andere architectuur:

• Het HubSpot-product genereert één vaste deal per verkoopregel, gebruikmakend van Mindbody's oudere verkoop-endpoint, dat vooraf gesplitste betalingsregels retourneert.
• Het Zoho-product schrijft een hoofdrecord voor aankopen en aparte subrecords voor artikelregels en betalingen, gebruikmakend van Mindbody's nieuwere endpoint, waarbij elke betaling een eigen, unieke betalings-ID heeft.

De AI concludeerde dat Zoho architectonisch schoner was en stelde aanvankelijk voor om het volledige model met drie objecten naar HubSpot over te zetten.

De aannemer beperkt de scope.

Dit is waar de mens de zaken met beide benen op de grond hield.

Snel: "Nog niet klaar voor V4.0. Bewaar het voor later, nu moeten we de problemen met ontbrekende deals oplossen die door klanten zijn gemeld."

De AI was afgedreven naar een bevredigende herziening van de architectuur. De ontwikkelaar bracht het echter terug naar het werkelijke probleem: de klant heeft correcte transactiebedragen nodig, geen nieuw datamodel. De AI stemde hiermee in, sloot het voorstel voor de herziening af als een toekomstig punt en beperkte zich tot een gerichte oplossing voor de bestaande automatiseringsprocessen voor transacties.

Die correctie is belangrijk. AI is goed in het vinden van de elegante algemene oplossing. Het is echter niet altijd even goed in het inschatten wanneer de elegante oplossing meer is dan wat het moment vereist. De ontwikkelaar gaf dat oordeel in één zin weer.

De AI paste vervolgens het principe achter het Zoho-ontwerp toe, zonder de structuur te kopiëren: één transactie per verkoopregel verwerken, de gegevens ophalen via het uitgebreidere eindpunt van Mindbody en het bedrag correct aggregeren over de verschillende betaalmethoden in plaats van de eerste betaling de rest te laten overschrijven. Ander platform, andere acties, hetzelfde onderliggende idee.

Het voorgevoel

Tijdens het herwerken van de sleutel voor het verwijderen van duplicaten, bekeek de AI een van de componenten: een datum. De redenering was helder. De verkoop-ID en de verkoopdetail-ID maken de sleutel al uniek. De datum is overbodig. De AI adviseerde om deze te verwijderen om de sleutel te vereenvoudigen en een bron van kwetsbaarheid tussen de twee automatiseringsprocessen te elimineren.

De aannemer had geen bouwvoorschriften om mee te discussiëren. Hij had een geheugen.

Snel: "Ik meen me te herinneren dat ik de datum heb toegevoegd omdat dat nodig was (twee betalingen voor dezelfde transactie, of zoiets vreemds)?"

Geen van beiden kon het bewijzen aan de hand van de huidige automatisering. Dus ging de AI de versiegeschiedenis van de automatisering in. De automatisering had 93 opgeslagen versies, teruggaand tot 2021. De AI las de beschrijvingen van de wijzigingen totdat de relevante gevonden waren.

Vanaf januari 2022:

"EPOCH MILLIS toegevoegd aan de database voor het opslaan van transactie-ID's, zodat deze uniek blijft bij meerdere betalingen voor hetzelfde artikel."

Vanaf februari 2022:

"Verkoopdatum toegevoegd voor 'vind deal op basis van aangepast vastgoed', zodat betalingen voor eerdere verkopen worden verwerkt."

Daar was het, zoals de bouwer zelf zei, vier jaar eerder. Wanneer een klant later een betaling doet voor een eerdere verkoop, registreert Mindbody die verkoop opnieuw op de nieuwe datum. Zonder de datum in de legenda botst de latere betaling met de oorspronkelijke deal en kan er geen eigen registratie van worden gemaakt. De datum was niet overbodig. Hij was juist essentieel en bewust toegevoegd om betalingen in termijnen en automatische incasso's te kunnen verwerken.

De AI reageerde door haar aanbeveling onmiddellijk terug te draaien en dat onomwonden te zeggen:

“Vertrouw op die herinnering. Als je de datum bewust hebt toegevoegd, is die bindend en kun je die niet weglaten. Ik heb hem gevonden in de versiegeschiedenis.”

Het ging nog een stap verder. Omdat de datum hetzelfde moest blijven, moesten de twee automatiseringsprocessen exact dezelfde datumwaarde produceren, anders zouden de sleutels niet overeenkomen en zouden er dubbele deals verschijnen. Het oorspronkelijke automatiseringsproces bouwt de datum op vanuit een specifiek Mindbody-veld. De AI zorgde ervoor dat het nieuwe automatiseringsproces datzelfde veld uitlas, via dezelfde API-aanroep en met dezelfde tijdzoneconversie. Dezelfde invoer, dezelfde uitvoer, gegarandeerd overeenkomende sleutels.

Een terugval die de afhandeling van termijnbetalingen stilletjes zou hebben verstoord, heeft zich nooit voorgedaan. Niet omdat de AI voorzichtig was, maar omdat een mens zich een vermoeden herinnerde en de AI dit binnen enkele seconden kon verifiëren aan de hand van vier jaar aan historische gegevens.

Het minder aantrekkelijke gedeelte: bouwen, uitvoeren, de foutmeldingen lezen, repareren.

Toen het ontwerp eenmaal vaststond, werd het een iteratief proces. De wijziging werd in een ontwikkelomgeving doorgevoerd, uitgevoerd, de uitvoeringslog werd geanalyseerd, het volgende probleem werd gevonden, opgelost en opnieuw uitgevoerd. De echte bugs waren alledaags:

• Een stap in het tot stand brengen van een deal mislukte bij zestien personen. PROPERTY_DOESNT_EXIST Er traden fouten op omdat de veldkoppelingen niet de interne eigenschapsnamen van HubSpot bevatten. De AI las de trace, haalde het veldschema van de connector op en koppelde elk veld opnieuw met de juiste ID.
• Een lus werd twee keer uitgevoerd terwijl dat maar één keer had gemoeten, omdat het platform de iteraties telde op basis van de langste array in de brongegevens, en de array met betalingen langer was dan de array met regelitems. De AI voegde een expliciete iteratiecontrole toe, zodat de lus alleen de regelitems telde.
• Een stap om een deal te vinden stopte de hele run toen er nog geen deal bestond, omdat de standaardfoutmodus "niet gevonden" als fataal beschouwde. De AI schakelde over naar "doorgaan bij fout" zodat de stap voor het aanmaken van de branch kon worden uitgevoerd, conform de manier waarop de sibling-automatisering dit al afhandelde.

Niets hiervan is glamoureus. Het is de daadwerkelijke realiteit van integratiewerk. Wat veranderd is, is de snelheid van de cyclus. De AI kon een volledige stapsgewijze uitvoeringsgeschiedenis lezen en direct de foutieve stap aanwijzen, waardoor elke herstelcyclus slechts enkele minuten duurde. Niets werd naar een klant verzonden voordat de ontwikkeltests waren geslaagd.

Wat dit betekent voor bouwers

Ontdoe je van het narratieve kader, dan blijft het werkmodel over:

• De kracht van de AI ligt in het lezen. Het bestudeerde een complete integratie van zustersystemen, vergeleek het met een probleem dat we al hadden opgelost, paste een architectuur aan voor twee verschillende platforms en dook in negentig versies van de geschiedenis om één ontwerpbeslissing te verifiëren. Geen mens doet dat in een middag.
• De kracht van de mens schuilt in het geheugen en het beoordelingsvermogen. "Ik denk dat ik dat om een bepaalde reden heb toegevoegd" staat in geen enkel bestand. "Nog niet klaar voor V4.0" staat in geen enkel bestand. Beide opmerkingen zijn voortgekomen uit de ervaring met het product. Elk van deze opmerkingen heeft het resultaat beïnvloed.
• De snelheid komt van de lus. Lees de trace, corrigeer de stap en voer het opnieuw uit. De wrijving die het debuggen en het reconstrueren van wat er is gebeurd normaal gesproken vertraagt, is verdwenen.

Bij AI-first integratietechniek werkt de AI niet alleen, en de mens werkt ook niet sneller. De AI leest de gegevens die de mens niet kan lezen, en de mens levert de context die niet in de code aanwezig is. Combineer die twee en een vier jaar oude, terugkerende bug wordt in één werksessie begrepen, opgelost en geverifieerd.

Dat is de workflow waar we naartoe moeten werken.