AI-först integrationsteknik med Claude Code: En riktig felsökningssession

De flesta berättelser om att "AI skrev min kod" är demonstrationer med en tydlig prompt och ett tydligt resultat. Det här är inte det. Det här är en riktig session om en riktig APIANT-integrationsprodukt, inklusive de faktiska prompterna, de felaktiga vändningarna, korrigeringarna och ögonblicket då ett mänskligt minne slog maskinen.

Poängen är inte att AI är imponerande. Poängen är hur samarbetet faktiskt ser ut när man sätter sig ner och gör jobbet.

Installationen

Produkten är en av våra CRMConnect-integrationer, Mindbody till HubSpotEn kund rapporterade att försäljning betald med mer än en betalningsmetod synkroniserades felaktigt. En försäljning på 8 400 dollar uppdelad på tre betalningsmetoder visades i HubSpot som en enda affär på 400 dollar. De övriga 8 000 dollarna saknades i pipelinen.

Vi spårar tekniskt arbete i GitHub Issues. Kundkonversationen finns i HubSpot Service Hub. Sessionen började med att byggaren pekade AI:n mot arbetet.

Prompt: "Titta på betalningsproblemet"

AI:n sökte igenom repoets GitHub-problem, hittade den öppna incidenten, hämtade hela innehållet och läste av det: en bugg i försäljning av flera betalningar, med två prod execution ID:n som angavs som bevis. Ingen handhavandeåtgärd behövdes. Den frågade sedan efter nästa steg i enkla ordalag istället för att gissa.

Prompt: "Vad gör logiken och vilka automatiseringar/åtgärder?"

AI:n laddade den relevanta automatiseringen från plattformen, gick igenom dess struktur steg för steg och förklarade felet exakt. Automatiseringen skapar en dedupliceringsnyckel för varje HubSpot-affär. För flerbetalningsförsäljningar returnerar Mindbody en rad per betalningsmetod, där alla delar samma nyckel, så rad två och tre kolliderade med affären som skapades av rad ett och deras belopp togs bort i tysthet.

Användbart. Men byggaren hade redan ett starkare försprång.

Ledtråden som styrde om allt

Prompt: "Jämför denna unika identifierare för affären med hur vi gör det med crmconnect-mindbody-zoho-projektet. Jag trodde att vi hade löst det där. Gör en laserfokuserad jämförelse."

Denna enda mening förändrade verkets form. Byggaren beskrev inte en reparation. Han pekade på en syskonprodukt och sa i princip, gå och läs den.

Så gjorde AI:n det. Den öppnade Mindbody till Zoho integrationen, en helt separat produkt, lokaliserade automationen som hanterar historisk försäljning och läste den. Sedan hittade och läste den subrutinen som skriver betalningsposter. Inte sammanfattningar. Själva automatiseringslogiken, steg för steg.

Den kom tillbaka med en fokuserad jämförelse. Zoho-integrationen hade verkligen löst detta, men med en annan arkitektur:

• HubSpot-produkten skriver en fast affär per försäljningsrad, med hjälp av Mindbodys äldre försäljningsslutpunkt, som returnerar fördelade betalningsrader.
• Zoho-produkten skriver en överordnad köppost plus separata underordnade poster för radartiklar och för betalningar, med hjälp av Mindbodys nyare slutpunkt, där varje betalning har sitt eget riktiga betalnings-ID.

AI:s tolkning var att Zoho var arkitektoniskt renare, och föreslog initialt att porta hela treobjektsmodellen till HubSpot.

Byggaren drar tillbaka kikarsiktet

Det är här människan höll saker jordade.

Prompt: "Inte redo för V4.0 än. Spara det till senare, nu måste vi åtgärda problemen med saknade affärer som rapporterats av kunden."

AI:n hade drivit mot en tillfredsställande omskrivning av arkitekturen. Byggaren reducerade det till det faktiska problemet: kunden behöver korrekta affärsbelopp, inte en ny datamodell. AI:n gick med på det, stängde omskrivningsförslaget som en framtida punkt och omarbetade gränserna till en kirurgisk lösning på de befintliga automatiseringarna av affärsavtal.

Den korrigeringen är viktig. AI är bra på att hitta den eleganta generella lösningen. Den är inte alltid bra på att veta när den eleganta lösningen är mer än vad ögonblicket kräver. Byggaren gav den bedömningen i en mening.

AI:n anpassade sedan principen bakom Zohos design, utan att kopiera dess struktur: avstämma en affär per försäljningsrad, hämta data från Mindbodys mer omfattande slutpunkt och aggregera beloppet korrekt över betalningsmetoder istället för att låta den första betalningen skriva över resten. Olika plattformar, olika åtgärder, samma underliggande idé.

Magkänslan

När AI:n omarbetade dedupliceringsnyckeln tittade den på en av dess komponenter: ett datum. Dess resonemang var tydligt. Försäljnings-ID och försäljningsdetalj-ID gör redan nyckeln unik. Datumet är redundant. Den rekommenderade att ta bort det för att förenkla nyckeln och ta bort en källa till bräcklighet mellan de två automatiseringarna.

