AI doprowadzi Cię do 80% w rekordowym tempie. Ale te ostatnie 20% to miejsce, gdzie mieszka prawdziwa inżynieria — i gdzie większość projektów umiera.
Budujemy aplikacje od ponad 10 lat. Ponad 60 projektów no-code i AI-generated — większość z nich to były akcje ratunkowe. Founderzy, którzy sami to zbudowali albo pozwolili AI wygenerować całość, przychodzili z tym samym problemem: „Działało na demo, ale na produkcji się sypie.”
I tu jest sedno sprawy. Ludzie widzą 90-procentowe rozwiązanie złożonego problemu i myślą, że to 90% roboty. W rzeczywistości to 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, deployment, monitoring. Wszystko to, co sprawia, że aplikacja przeżywa spotkanie z prawdziwym użytkownikiem.
Jest taka dziwna kultura postów „wysłałem to w weekend”, która całkowicie pomija część, w której musisz to zahartować, zanim prawdziwi ludzie zaczną tego używać. Nikt nie mówi o konfiguracji HTTPS, o zabezpieczeniach, 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 o tej części. O konkretnych wzorcach awarii, które widzę w każdym AI-generowanym projekcie, i o tym, jak je naprawić — krok po kroku, bez teorii.
Zanim przejdziemy do konkretnych bugów, porozmawiajmy o matematyce. Bo to tutaj iluzja AI-generowanych aplikacji się rozpada.
Załóżmy, że każdy krok w Twoim workflow ma 95% dokładności. Brzmi dobrze, prawda? To jest naprawdę hojna ocena dla większości AI-generowanych komponentów. Ale popatrzmy, co się dzieje, kiedy te kroki się składają:
Dwadzieścia kroków i Twoja „rewolucyjna automatyzacja” zawodzi częściej niż się udaje. To nie jest problem modelu AI. To jest problem złożoności systemu, i żadna ilość lepszych promptów tego nie naprawi.
Agenty, które faktycznie działają w produkcji? Robią jedną nudną rzecz naprawdę dobrze. Nie „autonomicznie nawigują złożonych workflowów” — parsują fakturę albo podsumowują wątek e-maili. Zespoły, które zamykają pętlę konsekwentnie, ograniczają agenta do jednego pełnego podprocesu zamiast próbować automatyzować 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 AI-generowanych projektów widzę ten sam wzorzec. To nie są losowe bugi. To są systemowe braki, które wynikają z tego, jak AI generuje kod — działa na szczęśliwą ścieżkę i kompletnie ignoruje wszystko, 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 „dziala”.
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 jest projektowana wokół tego, co AI potrafi zrobić, a nie tego, czego workflow faktycznie potrzebuje od początku do końca. To jest dokładnie odwrotnie. 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 to wbudujesz. Każda konwersacja to izolowany bąbek. To znaczy, że każda sesja zaczyna się od zera — te same błędy, te same naiwne założenia, te same brakujące edge case'y. Jeśli nie zapiszesz lekcji 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?
AI narzędzia są świetne do prototypowania, ale istnieje przepaść między demo a prawdziwym produktem. To jest lista problemów, które pojawiają się w momencie, kiedy ktoś inny niż Ty zaczyna używać Twojej aplikacji:
Frontend na jednej domenie, backend na drugiej, brak odpowiednich headerów. Na localhost działa, bo przeglądarka odpuszcza. Na produkcji? Błąd na każdym użytkowniku.
Zapytania N+1 do bazy danych, brak paginacji, ładowanie całej tabeli do pamięci. Przy 5 rekordach testowych tego nie zauważyć. Przy 5000 — strona ładuje się 30 sekund, a serwer zjada cały 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ść drag-and-drop platform rozwiązuje łączność. Niezawodność — obsługa częściowych awarii, retry'e, edge case'y — to jest miejsce, gdzie robi się bałagan na produkcji.
Nie musisz wyrzucać AI-generowanego kodu. 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. Row-level security (RLS) w Supabase, Postgres policies, albo middleware sprawdzający, czy użytkownik ma prawo widzieć dany rekord. Potem normalizacja bazy — linkowane tabele zamiast danych powielonych na każdym rekordzie.
Każda walidacja, która jest tylko we frontendzie, to zaproszenie do nadużywania. 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 API call może się nie udać. 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 retry z exponential backoff. Dodaj fallbacki — jeśli główna usługa padnie, co się dzieje?
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 na błędy frontendowe i backendowe. CloudWatch albo Datadog na metryki serwerowe. Alerty na Slacku albo e-mailu, kiedy error rate przekroczy próg. Jeśli nie wiesz, że coś się popsuło — to tak, jakby się nie popsuło. Do momentu, aż klient Ci powie.
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ś, co widziałem brakującego w prawdziwych projektach.
To dokładnie to, co naprawiam. Porozmawiajmy — sprawdzę, co trzeba wzmocnić, i powiem Ci, ile to zajmie.
Zarezerwuj bezpłatną rozmowę →