Co tak naprawdę psuje się w środku MVP, które pierwszego dnia „po prostu działało".
Zapytaj nietechnicznego założyciela, który zbudował swoje MVP z asystentem AI, jak poszło, a usłyszysz jakąś wersję tej samej historii: na początku zaskakująco szybko, potem coraz dziwniej. Funkcja, którą kiedyś wdrażało się w godzinę, zajmuje teraz cały dzień. Klient zgłasza coś, co w ogóle nie powinno się wydarzyć. AI wciąż chętnie dopisuje kolejny kod — ale każda nowa rzecz, którą dodaje, psuje coś, co działało wcześniej.
To nie jest argument przeciwko programowaniu z pomocą AI. To argument za tym, by zrozumieć, w jaki sposób taki kod zawodzi — żebyś wyłapał problemy, zanim trafią na nich Twoi klienci.
Asystenci AI zwykle nie piszą zepsutego kodu. Piszą kod, który wygląda wiarygodnie. Różnica wychodzi na jaw dopiero pod obciążeniem: prawdziwych użytkowników, prawdziwych danych, prawdziwej skali, prawdziwego bezpieczeństwa. A wtedy kod nadal wygląda dobrze — i właśnie dlatego znalezienie błędu zajmuje więcej czasu.
Większość założycieli — nawet ci, którzy powinni wiedzieć lepiej — po cichu zakłada:
Jeśli działa i przechodzi happy path, to znaczy, że AI zrobiło to dobrze.
W każdym innym kontekście to rozsądne. Błąd kompilatora, wywrócenie się aplikacji w trakcie działania, oblany test — to uczciwe sygnały. Kod generowany przez LLM zwodzi w bardzo konkretny sposób: jest uczony tak, by tworzyć coś, co wygląda jak sprawdzony kod, bo właśnie takie przykłady są w jego danych treningowych. A wyglądać jak sprawdzony kod i być sprawdzonym kodem to dwie różne rzeczy.
To problemy, które wychodzą podczas audytu MVP zbudowanego głównie z pomocą AI. Żaden z nich nie jest egzotyczny. I każdy siedzi cicho — aż przestaje.
AI pisze logowanie, rejestrację, reset hasła, obsługę sesji. UX wygląda świetnie. Ale gdzieś w środku procesu brakuje jednego sprawdzenia — tokena, który nie jest weryfikowany na newralgicznym endpoincie, cookie bez flagi HttpOnly, resetu hasła, który nie unieważnia starej sesji. Każdy z tych braków z osobna to poprawka na jedną linijkę. Razem oznaczają, że ktoś wystarczająco zdeterminowany może podszyć się pod dowolnego użytkownika.
Założyciel zwykle o tym nie wie, bo przecież autentykacja działa. Da się zalogować. Da się wylogować. Dziura jest w tym, co dzieje się pomiędzy.
AI projektuje schemat bazy na podstawie promptu, który dostało. A ten prompt opisywał produkt taki, jaki jest dzisiaj — i schemat odwzorowuje właśnie ten stan. Gdy trzy miesiące później założyciel próbuje dodać „jeszcze jedną rzecz", o którą poprosił klient, okazuje się, że pierwotna struktura tabel opierała się na założeniach, które już nie są aktualne — jeden użytkownik na konto, jeden produkt na zamówienie, jedna waluta, jeden język.
Migrację zawsze da się przeprowadzić. Ale migracja działającego produktu, w którym są już prawdziwe dane, to zupełne przeciwieństwo „dwugodzinnej funkcji od AI", do której założyciel zdążył się przyzwyczaić.
LLM-y uwielbiają pisać funkcje pomocnicze. Z nazwami w stylu getUserOrdersByStatusAndDate. Wyglądają, jakby dało się ich używać wielokrotnie. Tak nie jest — obsługują wyłącznie dokładnie tę kombinację, o którą poprosił założyciel. Kiedy następnym razem ktoś będzie potrzebował zamówień według statusu, ale już bez daty, AI napisze drugą, niemal identyczną funkcję. Po kilku miesiącach kod zamienia się w muzeum prawie-duplikatów, z których każdy różni się drobnym szczegółem.
Tu zagrożeniem nie jest wywrócenie się aplikacji. Problem w tym, że poprawka w jednej kopii nie naprawia pozostałych, a założyciel nie ma jak sprawdzić, która kopia obsługuje na produkcji którą funkcję.
Poproś AI, żeby uodporniło kod, a ono ochoczo poopakowuje wszystko w bloki try/except, które po cichu połykają błędy. Awarie, które powinny kogoś poderwać na nogi, lądują w konsoli — albo, co gorsza, nie zostają zalogowane w ogóle. Dane, które powinny natychmiast zatrzymać przetwarzanie, po cichu zmieniają się w null i lecą dalej w głąb systemu. Produkt „nigdy się nie wywraca". Tyle że nigdy też nie daje znać, że coś jest nie tak.
Stripe, SendGrid, Supabase, OpenAI — asystenci AI świetnie radzą sobie z postawieniem pierwszej integracji. Ale ponawianie żądań, idempotencja, weryfikacja webhooków, limitowanie zapytań, obsługa błędów na wypadek awarii dostawcy — to wszystko zwykle wypada, bo prompt o to nie prosił. Założyciel dowiaduje się o tym dopiero przy pierwszym podwójnym obciążeniu karty, pierwszym niewysłanym mailu rejestracyjnym albo pierwszej awarii, która rozlewa się po całym produkcie, bo zacięła się jedna usługa, od której produkt zależy.
Żeby MVP zbudowane przez AI było bezpieczne, wcale nie musisz go przepisywać. Potrzebujesz stałego schematu przeglądów — krótkiej listy pytań, którą ktoś o odpowiednich kompetencjach technicznych przerabia co kilka tygodni, a do tego raz przed każdym ważnym wydarzeniem z klientem czy inwestorem.
Jak to wygląda w praktyce:
To nie jest pełny audyt za każdym razem. To rutyna — odpowiednik wymiany oleju w samochodzie, którym jeździsz codziennie. Notorycznie pomijana, prowadzi dokładnie do tego scenariusza, w którym ląduje większość MVP od AI: jest OK, jest OK, jest OK, jest katastrofa.
Założyciel zbudował narzędzie B2B z asystentem AI w trzy weekendy. W sześć tygodni zdobył pięciu płacących klientów. W jedenastym tygodniu jeden z nich — przez przypadek, ze starej zakładki w przeglądarce — wszedł na dashboard innego klienta. Poprawka zajęła dwie linijki. Prawdziwą szkodą był e-mail, który założyciel musiał potem wysłać.
Przegląd, który by to wychwycił, zająłby dziewięćdziesiąt minut i kosztował mniej niż miesięczny budżet założyciela na kawę.
MVP generowane przez AI to nie jest zły pomysł. To świetny sposób, żeby tanio sprawdzić, czy produkt trafia w rynek. Ale psują się w bardzo konkretny sposób: kod, który wygląda wiarygodnie, ale rozsypuje się w realnych warunkach. Koszt lekkiego, regularnego przeglądu jest znikomy. Koszt pierwszego incydentu, którego dało się uniknąć — już nie.
Jeśli zbudowałeś swoje MVP głównie z pomocą AI, to najcenniejsze, co możesz zrobić w tym miesiącu, to dać je do przeczytania komuś, kto nie jest AI — i nie jest Tobą.
Rozmowa wstępna jest bezpłatna. 30 minut. Powiem Ci szczerze, czy audyt albo naprawa pasują do Twojej sytuacji — albo czy żadne z nich.
Umów rozmowę zapoznawczą →