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

Philip Tihonovich

29 maja 2025 r. 10 minut

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 in service fees.

But the bigger hit came from customer fallout. Failed notifications led to missed payments and churn. The client told us they spent at least $10,000 on support tickets, SLA compensation, and goodwill credits over that one botched script.

The ironic thing is that a senior developer could’ve written the correct migration in maybe four hours. But the promise of AI speed ended up costing them two weeks of cleanup and reputation damage.

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?

The scary part isn’t that these things go wrong. It’s how predictable it’s all becoming.

Every one of these incidents follows the same pattern. A developer asks ChatGPT for a code snippet. It returns something that works just well enough not to throw errors. They wire it into the system, maybe clean it up a little, and ship it, assuming that if it compiles and runs, it must be safe.

But here’s the catch: Large language models don’t know your system.
They don’t know how your services interact.
They don’t know your latency budget, your deployment pipeline, your observability setup, or your production traffic patterns.

They generate the most likely-looking code based on patterns in their training data. That’s all. There’s no awareness. No guarantees. No intuition for system design.

And the output often reflects that:

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

As we mentioned earlier, we use AI too. Pretty much every engineer on our team has a Copilot-like setup running locally. It’s fast, helpful, and honestly, a great way to skip the boring parts.

But here’s the difference: nothing makes it into the main branch without going through a senior engineer, and in most cases, a CI pipeline that knows what to look for.

LLMs are great at:

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

We’re not here to tell you to ban AI tools. That ship has sailed.

But giving a language model commit access? That’s just asking for trouble.

Here’s what we recommend instead:

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 can help you move faster. But it can’t think for you.

It doesn’t understand your architecture. It doesn’t know what “done” means in your context. And it definitely doesn’t care if your data pipeline silently breaks on a Friday night.

That’s why, as CTOs, we need to stay focused on system resilience, not just speed.

It’s tempting to let AI handle the boring parts. And sometimes that’s fine. But every shortcut comes with a tradeoff. When AI-generated code slips through unchecked, it often becomes AI technical debt. The kind you don’t see until your ops team is firefighting in production.

If you’ve already run into that wall, you’re not alone. We’ve helped teams recover from everything from broken migrations to API disasters. We don’t just refactor code. We help refactor the thinking behind it.

Because in the end, that’s what actually makes systems reliable.

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

Napisz do nas

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.