Najpierw wykorzystali ChatGPT do obniżenia kosztów. Następnie wynajęli nas, aby oczyścić dług techniczny AI

5 sierpnia 2025 r. 10 minut

Podsumuj artykuł za pomocą AI

Zdziwiłbyś się, jak wiele firm robi to obecnie.

Jak wskazują raporty z całej branży, obecnie rośnie wyspecjalizowany sektor dla inżynierów, którzy koncentrują się na poprawianiu błędów w kodzie generowanych przez AI.

Wzorzec ten stał się niezwykle spójny. Firmy zwracają się do ChatGPT, aby wygenerować skrypty migracyjne, integracje lub całe funkcje, mając nadzieję na oszczędność czasu i obniżenie kosztów. W końcu technologia wydaje się szybka i dostępna.

Wtedy systemy zawodzą.

I dzwonią do nas.

Ostatnio otrzymujemy coraz więcej takich próśb. Nie chodzi o dostarczenie nowego produktu, ale o rozwiązanie bałaganu, który pozostał po tym, jak ktoś zaufał modelowi językowemu w swoim kodzie produkcyjnym.

W tym momencie zaczyna to wyglądać jak własna niszowa branża. Naprawianie błędów generowanych przez AI jest teraz płatną usługą. W niektórych przypadkach bardzo kosztowną.

Raport GitClear 2024 potwierdza to, co zaobserwowaliśmy u klientów: Narzędzia do kodowania AI przyspieszają dostawę, ale także napędzają powielanie, ograniczają ponowne wykorzystanie i zawyżają długoterminowe koszty utrzymania.

W jednym przypadku klient zgłosił się do nas po tym, jak migracja wygenerowana przez AI spowodowała utratę krytycznych danych klienta. Spędziliśmy 30 godzin odzyskiwania utraconych danych, przepisywania logiki od zera i czyszczenia potoku. Ironią losu jest to, że byłoby taniej, gdyby starszy programista napisał to w staroświecki sposób.

Wyjaśnijmy jednak, że nie jesteśmy "przeciwko AI". My też go używamy. I jest pomocny we właściwym kontekście, z odpowiednimi zabezpieczeniami. Ale to, co frustruje mnie w nadmiernym poleganiu na AI i jego powszechnych implikacjach - i prawdopodobnie także ciebie - to magiczne myślenie. Pomysł, że model językowy może zastąpić prawdziwą pracę inżynierską.

Nie może. A jak mówi przysłowie, dowód tkwi w budyniu. Kiedy firmy udają, że jest inaczej, w końcu płacą komuś takiemu jak my, aby to posprzątał.

Jak więc wygląda jedna z tych prac porządkowych? Oto, czego AI-afficionados nie mówią, jeśli chodzi o stracony czas i zmarnowane pieniądze.

Jak wygląda typowe żądanie

Wiadomość jest zazwyczaj następująca:

"Hej, możesz rzucić okiem na mikrousługę, którą zbudowaliśmy? Użyliśmy ChatGPT do wygenerowania pierwszej wersji. Przesunęliśmy ją do etapu przejściowego, a teraz nasza kolejka RabbitMQ jest całkowicie zalana".

Zawsze zaczyna się od czegoś małego. Zadanie, które wydawało się zbyt nudne lub czasochłonne. Coś w rodzaju parsowania CSV, przepisania zadania cron lub podłączenia prostego webhooka. Przekazują je więc modelowi językowemu i liczą na najlepsze.

Ale jest jedna rzecz: objawy pojawiają się znacznie później. Czasami nawet kilka dni później. A kiedy to robią, rzadko jest oczywiste, że główną przyczyną był kod wygenerowany przez AI. Po prostu wygląda na to, że... coś jest nie tak.

"Nie można zlecić myślenia architektonicznego modelowi językowemu. AI może przyspieszyć pracę, ale nadal potrzeba inżynierów, aby zbudować systemy, które nie rozpadną się pod presją".

