KI-gestütztes Integrations-Engineering mit Claude Code: Eine echte Debug-Session

Die meisten Geschichten über KI-generierte Codes sind Demos mit klar definierten Eingabeaufforderungen und einem eindeutigen Ergebnis. Dies ist anders. Dies ist eine echte Sitzung mit einem echten APIANT-Integrationsprodukt, inklusive der tatsächlichen Eingabeaufforderungen, der Fehlversuche, der Korrekturen und des Moments, in dem das menschliche Gedächtnis die Maschine überlistete.

Es geht nicht darum, wie beeindruckend KI ist. Es geht darum, wie die Zusammenarbeit tatsächlich aussieht, wenn man sich hinsetzt und die Arbeit erledigt.

Der Aufbau

Das Produkt ist eine unserer CRMConnect-Integrationen. Mindbody zu HubSpotEin Kunde meldete, dass Verkäufe, die mit mehr als einer Zahlungsmethode bezahlt wurden, nicht korrekt synchronisiert wurden. Ein Verkauf über 8.400 US-Dollar, aufgeteilt auf drei Zahlungsmethoden, wurde in HubSpot als ein einziger Deal über 400 US-Dollar angezeigt. Die restlichen 8.000 US-Dollar fehlten in der Pipeline.

Wir verfolgen die Entwicklungsarbeit in GitHub Issues. Die Kundenkommunikation findet im HubSpot Service Hub statt. Die Sitzung begann damit, dass der Entwickler die KI auf die Arbeit aufmerksam machte.

Prompt: „Schauen Sie sich das Zahlungsproblem an.“

Die KI durchsuchte die GitHub-Issues des Repos, fand den offenen Vorfall, las den vollständigen Text vor und gab ihn wieder: ein Fehler bei Mehrfachzahlungen, mit zwei Produktionsausführungs-IDs als Beweis. Keine weiteren Erklärungen nötig. Anschließend fragte sie in klaren Worten nach dem nächsten Schritt, anstatt zu raten.

Prompt: „Welche Logik bewirkt sie und welche Automatisierungen/Aktionen werden durchgeführt?“

Die KI lud die relevante Automatisierung von der Plattform, analysierte deren Struktur Schritt für Schritt und erklärte den Fehler präzise. Die Automatisierung erstellt für jeden HubSpot-Deal einen Deduplizierungsschlüssel. Bei Verkäufen mit mehreren Zahlungsmethoden gibt Mindbody pro Zahlungsmethode eine Zeile zurück, die alle denselben Schlüssel verwenden. Daher kollidierten die Zeilen zwei und drei mit dem Deal aus Zeile eins, und ihre Beträge wurden stillschweigend verworfen.

Nützlich. Aber der Bauunternehmer hatte bereits einen größeren Vorsprung.

Der Hinweis, der alles veränderte

Prompt: „Vergleichen Sie diese eindeutige Kennung für den Deal mit unserer Vorgehensweise im CRMConnect-MindBody-Zoho-Projekt. Ich dachte, wir hätten das Problem dort gelöst. Führen Sie einen präzisen Vergleich durch.“

Dieser eine Satz veränderte den Charakter der Arbeit. Der Bauunternehmer beschrieb keine Lösung. Er verwies auf ein ähnliches Produkt und sagte im Grunde: „Lesen Sie es.“

Und die KI tat es. Sie öffnete die Mindbody zu Zoho Die Integration, ein völlig separates Produkt, lokalisierte die Automatisierung, die historische Verkäufe verarbeitet, und las sie aus. Anschließend fand und las sie die Subroutine, die Zahlungsdatensätze schreibt. Nicht Zusammenfassungen, sondern die eigentliche Automatisierungslogik, Schritt für Schritt.

Es folgte ein gezielter Vergleich. Die Zoho-Integration hatte das Problem tatsächlich gelöst, jedoch mit einer anderen Architektur:

• Das HubSpot-Produkt erstellt pro Verkaufszeile einen einzigen pauschalen Deal unter Verwendung des älteren Verkaufsendpunkts von Mindbody, der die vor der Aufteilung der Zahlungen vorliegenden Zeilen zurückgibt.
• Das Zoho-Produkt erstellt einen übergeordneten Kaufdatensatz sowie separate untergeordnete Datensätze für die einzelnen Positionen und die Zahlungen mithilfe des neueren Endpunkts von Mindbody, wobei jede Zahlung ihre eigene echte Zahlungs-ID hat.