Byggaren hade ingen kodreferens att argumentera mot. Han hade minne.

Prompt: "Jag tycks minnas att jag lade till datumet eftersom det behövdes (två betalningar på samma transaktion, eller något konstigt liknande)?"

Ingen av dem kunde bevisa det utifrån den aktuella automatiseringen. Så AI:n gick in i automatiseringens versionshistorik. Automatiseringen hade nittiotre sparade versioner, tillbaka till 2021. AI:n läste ändringsbeskrivningarna tills den hittade de relevanta.

Från januari 2022:

"Lade till EPOCH MILLIS för att spara transaktions-ID i databasen för att hålla det unikt när flera betalningar görs för samma artikel"

Från februari 2022:

"Lade till försäljningsdatum för att hitta affärer efter anpassad fastighet så att betalningar för tidigare försäljningar behandlas"

Där var det, med byggarens egna ord, fyra år tidigare. När en kund gör en betalning senare mot en tidigare försäljning, återbetalar Mindbody den försäljningen på det nya datumet. Utan datumet i nyckeln kolliderar den senare betalningen med den ursprungliga affären och kan inte få sin egen registrering. Datumet var inte redundant. Det var bärande, avsiktligt tillagt för att hantera avbetalningar och automatiska betalningar.

AI:s svar var att omedelbart upphäva sin rekommendation och säga det tydligt:

"Lita på det minnet. Om du lade till datumet medvetet är det bärande, och att ta bort det är uteslutet. Hittade det i versionshistoriken."

Sedan gick det längre. Eftersom datumet var tvunget att behållas, behövde de två automatiseringarna producera exakt samma datumvärde, annars skulle nycklarna inte matcha och dubbletter skulle visas. Den ursprungliga automatiseringen bygger datumet från ett specifikt Mindbody-fält. AI:n ompekade den nya automatiseringen för att läsa det identiska fältet, från samma API-anrop, med samma tidszonkonvertering. Samma indata, samma utdata, nycklar garanterat matchande.

En regression som i tysthet skulle ha stört hanteringen av avbetalningar inträffade aldrig. Inte för att AI:n var försiktig, utan för att en människa kom ihåg en magkänsla och AI:n kunde verifiera den mot fyra års historik på några sekunder.

Den oglamorösa delen: bygga, köra, läsa spåret, fixa

När designen var klar blev det iterativ ingenjörskonst. Bygg ändringen i en utvecklingsmiljö, kör den, läs exekveringsspåret, hitta nästa problem, åtgärda, kör om. De verkliga buggarna var vanliga:

• Ett steg i att skapa en affär misslyckades med sexton PROPERTY_DOESNT_EXIST fel eftersom fältbindningarna inte bar HubSpots interna egenskapsnamn. AI:n läste spårningen, hämtade kopplingens fältschema och returnerade varje fält med dess korrekta ID.
• En loop kördes två gånger när den borde ha körts en gång, eftersom plattformen räknade iterationer från den längsta arrayen i källdata, och betalningsarrayen var längre än radpostarrayen. AI:n infogade en explicit iterationskontroll så att loopen endast räknade radposter.
• Ett steg med "hitta affär" stoppade hela körningen när ingen affär ännu fanns, eftersom dess standardfelläge behandlade "not found" som fatalt. AI:n bytte till continue-on-error så att create-grenen kunde köras, vilket matchade hur den syskonautomatiserade funktionen redan hanterade den.

Inget av detta är glamoröst. Det är själva strukturen i integrationsarbetet. Det som förändrats är loophastigheten. AI:n kunde läsa ett fullständigt steg-för-steg-exekveringsspår och peka på det felaktiga steget omedelbart, så varje fixcykel tog några minuter. Ingenting levererades till en kund förrän utvecklingstesterna var klara.

Vad detta innebär för byggare

Strimla bort berättelsen och här är den fungerande modellen:

• AI:s styrka är läsning. Den studerade en hel syskonintegration, korsrefererade ett problem vi redan hade löst, anpassade en arkitektur över två olika plattformar och grävde igenom nittio versioner av historia för att verifiera ett designbeslut. Ingen människa gör det på en eftermiddag.
• Människans styrka är minne och omdöme. ”Jag tror att jag lade till det av en anledning” finns inte i någon fil. ”Inte redo för V4.0 än” finns inte i någon fil. Båda kom från att ha levt produkten. Var och en förändrade resultatet.
• Hastigheten kommer från loopen. Läs spårningen, fixa steget, kör om. Friktionen som vanligtvis saktar ner felsökningen och rekonstruktionen av vad som hände är borta.

AI-först integrationsteknik handlar inte om att AI:n arbetar ensam, och det är inte människan som arbetar snabbare. Det är AI:n som gör läsningen som ingen människa har tid med, och människan som tillhandahåller kontexten utan kodbasposter. Sätt ihop dessa saker och en fyra år gammal återkommande bugg förstås, åtgärdas och verifieras i en enda arbetssession.

Det är det arbetsflödet som är värt att bygga mot.