Dmitry Nazarevich

Dyrektor ds. technicznych

Po kilkunastu takich przypadkach zaczynają pojawiać się wzorce:

Brak testów. W ogóle. Nie ma nawet asercji hello-world. Po prostu surowy, spekulacyjny kod, który nigdy nie został poprawnie przetestowany.
Brak świadomości granic systemu. Widzieliśmy skrypty ChatGPT, które synchronicznie odpytywały trzy mikrousługi, ignorowały timeouty i wysadzały cały łańcuch połączeń przy pierwszym niepowodzeniu.
Niewłaściwe wykorzystanie transakcji. Jeden z klientów korzystał z SQL generowanego przez AI z zagnieżdżonymi transakcjami wewnątrz usługi Node.js korzystającej z Knex. Wszystko działało, dopóki nie przestało i połowa zapisów zakończyła się niepowodzeniem.
Subtelne warunki wyścigu. Zwłaszcza w wielowątkowych lub asynchronicznych bazach kodu. Tego rodzaju błędy, które nie pojawiają się w fazie deweloperskiej, ale niszczą produkcję na dużą skalę.

I oczywiście, gdy wszystko się zawali, AI nie zostawi ci komentarza mówiącego: "Przy okazji, zgaduję tutaj".

Ta część zależy od ciebie.

Przypadek 1: Skrypt migracyjny, który po cichu porzucił dane klientów

Ta pochodzi od szybko rozwijającej się firmy z branży fintech.

Wprowadzali nową wersję modelu danych klientów, dzieląc jedno duże pole JSONB w Postgres na wiele znormalizowanych tabel. Dość standardowa rzecz. Ale z napiętymi terminami i niewystarczającą liczbą rąk, jeden z programistów postanowił "przyspieszyć pracę", prosząc ChatGPT o wygenerowanie skryptu migracyjnego.

Na pierwszy rzut oka wyglądało to dobrze. Skrypt przeanalizował JSON, wyodrębnił informacje kontaktowe i wstawił je do nowego pliku user_contacts tabela.

Więc go uruchomili.

Brak pracy na sucho. Żadnej kopii zapasowej. Prosto do etapu przejściowego, który, jak się okazało, udostępniał dane produkcji za pośrednictwem repliki.

Kilka godzin później obsługa klienta zaczęła otrzymywać wiadomości e-mail. Użytkownicy nie otrzymywali powiadomień o płatnościach. Inni nie mieli numerów telefonów w swoich profilach. Wtedy do nas zadzwonili.

Co poszło nie tak

Wyśledziliśmy problem w skrypcie. Wykonał on podstawową ekstrakcję, ale przyjął trzy fatalne założenia:

Nie poradził sobie NULL lub brakujące klucze w strukturze JSON.
Wstawił częściowe rekordy bez walidacji.
Użyto ON CONFLICT DO NOTHING, więc wszelkie nieudane wstawienia były po cichu ignorowane.

Wynik: o 18% danych kontaktowych został utracony lub uszkodzony. Brak dzienników. Brak komunikatów o błędach. Po prostu cicha utrata danych.

Co trzeba było naprawić

Wyznaczyliśmy niewielki zespół, którego zadaniem było rozplątanie tego bałaganu. Oto, co zrobiliśmy:

Diagnoza i replikacja (4 godziny) Odtworzyliśmy skrypt w środowisku piaskownicy i uruchomiliśmy go w oparciu o migawkę bazy danych. W ten sposób potwierdziliśmy problem i dokładnie określiliśmy, czego zabrakło.
Śledczy audyt danych (8 godzin) Porównaliśmy uszkodzony stan z kopiami zapasowymi, zidentyfikowaliśmy wszystkie rekordy z brakującymi lub częściowymi danymi i dopasowaliśmy je do dzienników zdarzeń, aby prześledzić, które wstawki nie powiodły się i dlaczego.
Przepisanie logiki migracji (12 godzin) Przepisaliśmy cały skrypt w Python, dodaliśmy pełną logikę walidacji, zbudowaliśmy mechanizm wycofywania i zintegrowaliśmy go z potokiem CI klienta. Tym razem obejmowało to testy i obsługę suchych przebiegów.
Ręczne odzyskiwanie danych (6 godzin) Niektórych rekordów nie można było odzyskać z kopii zapasowych. Wyciągnęliśmy brakujące pola z systemów zewnętrznych (interfejsy API CRM i dostawcy poczty e-mail) i ręcznie przywróciliśmy brakujące pola.

Całkowity czas: 30 godzin inżynierskich

Dwóch inżynierów, trzy dni. Koszt dla klienta: około $4,500 w opłatach za usługi.

Większym ciosem były jednak straty ponoszone przez klientów. Nieudane powiadomienia doprowadziły do braku płatności i rezygnacji. Klient powiedział nam, że wydał co najmniej $10,000 na zgłoszeniach do pomocy technicznej, rekompensatach SLA i kredytach dobrej woli za ten jeden nieudany skrypt.

Ironiczne jest to, że starszy programista mógł napisać poprawną migrację w ciągu czterech godzin. Ale obietnica szybkości AI kosztowała ich dwa tygodnie sprzątania i utratę reputacji.

Naprawiamy to, co ChatGPT zepsuł - i budujemy to, czego nie mógł.

Przypadek 2: Klient API, który zignorował limity stawek i zepsuł produkcję

Ten pochodził od startupu zajmującego się technologiami prawnymi, który tworzył platformę do zarządzania dokumentami dla firm prawniczych. Jedną z ich podstawowych funkcji była integracja z rządową usługą e-powiadomień - zewnętrznym interfejsem API REST z OAuth 2.0 i ścisłym ograniczeniem szybkości: 50 żądań na minutę, bez wyjątków.

Zamiast przydzielić integrację doświadczonemu programiście backendu, ktoś z zespołu postanowił "prototypować" ją za pomocą ChatGPT. Wrzucili specyfikację OpenAPI, poprosili o klienta Python i otrzymali czysto wyglądający skrypt z requests, logika ponawiania próby przy użyciu tenacity, i odświeżanie tokenów.

Na papierze wyglądał solidnie. Więc go wysłali.

Co poszło nie tak

Początkowo wszystko wydawało się w porządku. Klient poprawnie obsługiwał poszczególne żądania, przechodził uwierzytelnianie, a nawet ponawiał próbę w przypadku niepowodzenia. Jednak podczas rzeczywistego użytkowania, zwłaszcza pod obciążeniem, platforma zaczęła zachowywać się nieprzewidywalnie.

Oto, co faktycznie się wydarzyło:

Brak poszanowania dla limitów stawek. Wygenerowany kod nie odczytał ani nie zinterpretował X-RateLimit-Remaining lub Retry-After nagłówków. Po prostu wysyłał żądania na ślepo.
Ponowne próby pogorszyły sytuację. Gdy zaczęły powracać błędy 429, dekorator tenacity automatycznie ponowił próbę. Bez jittera. Bez kolejkowania. Po prostu zalew kolejnych żądań.
Dostawca API tymczasowo zablokował ich adres IP. Przez 3 godziny nikt na platformie nie mógł zsynchronizować dokumentów. Brak dzienników, brak alertów. Po prostu cicha awaria.

To nie była jednolinijkowa poprawka. To było niezrozumienie tego, jak zachowują się systemy produkcyjne. I jest to świetny przykład tego, czego LLM nie wiedzą; nie dlatego, że są zepsute, ale dlatego, że nie mają świadomości runtime.

Przestań łatać kod wygenerowany przez AI w prod - wprowadź nas, zanim się zepsuje.

Jak to naprawiliśmy