Die KI kam zu dem Schluss, dass Zoho architektonisch sauberer sei, und schlug zunächst vor, das gesamte Drei-Objekt-Modell in HubSpot zu portieren.

Der Bauherr zieht den Umfang zurück

Hier sorgte der Mensch dafür, dass die Dinge auf dem Boden der Tatsachen blieben.

Prompt: „Für Version 4.0 sind wir noch nicht bereit. Heben wir uns das für später auf; jetzt müssen wir die vom Kunden gemeldeten Probleme mit fehlenden Deals beheben.“

Die KI hatte sich in Richtung einer zufriedenstellenden Architekturüberarbeitung entwickelt. Der Entwickler brachte das Problem auf den Punkt: Der Kunde benötigt korrekte Transaktionsbeträge, kein neues Datenmodell. Die KI stimmte zu, schloss den Überarbeitungsvorschlag als zukünftigen Punkt aus und konzentrierte sich fortan auf eine gezielte Korrektur der bestehenden Transaktionsautomatisierungen.

Diese Korrektur ist wichtig. KI ist gut darin, elegante, allgemeine Lösungen zu finden. Sie erkennt aber nicht immer, wann diese elegante Lösung über die aktuellen Anforderungen hinausgeht. Der Entwickler hat diese Einschätzung in einem Satz zusammengefasst.

Die KI adaptierte das Prinzip des Zoho-Designs, ohne dessen Struktur zu kopieren: Sie glich pro Verkaufsposition einen Deal ab, bezog die Daten von Mindbodys umfangreicherem Endpunkt und aggregierte den Betrag korrekt über alle Zahlungsmethoden hinweg, anstatt die erste Zahlung die restlichen überschreiben zu lassen. Andere Plattform, andere Vorgehensweise, gleiche Grundidee.

Die Ahnung

Bei der Überarbeitung des Deduplizierungsschlüssels untersuchte die KI eine seiner Komponenten: das Datum. Ihre Begründung war einleuchtend. Die Verkaufs-ID und die Verkaufsdetail-ID machen den Schlüssel bereits eindeutig. Das Datum ist überflüssig. Sie empfahl, es zu entfernen, um den Schlüssel zu vereinfachen und eine potenzielle Fehlerquelle zwischen den beiden Automatisierungen zu beseitigen.

Der Bauherr hatte keine Bauvorschrift, auf die er sich berufen konnte. Er hatte sein Gedächtnis.

Prompt: „Ich meine mich zu erinnern, dass ich das Datum hinzugefügt habe, weil es nötig war (zwei Zahlungen für dieselbe Transaktion oder etwas Ähnliches)?“

Keiner von beiden konnte es mit der bestehenden Automatisierung beweisen. Daher durchsuchte die KI den Versionsverlauf der Automatisierung. Diese enthielt 93 gespeicherte Versionen, die bis ins Jahr 2021 zurückreichten. Die KI las die Änderungsbeschreibungen, bis sie die relevanten Versionen gefunden hatte.

Ab Januar 2022:

„EPOCH MILLIS wurde hinzugefügt, um die Transaktions-ID in der Datenbank zu speichern und so die Eindeutigkeit bei Mehrfachzahlungen für denselben Artikel zu gewährleisten.“

Ab Februar 2022:

„Verkaufsdatum für die Immobiliensuche hinzugefügt, damit Zahlungen für frühere Verkäufe verarbeitet werden können.“

Dort stand es, in den Worten des Bauträgers, vier Jahre zuvor. Wenn ein Kunde eine Zahlung für einen früheren Kauf später leistet, überträgt Mindbody diesen Kauf erneut mit dem neuen Datum. Ohne das Datum im Schlüssel würde die spätere Zahlung mit dem ursprünglichen Geschäft kollidieren und keinen eigenen Datensatz erhalten. Das Datum war nicht überflüssig. Es war speicherrelevant und wurde bewusst hinzugefügt, um Ratenzahlungen und automatische Zahlungen zu verarbeiten.

Die KI reagierte darauf, indem sie ihre Empfehlung umgehend zurücknahm und dies unmissverständlich erklärte:

„Vertrauen Sie Ihrer Erinnerung. Wenn Sie das Datum absichtlich hinzugefügt haben, ist es relevant, und es wegzulassen, kommt nicht in Frage. Ich habe es in der Versionshistorie gefunden.“

