Inżynieria integracji AI-First z Claude Code: prawdziwa sesja debugowania

Większość historii typu „sztuczna inteligencja napisała mój kod” to dema z czystym komunikatem i czystym rezultatem. To nie to. To prawdziwa sesja na temat prawdziwego produktu integracyjnego APIANT, obejmująca rzeczywiste komunikaty, błędne zwroty, poprawki i moment, w którym ludzka pamięć pokonała maszynę.

Nie chodzi o to, że sztuczna inteligencja robi wrażenie. Chodzi o to, jak faktycznie wygląda współpraca, kiedy siadasz i zaczynasz pracę.

Konfiguracja

Produkt jest jedną z naszych integracji CRMConnect, Mindbody do HubSpotKlient zgłosił, że sprzedaż opłacona za pomocą więcej niż jednej metody płatności nie synchronizowała się prawidłowo. Sprzedaż na kwotę 8400 USD, podzielona na trzy metody płatności, pojawiła się w HubSpot jako pojedyncza transakcja o wartości 400 USD. Pozostałe 8000 USD zniknęło z lejka sprzedażowego.

Śledzimy prace inżynieryjne w GitHub Issues. Rozmowa z klientem odbywa się w HubSpot Service Hub. Sesja rozpoczęła się od tego, że konstruktor wskazał AI pracę.

Podpowiedź: „spójrz na problem z płatnościami”

Sztuczna inteligencja przeszukała zgłoszenia w repozytorium w serwisie GitHub, znalazła otwarty incydent, pobrała pełną treść zgłoszenia i odczytała ją: błąd sprzedaży wielopłatnościowej, z dwoma identyfikatorami wykonania produktu jako dowodem. Nie było potrzeby prowadzenia za rękę. Następnie poprosiła o podanie kolejnego kroku w prostych słowach, zamiast zgadywać.

Podpowiedź: „co robi logika i jaka automatyzacja / działania?”

Sztuczna inteligencja załadowała odpowiednią automatyzację z platformy, przeszła krok po kroku przez jej strukturę i dokładnie wyjaśniła awarię. Automatyzacja tworzy klucz deduplikacji dla każdej transakcji HubSpot. W przypadku sprzedaży z wieloma płatnościami, Mindbody zwraca jeden wiersz dla każdej metody płatności, wszystkie współdzieląc ten sam klucz. W związku z tym wiersze drugi i trzeci kolidowały z transakcją utworzoną przez wiersz pierwszy, a ich kwoty zostały po cichu usunięte.

Przydatne. Ale budowniczy miał już większą przewagę.

Wskazówka, która wszystko przekierowała

Podpowiedź: „Porównaj ten unikalny identyfikator transakcji z tym, jak to robimy w projekcie crmconnect-mindbody-zoho. Myślałem, że już to rozwiązaliśmy. Zrób precyzyjne porównanie”.

To jedno zdanie zmieniło kształt dzieła. Wykonawca nie opisał naprawy. Wskazał na produkt pokrewny i powiedział w zasadzie: idź i go przeczytaj.

Więc sztuczna inteligencja to zrobiła. Otworzyła Mindbody do Zoho Integracja, zupełnie oddzielny produkt, zlokalizowała automatyzację obsługującą historię sprzedaży i ją odczytała. Następnie odnalazła i odczytała podprocedurę, która zapisuje rekordy płatności. Nie podsumowania. Rzeczywistą logikę automatyzacji, krok po kroku.

Wróciliśmy z dokładnym porównaniem. Integracja Zoho rzeczywiście rozwiązała ten problem, ale z inną architekturą:

• Produkt HubSpot generuje jedną stałą transakcję na wiersz sprzedaży, korzystając ze starszego punktu końcowego sprzedaży Mindbody, który zwraca wiersze płatności przed podziałem.
• Produkt Zoho tworzy nadrzędny rekord zakupu oraz oddzielne rekordy podrzędne dla pozycji zamówienia i płatności, korzystając z nowszego punktu końcowego Mindbody, w którym każda płatność ma swój własny, rzeczywisty identyfikator płatności.

Sztuczna inteligencja uznała, że Zoho jest bardziej przejrzyste pod względem architektonicznym i początkowo zaproponowała przeniesienie całego modelu składającego się z trzech obiektów do HubSpot.