Śledzenie i izolowanie awarii (6 godzin) Dodaliśmy oprogramowanie pośredniczące do inspekcji ruchu wychodzącego i potwierdziliśmy zalew żądań podczas szczytowego wykorzystania. Odtworzyliśmy również awarię w fazie przejściowej, aby w pełni zrozumieć wzorzec wyzwalania.
Przebudowa klienta API (10 godzin) Przepisaliśmy klienta używając httpx.AsyncClient, zaimplementował przepustnicę opartą na semaforach, dodał wykładniczy backoff z jitterem i poprawnie obsługiwał Retry-After i nagłówki ograniczające szybkość.
Test warunków skrajnych i walidacja (6 godzin) Przeprowadziliśmy symulację rzeczywistego użycia z tysiącami jednoczesnych żądań przy użyciu Locust, przetestowaliśmy ograniczanie szybkości w różnych scenariuszach burst i potwierdziliśmy zero 429 przy stałym obciążeniu.
Dodanie monitorowania i alertów (4 godziny) Skonfigurowaliśmy niestandardowe wskaźniki Prometheus do śledzenia użycia API na minutę i dodaliśmy alerty, aby powiadomić zespół, jeśli zbliżali się do progów szybkości.

Całkowity czas: 26 godzin

Dwóch inżynierów, rozłożone na dwa i pół dnia. Koszt dla klienta: około $3,900.

Większym problemem jest to, że ich największy klient - firma prawnicza, której zależy na czasie - przegapił dwa okna składania wniosków sądowych z powodu awarii. Klient musiał naprawić szkody i zaoferować zniżkę, aby utrzymać konto.

Wszystko dlatego, że model językowy nie rozumiał różnicy między "kodem roboczym" a "kodem gotowym do produkcji". I tak po prostu, kolejna warstwa długu technicznego AI została po cichu dodana do stosu.

Dlaczego tak się dzieje?

Przerażające nie jest to, że te rzeczy idą źle. Chodzi o to, jak przewidywalne staje się to wszystko.

Każdy z tych incydentów przebiega według tego samego schematu. Deweloper prosi ChatGPT o fragment kodu. Zwraca coś, co działa wystarczająco dobrze, by nie wyrzucać błędów. Podłączają go do systemu, być może trochę go czyszczą i wysyłają, zakładając, że jeśli kompiluje się i działa, to musi być bezpieczny.

Jest jednak pewien haczyk: Duże modele językowe nie znają Twojego systemu.
Nie wiedzą, w jaki sposób Twoje usługi współdziałają.
Nie znają budżetu na opóźnienia, potoku wdrożeń, konfiguracji obserwowalności ani wzorców ruchu produkcyjnego.

Generują najbardziej prawdopodobny kod na podstawie wzorców w danych treningowych. To wszystko. Nie ma żadnej świadomości. Żadnych gwarancji. Brak intuicji w projektowaniu systemu.

Wyniki często to odzwierciedlają:

Kod, który działa raz, ale zawodzi pod obciążeniem
Brak programowania defensywnego, brak zabezpieczeń przed awarią
Słabe zrozumienie rzeczywistych ograniczeń, takich jak limity szybkości, limity czasu lub ewentualna spójność.
Absolutnie zerowe wyczucie intencji architektonicznych

Co gorsza, kod wygląda poprawnie. Jest składniowo czysty. Przechodzi lintery. Może być nawet objęty podstawowym testem. Ale brakuje mu jednej rzeczy, która ma znaczenie: kontekstu.

Dlatego te błędy nie pojawiają się od razu. Czekają na wdrożenia w piątek wieczorem, na okna o dużym natężeniu ruchu, na rzadkie przypadki brzegowe. Taka jest natura długu technicznego AI - jest niewidoczny, dopóki nie zepsuje czegoś krytycznego.

Kiedy AI faktycznie pomaga