Doch es ging noch weiter. Da das Datum erhalten bleiben musste, mussten die beiden Automatisierungen exakt denselben Datumswert liefern, sonst würden die Schlüssel nicht übereinstimmen und doppelte Einträge entstehen. Die ursprüngliche Automatisierung ermittelt das Datum aus einem bestimmten Mindbody-Feld. Die KI hat die neue Automatisierung so konfiguriert, dass sie genau dieses Feld mit demselben API-Aufruf und derselben Zeitzonenkonvertierung ausliest. Gleiche Eingabe, gleiche Ausgabe, garantiert übereinstimmende Schlüssel.

Ein Fehler, der die Ratenzahlungsabwicklung unbemerkt lahmgelegt hätte, trat nie ein. Nicht etwa, weil die KI vorsichtig war, sondern weil ein Mensch eine Ahnung hatte und die KI diese innerhalb von Sekunden anhand von vier Jahren Historie überprüfen konnte.

Der unglamouröse Teil: kompilieren, ausführen, Trace lesen, Fehler beheben

Nachdem das Design feststand, wurde es zu einem iterativen Entwicklungsprozess. Die Änderung wurde in einer Entwicklungsumgebung erstellt, ausgeführt, der Ausführungsprotokoll gelesen, das nächste Problem gefunden, behoben und erneut ausgeführt. Die eigentlichen Fehler waren alltäglicher Natur:

• Ein Schritt zur Vertragsgestaltung scheiterte mit sechzehn PROPERTY_DOESNT_EXIST Es traten Fehler auf, weil die Feldbindungen nicht die internen Eigenschaftsnamen von HubSpot enthielten. Die KI las den Trace, ermittelte das Feldschema des Konnektors und ordnete jedem Feld seine korrekte ID zu.
• Eine Schleife wurde zweimal statt nur einmal ausgeführt, da die Plattform die Iterationen anhand des längsten Arrays in den Quelldaten zählte und das Zahlungs-Array länger war als das Positions-Array. Die KI fügte eine explizite Iterationskontrolle ein, sodass die Schleife nur noch die Positionen zählte.
• Der Schritt „Deal finden“ stoppte den gesamten Lauf, da noch kein Deal existierte und der Standardfehlermodus „nicht gefunden“ als schwerwiegenden Fehler behandelte. Die KI änderte den Modus auf „Bei Fehler fortfahren“, damit der Zweig „Erstellen“ ausgeführt werden konnte, analog zur Vorgehensweise der anderen Automatisierung.

Nichts davon ist glamourös. Es ist die Realität der Integrationsarbeit. Was sich geändert hat, ist die Geschwindigkeit der Schleifen. Die KI konnte einen vollständigen, schrittweisen Ausführungsablauf analysieren und den fehlerhaften Schritt sofort identifizieren, sodass jeder Korrekturzyklus nur wenige Minuten dauerte. Nichts wurde an einen Kunden ausgeliefert, bevor die Entwicklertests nicht erfolgreich waren.

Was das für Bauherren bedeutet

Lässt man die Erzählung außer Acht, ergibt sich folgendes Funktionsmodell:

• Die Stärke der KI liegt im Lesen. Es untersuchte die Integration eines gesamten Geschwistersystems, verglich ein bereits gelöstes Problem, passte eine Architektur an zwei verschiedene Plattformen an und durchforstete neunzig Versionen der Projekthistorie, um eine Designentscheidung zu überprüfen. Das schafft kein Mensch an einem Nachmittag.
• Die Stärke des Menschen liegt in seinem Gedächtnis und seinem Urteilsvermögen. „Ich glaube, ich habe das aus einem bestimmten Grund hinzugefügt“ und „Noch nicht bereit für Version 4.0“ sind in keiner Datei zu finden. Beide Aussagen basieren auf der praktischen Erfahrung mit dem Produkt. Jede einzelne hat das Ergebnis beeinflusst.
• Die Geschwindigkeit kommt von der Schleife. Lies den Trace, korrigiere den Schritt und führe das Programm erneut aus. Die Reibungsverluste, die das Debuggen und die Rekonstruktion des Geschehens normalerweise verlangsamen, sind beseitigt.

KI-gestütztes Integrations-Engineering bedeutet nicht, dass die KI allein arbeitet oder dass der Mensch schneller arbeitet. Es bedeutet, dass die KI die Informationen liest, für die kein Mensch Zeit hat, und der Mensch den Kontext liefert, den keine Codebasis enthält. Durch diese Kombination wird ein vier Jahre alter, wiederkehrender Fehler in einer einzigen Arbeitssitzung verstanden, behoben und verifiziert.

Das ist der Arbeitsablauf, auf den es sich hinzuarbeiten lohnt.