Deweloper wycofuje zakres

To właśnie tutaj człowiek utrzymuje wszystko w ryzach.

Podpowiedź: „Jeszcze nie jesteśmy gotowi na wersję 4.0. Zostawmy to na później, teraz musimy rozwiązać problemy z brakującymi ofertami zgłoszone przez klienta.”

Sztuczna inteligencja zmierzała w kierunku satysfakcjonującego przeprojektowania architektury. Twórca oprogramowania skupił się na samym problemie: klient potrzebuje prawidłowych kwot transakcji, a nie nowego modelu danych. Sztuczna inteligencja wyraziła zgodę, zamknęła propozycję przeprojektowania jako element przyszłości i zmieniła zakres, dokonując chirurgicznej poprawki istniejących automatyzacji transakcji.

Ta korekta ma znaczenie. Sztuczna inteligencja jest dobra w znajdowaniu eleganckich rozwiązań ogólnych. Nie zawsze jednak potrafi rozpoznać, kiedy eleganckie rozwiązanie jest lepsze niż wymaga tego sytuacja. Twórca zawarł tę ocenę w jednym zdaniu.

Następnie sztuczna inteligencja zaadaptowała zasadę leżącą u podstaw projektu Zoho, nie kopiując jego struktury: uzgadnianie jednej transakcji na pozycję sprzedaży, pobieranie danych z rozszerzonego punktu końcowego Mindbody i poprawna agregacja kwot dla wszystkich metod płatności, zamiast pozwalać, aby pierwsza płatność nadpisywała pozostałe. Inna platforma, inne działania, ta sama podstawowa idea.

Przeczucie

Podczas przerabiania klucza deduplikacji, sztuczna inteligencja przyjrzała się jednemu z jego komponentów: dacie. Jej rozumowanie było jasne. Identyfikator sprzedaży i identyfikator szczegółów sprzedaży już czynią klucz unikalnym. Data jest zbędna. Zaleciła jej usunięcie, aby uprościć klucz i wyeliminować źródło niestabilności między dwiema automatyzacjami.

Deweloper nie miał żadnego przepisu, z którym mógłby się kłócić. Miał pamięć.

Podpowiedź: „przypominam sobie, że dodałem datę, bo było to konieczne (2 płatności w ramach tej samej transakcji, czy coś podobnego)?”

Żadna z nich nie mogła tego udowodnić na podstawie bieżącej automatyzacji. Dlatego sztuczna inteligencja sięgnęła do historii wersji automatyzacji. Automatyzacja miała dziewięćdziesiąt trzy zapisane wersje, sięgające 2021 roku. Sztuczna inteligencja czytała opisy zmian, aż znalazła te, które jej odpowiadały.

Od stycznia 2022 r.:

„Dodano EPOCH MILLIS do zapisywania identyfikatorów transakcji w bazie danych, aby zachować ich unikalność w przypadku dokonywania wielu płatności za ten sam przedmiot”

Od lutego 2022 r.:

„Dodano datę sprzedaży dla funkcji wyszukiwania ofert według właściwości niestandardowej, aby umożliwić przetwarzanie płatności za poprzednie transakcje”

Było to, jak sam deweloper powiedział, cztery lata wcześniej. Kiedy klient dokonuje płatności później w ramach wcześniejszej sprzedaży, Mindbody ponownie wystawia tę sprzedaż w nowym terminie. Bez daty w kluczu, późniejsza płatność koliduje z pierwotną transakcją i nie może zostać zarejestrowana. Data nie była zbędna. Była nośna, celowo dodana, aby obsługiwać płatności ratalne i automatyczne.

Reakcją sztucznej inteligencji było natychmiastowe wycofanie rekomendacji i wyraźne jej oświadczenie:

„Zaufaj temu wspomnieniu. Jeśli celowo dodałeś datę, jest ona nośna, a jej usunięcie jest niemożliwe. Znalazłem to w historii wersji.”