Jak wspomnieliśmy wcześniej, my również używamy AI. Prawie każdy inżynier w naszym zespole ma lokalnie uruchomioną konfigurację podobną do Copilota. Jest szybki, pomocny i, szczerze mówiąc, świetny sposób na pominięcie nudnych części.

Ale oto różnica: nic nie trafia do głównej gałęzi bez przejścia przez starszego inżyniera, a w większości przypadków przez potok CI, który wie, czego szukać.

Absolwenci studiów LLM są w tym świetni:

szablon rusztowania dla nowych usług lub punktów końcowych API,
generowanie pokrycia testowego dla istniejącej logiki,
pomoc w powtarzalnym refaktoryzowaniu dużych baz kodu,
tłumaczenie prostych skryptów powłoki na szablony infrastruktury jako kodu,
lub nawet porównując podejścia algorytmiczne, które już rozumiemy.

Czym są nie dobry w projektowaniu. Lub kontekst. Lub bezpieczne ustawienia domyślne.

Właśnie dlatego stworzyliśmy nasze przepływy pracy, aby traktować dane wyjściowe LLM jak sugestie, a nie źródło prawdy. Oto jak to wygląda w praktyce:

Oznaczamy wszystkie zatwierdzenia wygenerowane przez AI, aby można je było łatwo śledzić i przeglądać.
Nasi edytorzy mają wbudowane podpowiedzi, ale z wymuszonymi hakami przed zatwierdzeniem, które blokują wszystko bez testów lub dokumentacji.
Nasz CI zawiera reguły analizy statycznej, które oznaczają niebezpieczne wzorce, które widzieliśmy wcześniej w LLM: rzeczy takie jak niezabezpieczone ponowienia, nieobjęte limitem czasu timeouty, naiwne parsowanie JSON lub niebezpieczna obsługa SQL.
Każdy pull request z kodem wygenerowanym przez LLM przechodzi obowiązkową weryfikację przez człowieka, zwykle przez kogoś wyższego rangą, kto rozumie logikę domeny i powierzchnię ryzyka.

Używany prawidłowo, oszczędza czas. Używany na ślepo jest bombą zegarową.

Co zalecamy CTO

Nie jesteśmy tu po to, by mówić ci, byś zakazał narzędzi AI. Ten statek już odpłynął.

Ale dać modelowi językowemu dostęp do commitów? To tylko proszenie się o kłopoty.

Oto, co zalecamy zamiast tego:

1. Traktuj LLM jak narzędzia, a nie inżynierów

Pozwól im pomóc z powtarzalnym kodem. Niech proponują rozwiązania. Ale nie ufaj im w podejmowaniu krytycznych decyzji. Każdy kod wygenerowany przez AI powinien zostać sprawdzony przez starszego inżyniera, bez wyjątków.

2. Możliwość śledzenia kodu generowanego przez LLM

Niezależnie od tego, czy są to tagi commit, metadane czy komentarze w kodzie, wyjaśnić, które części pochodzą z AI. Ułatwia to późniejszy audyt, debugowanie i zrozumienie profilu ryzyka.

3. Zdefiniowanie polityki generowania

Zdecydujcie jako zespół, gdzie dopuszczalne jest korzystanie z LLM, a gdzie nie. Boilerplate? Jasne. Przepływy autoryzacji? Być może. Systemy transakcyjne? Absolutnie nie bez weryfikacji. Jasno określ zasady i częścią standardów inżynieryjnych.

4. Dodaj monitorowanie na poziomie DevOps

Jeśli pozwalasz kodowi wygenerowanemu przez AI dotknąć produkcji, musisz założyć, że coś w końcu się zepsuje. Dodaj kontrole syntetyczne. Monitory ograniczające szybkość. Śledzenie zależności. Uczyń niewidzialne widzialnym, zwłaszcza gdy oryginalny autor nie jest człowiekiem.

5. Budowanie pod kątem odzyskiwalności

