AI doprowadzi Cię do 80% w rekordowym tempie. Ale te ostatnie 20% to miejsce, gdzie kryje się prawdziwa inżynieria — i gdzie większość projektów umiera.
Buduję aplikacje od ponad 10 lat. Ponad 60 wdrożonych projektów — no-code i wygenerowanych przez AI — w większości akcje ratunkowe. Założyciele, którzy sami zbudowali aplikację albo kazali AI wygenerować całość, przychodzili do mnie z tym samym problemem: „Na demo działało, ale na produkcji się sypie.”
I tu większość ludzi się myli. Widzą rozwiązanie złożonego problemu gotowe w 90% i myślą, że to 90% roboty. A to zwykle najwyżej połowa. Pewnie nawet mniej. Bo to nie jest ten sam rodzaj pracy. Te pierwsze 80% to prototyp. Te ostatnie 20% to inżynieria — bezpieczeństwo, obsługa błędów, skalowalność, testy, wdrożenie, monitoring. Wszystko to, co sprawia, że aplikacja przeżywa zderzenie z prawdziwym użytkownikiem.
Mamy tę dziwną modę na posty w stylu „wypuściłem to w weekend”, które całkowicie pomijają moment, w którym trzeba aplikację porządnie wzmocnić, zanim sięgną po nią prawdziwi ludzie. Nikt nie mówi o konfiguracji HTTPS, o nagłówkach bezpieczeństwa ani o tym, co się dzieje, kiedy dwa procesy próbują zapisać ten sam rekord. A to właśnie tam żyją prawdziwe problemy.
Ten artykuł jest właśnie o tej części. O konkretnych schematach awarii, które widzę w każdym projekcie generowanym przez AI, i o tym, jak je naprawić — krok po kroku, bez teorii.
Zanim przejdziemy do konkretnych bugów, porozmawiajmy o matematyce. Bo to właśnie tutaj rozsypuje się złudzenie wokół aplikacji generowanych przez AI.
Załóżmy, że każdy krok w Twoim workflow ma 95% dokładności. Brzmi nieźle, prawda? A i tak jest to bardzo optymistyczne założenie dla większości komponentów wygenerowanych przez AI. Ale popatrz, co się dzieje, kiedy te kroki zaczynają się nawarstwiać:
Dwadzieścia kroków i Twoja „rewolucyjna automatyzacja” częściej zawodzi, niż działa. To nie jest problem modelu AI. To jest problem złożoności systemu i żadne, nawet najlepsze prompty tego nie naprawią.
Agenty, które naprawdę działają na produkcji? Robią jedną nudną rzecz naprawdę dobrze. Nie „poruszają się autonomicznie po złożonych workflowach” — przetwarzają fakturę albo streszczają wątek e-maili. Zespoły, którym konsekwentnie udaje się domknąć całość, zawężają agenta do jednego kompletnego podprocesu, zamiast próbować zautomatyzować cały workflow.
Prawdziwym wąskim gardłem nie jest już model AI. To jest przepaść między myśleniem a działaniem. Dobry agent musi faktycznie wykonywać zadania od początku do końca, a nie tylko generować tekst.
Po naprawieniu dziesiątek projektów wygenerowanych przez AI widzę wciąż ten sam schemat. To nie są przypadkowe bugi. To systemowe braki, które wynikają z tego, jak AI pisze kod — buduje wyłącznie wariant, w którym wszystko idzie zgodnie z planem, i kompletnie ignoruje to, co może pójść nie tak.
Oto lista, którą widzę praktycznie w każdym projekcie:
Każdy z tych problemów jest trywialny do naprawienia, jeśli wiesz, że istnieje. Problem w tym, że AI ich nie widzi, bo z perspektywy AI — kod „działa”.
Większości awarii nie powodował model. Powodowały je brakujące kontrakty. Brak jasnej definicji tego, co agent ma prawo robić, jak wygląda poprawny output i jaki stan ma zachowywać.
Kiedy coś idzie nie tak, ludzie zaczynają poprawiać prompty zamiast naprawiać strukturę. To tylko maskuje problem. Tydzień później wypluwa coś innego, bo podstawowy problem — brak kontraktów — jest nadal taki sam.
Większość projektów agentowych buduje się wokół tego, co AI potrafi zrobić, a nie tego, czego workflow faktycznie wymaga od początku do końca. A to dokładnie na odwrót. Solidny agent zaczyna od:
Dopiero potem myślisz o UI i integracjach.
Agenty nie uczą się na własnych błędach. Nawet ich nie pamiętają, chyba że sam im to zapewnisz. Każda rozmowa to osobna, odizolowana bańka. To znaczy, że każda sesja zaczyna się od zera — te same błędy, te same naiwne założenia, te same przeoczone edge case'y. Jeśli nie zapiszesz wniosków z jednej sesji i nie przekażesz ich następnej, AI będzie powtarzać te same problemy w nieskończoność.
Działa na localhost. Pięknie. Ale co się dzieje, kiedy wrzucisz to na serwer?
Narzędzia AI świetnie sprawdzają się w prototypowaniu, ale między demo a prawdziwym produktem jest przepaść. Oto lista problemów, które wychodzą na jaw w chwili, gdy z Twojej aplikacji zaczyna korzystać ktoś inny niż Ty:
Frontend na jednej domenie, backend na drugiej, brak odpowiednich nagłówków. Na localhoście działa, bo przeglądarka jest pobłażliwa. Na produkcji? Błąd u każdego użytkownika.
Zapytania N+1 do bazy danych, brak paginacji, wczytywanie całej tabeli do pamięci. Przy 5 testowych rekordach tego nie zauważysz. Przy 5000 — strona ładuje się 30 sekund, a serwer zjada cały dostępny RAM.
AI nie myśli o tym, co się dzieje, kiedy użytkownik otwiera dwie karty, traci połączenie albo wraca po godzinie. Sesje wygasają? Token się odświeża? Kto obsługuje conflict resolution? Nikt, bo AI nie pomyślało o tym scenariuszu.
Brak Dockerfile. Brak zmiennych środowiskowych — wszystko zahardkodowane. Brak CI/CD. Brak health checka. Brak strategii rollbacku. Brak autoskalowania. Jeden serwer, zero redundancji. Jeśli padnie — padnie wszystko.
Większość platform typu drag-and-drop rozwiązuje kwestię łączności. To niezawodność — obsługa częściowych awarii, retry'e, edge case'y — jest tym, na czym wszystko się sypie na produkcji.
Nie musisz wyrzucać kodu wygenerowanego przez AI. Musisz go wzmocnić. Oto konkretne kroki, nie teoria:
To jest rada, którą daję każdemu. Jeśli Twoja aplikacja wydaje się krucha, zacznij od tych dwóch rzeczy. Row-level security (RLS) w Supabase, polityki w Postgresie albo middleware sprawdzający, czy użytkownik ma prawo widzieć dany rekord. Potem normalizacja bazy — powiązane tabele zamiast danych powielanych przy każdym rekordzie.
Każda walidacja, która działa wyłącznie we frontendzie, to proszenie się o nadużycia. Ceny, rabaty, uprawnienia, limity — wszystko po stronie serwera. Frontend to tylko warstwa prezentacji. Jeśli ktoś może otworzyć DevTools i zmienić cenę produktu — masz problem.
Każde wywołanie API może się nie powieść. Każda płatność może zostać odrzucona. Każde połączenie z bazą danych może się zerwać. AI generuje kod, który zakłada, że nic nigdy się nie psuje. Dodaj try/catch z sensownymi komunikatami. Dodaj ponawianie prób z exponential backoff. Dodaj fallbacki — co się dzieje, kiedy główna usługa padnie?
Zmienne środowiskowe, nie zahardkodowane stringi. AWS Secrets Manager, Doppler, albo chociaż .env z prawidłowym .gitignore. Jeśli Twój klucz API jest w kodzie frontendowym — jest publiczny. Nie ma wyjątków.
GitHub Actions, GitLab CI, Bitbucket Pipelines — nie ma znaczenia które. Ważne, że każdy deploy przechodzi przez: lint, testy, build, deploy na staging, potem na produkcję. Zero ręcznego wrzucania plików przez FTP.
Sentry do błędów frontendu i backendu. CloudWatch albo Datadog do metryk serwerowych. Alerty na Slacku albo na mailu, gdy error rate przekroczy próg. Jeśli nie wiesz, że coś się popsuło — to tak, jakby się nie popsuło. Do momentu, aż powie Ci o tym klient.
Kiedy coś idzie nie tak, ludzie zaczynają poprawiać prompty zamiast naprawiać strukturę. To jak malowanie domu, który ma pęknięty fundament. Wygląda lepiej przez tydzień. Potem pęknięcia wracają.
Przejdź przez to przed każdym deployem. Każdy punkt to coś, czego brakowało w prawdziwych projektach, które naprawiałem.
To dokładnie to, co naprawiam. Porozmawiajmy — sprawdzę, co trzeba wzmocnić, i powiem Ci, ile to zajmie.
Zarezerwuj bezpłatną rozmowę →