Potem poszło jeszcze dalej. Ponieważ data musiała pozostać niezmieniona, dwie automatyzacje musiały wygenerować dokładnie tę samą wartość daty, w przeciwnym razie klucze nie byłyby zgodne i pojawiałyby się duplikaty transakcji. Oryginalna automatyzacja tworzy datę z określonego pola Mindbody. Sztuczna inteligencja przekierowała nową automatyzację, aby odczytała to samo pole, z tego samego wywołania API, z tą samą konwersją strefy czasowej. Te same dane wejściowe, te same dane wyjściowe, klucze gwarantowane.

Regresja, która dyskretnie zakłóciłaby obsługę płatności ratalnych, nigdy nie nastąpiła. Nie dlatego, że sztuczna inteligencja była ostrożna, ale dlatego, że człowiek zapamiętał przeczucie, a sztuczna inteligencja mogła je zweryfikować w ciągu kilku sekund, porównując z historią czterech lat.

Nieefektowna część: zbuduj, uruchom, odczytaj ślad, napraw

Po ustaleniu projektu, nastąpiła iteracyjna inżynieria. Zbudować zmianę w środowisku programistycznym, uruchomić ją, odczytać ślad wykonania, znaleźć kolejny problem, naprawić i uruchomić ponownie. Prawdziwe błędy były zwyczajne:

• Nie powiódł się etap tworzenia transakcji z szesnastoma PROPERTY_DOESNT_EXIST Błędy, ponieważ powiązania pól nie zawierały wewnętrznych nazw właściwości HubSpot. Sztuczna inteligencja odczytała ślad, pobrała schemat pól łącznika i ponownie powiązała każde pole z jego poprawnym identyfikatorem.
• Pętla uruchomiła się dwukrotnie, podczas gdy powinna była uruchomić się raz, ponieważ platforma zliczała iteracje od najdłuższej tablicy w danych źródłowych, a tablica „Płatności” była dłuższa niż tablica „Pozycje”. Sztuczna inteligencja wstawiła jawną kontrolę iteracji, więc pętla zliczała tylko pozycje.
• Krok „znajdź ofertę” zatrzymywał cały przebieg, gdy nie istniała jeszcze żadna oferta, ponieważ domyślny tryb błędu traktował komunikat „nie znaleziono” jako krytyczny. Sztuczna inteligencja przełączyła go na tryb „kontynuuj w razie błędu”, aby gałąź tworzenia mogła zostać uruchomiona, podobnie jak powiązana automatyzacja już sobie z tym poradziła.

Nic z tego nie jest efektowne. To rzeczywista struktura pracy integracyjnej. Zmieniła się prędkość pętli. Sztuczna inteligencja mogła odczytać pełny ślad wykonania krok po kroku i natychmiast wskazać błąd, więc każdy cykl naprawy trwał minuty. Nic nie zostało wysłane do klienta, dopóki testy deweloperskie nie przeszły pomyślnie.

Co to oznacza dla deweloperów

Odrzuć narrację, a otrzymasz działający model:

• Siłą sztucznej inteligencji jest czytanie. Przeanalizowano integrację całego systemu siostrzanego, dokonano wzajemnych odniesień do problemu, który już rozwiązaliśmy, dostosowano architekturę na dwóch różnych platformach i przeanalizowano dziewięćdziesiąt wersji historii, aby zweryfikować jedną decyzję projektową. Żaden człowiek nie robi tego w jedno popołudnie.
• Siłą człowieka jest pamięć i osąd. „Myślę, że dodałem to z jakiegoś powodu” nie znajduje się w żadnym pliku. „Jeszcze nie gotowy na wersję 4.0” nie znajduje się w żadnym pliku. Oba pochodzą z doświadczenia z produktem. Każdy z nich zmienił wynik.
• Prędkość pochodzi z pętli. Przeczytaj ślad, popraw krok, uruchom ponownie. Tarcie, które zazwyczaj spowalnia debugowanie i rekonstrukcję tego, co się stało, zniknęło.

Inżynieria integracyjna AI first to nie sztuczna inteligencja działająca w pojedynkę ani człowiek pracujący szybciej. To sztuczna inteligencja czyta kod, na który żaden człowiek nie ma czasu, a człowiek dostarcza kontekst, a nie rekordy w bazie kodu. Połącz te elementy, a czteroletni, powtarzający się błąd zostanie zrozumiany, naprawiony i zweryfikowany w ciągu jednej sesji roboczej.

To jest przepływ pracy, który warto rozwijać.