Największe awarie spowodowane przez AI, jakie widzieliśmy, nie wynikały ze "złego" kodu. Wynikały one z cichych błędów - brakujących danych, uszkodzonych kolejek, burz ponownych prób - które pozostawały niewykryte przez wiele godzin. Zainwestuj w obserwowalność, logikę awaryjną i wycofywanie. Zwłaszcza jeśli pozwalasz ChatGPT pisać migracje.

Krótko mówiąc, AI może zaoszczędzić czas zespołu, ale nie może przejąć odpowiedzialności.

To wciąż ludzka praca.

Przemyślenia końcowe: AI ≠ inżynierowie oprogramowania

AI może pomóc ci poruszać się szybciej. Ale nie może myśleć za ciebie.

Nie rozumie twojej architektury. Nie wie, co oznacza "zrobione" w danym kontekście. I zdecydowanie nie dba o to, czy potok danych po cichu zepsuje się w piątek wieczorem.

Dlatego jako CTO musimy skupić się na odporności systemu, a nie tylko na szybkości.

Kuszące jest, aby pozwolić AI zająć się nudnymi częściami. I czasami jest to w porządku. Ale każdy skrót wiąże się z kompromisem. Kiedy kod wygenerowany przez AI prześlizguje się bez kontroli, często staje się długiem technicznym AI. Takim, którego nie widać, dopóki zespół operacyjny nie zacznie gaszenia pożarów w produkcji.

Jeśli już napotkałeś tę ścianę, nie jesteś sam. Pomogliśmy zespołom odzyskać sprawność we wszystkim, od zepsutych migracji po katastrofy API. Nie tylko refaktoryzujemy kod. Pomagamy refaktoryzować myślenie, które za nim stoi.

Ponieważ ostatecznie to właśnie sprawia, że systemy są niezawodne.

Philip Tikhanovich

Kierownik działu Python, Big Data, ML/DS/AI

Philip skupia się na wszystkich kwestiach związanych z danymi i AI. To on zadaje właściwe pytania na wczesnym etapie, wyznacza silną wizję techniczną i upewnia się, że nie tylko budujemy inteligentne systemy - budujemy właściwe, dla prawdziwej wartości biznesowej.

Czytaj więcej

Spis treści

Skontaktuj się z nami

Umów się na rozmowę lub wypełnij poniższy formularz, a my skontaktujemy się z Tobą po przetworzeniu Twojego zgłoszenia.

Nazwa

Firma

E-mail

Telefon

Wiadomość

Wyślij nam wiadomość głosową

Załącz dokumenty

Prześlij plik

Można załączyć 1 plik o rozmiarze do 2 MB. Prawidłowe formaty plików: pdf, jpg, jpeg, png.

Klikając przycisk Wyślij, użytkownik wyraża zgodę na przetwarzanie przez Innowise jego danych osobowych zgodnie z naszą polityką prywatności. Politykę Prywatności w celu dostarczenia użytkownikowi odpowiednich informacji. Podając swój numer telefonu, użytkownik wyraża zgodę na kontaktowanie się z nim za pośrednictwem połączeń głosowych, wiadomości SMS i aplikacji do przesyłania wiadomości. Mogą obowiązywać opłaty za połączenia, wiadomości i transmisję danych.

Możesz również przesłać nam swoje zapytanie
na adres contact@innowise.com

Co dalej?

Po otrzymaniu i przetworzeniu zgłoszenia skontaktujemy się z Tobą, aby szczegółowo opisać projektu i podpisać umowę NDA w celu zapewnienia poufności.

Po zapoznaniu się z Twoimi potrzebami i oczekiwaniami, nasz zespół opracuje projekt wraz z zakresem prac, wielkością zespołu, czasem i szacunkowymi kosztami.

Zorganizujemy spotkanie w celu omówienia oferty i ustalenia szczegółów.

Na koniec podpiszemy umowę, błyskawicznie rozpoczynając pracę nad projektem.