Co naprawdę idzie nie tak wewnątrz MVP, które „po prostu działały" pierwszego dnia.
Zapytaj nietechnicznego założyciela, który zbudował swoje MVP z asystentem AI, jak poszło, a usłyszysz wersję tej samej historii: na początku zaskakująco szybko, potem coraz dziwniej. Funkcja, która dostarczała się w godzinę, zajmuje dzień. Klient zgłasza coś, co nie powinno być możliwe. AI nadal chętnie pisze więcej kodu — ale każda nowa rzecz, którą dodaje, wydaje się psuć coś starszego.
To nie jest argument przeciwko kodowaniu z AI. To argument za zrozumieniem, jak to zazwyczaj zawodzi, żebyś mógł wyłapać awarie, zanim znajdą Twoich klientów.
Asystenci AI zwykle nie piszą zepsutego kodu. Piszą prawdopodobny kod. Różnica ujawnia się dopiero pod presją: realnymi użytkownikami, realnymi danymi, realną skalą, realnym bezpieczeństwem. Do tego czasu kod wygląda dobrze — i właśnie dlatego debugowanie zajmuje dłużej.
Większość założycieli, w tym tych, którzy wiedzą lepiej, cicho zakłada:
Jeśli działa i przechodzi happy path, to AI zrobił to dobrze.
To rozsądne w każdym innym kontekście. Błąd kompilatora, runtime crash, failing test — to uczciwe sygnały. Kod generowany przez LLM jest nieuczciwy w specyficzny sposób: jest trenowany, by produkować output, który wygląda jak sprawdzony kod, bo to jest w jego danych treningowych. Wyglądać jak sprawdzony kod i być sprawdzonym kodem — to nie to samo.
To są problemy, które pojawiają się, gdy audyt trafia na MVP zbudowane głównie ze wsparciem AI. Żaden z nich nie jest egzotyczny. Wszystkie są ciche, dopóki nie są.
AI pisze login, rejestrację, reset hasła, obsługę sesji. UX wygląda świetnie. Potem gdzieś w środku flow brakuje sprawdzenia — token, który nie jest walidowany na krytycznym endpoincie, cookie bez flagi HttpOnly, reset hasła, który nie unieważnia starej sesji. Każdy z tych problemów to jednowierszowa poprawka w izolacji. Razem oznaczają, że każda zdeterminowana osoba może podszyć się pod użytkownika.
Założyciel zwykle nie wie, że to się dzieje, bo autentykacja działa. Można się zalogować. Można się wylogować. Dziura jest w tym, co dzieje się pomiędzy.
AI projektuje schemat na podstawie promptu, który dostał. Ten prompt opisywał produkt dzisiaj. Schemat odzwierciedla dzisiaj. Gdy założyciel próbuje dodać „jeszcze jedną rzecz", o którą poprosił klient trzy miesiące później, okazuje się, że oryginalna struktura tabeli zakładała rzeczy, które już nie są prawdziwe — jeden użytkownik na konto, jeden produkt na zamówienie, jedna waluta, jeden język.
Zawsze można zrobić migrację. Ale migracja dla żywego produktu z danymi to przeciwieństwo „dwugodzinnej funkcji AI", do której założyciel się przyzwyczaił.
LLMy uwielbiają pisać helpery. Funkcje z nazwami typu getUserOrdersByStatusAndDate. Wyglądają na reużywalne. Nie są — obsługują tylko dokładną kombinację, o którą poprosił założyciel. Następnym razem, gdy ktoś potrzebuje zamówień według statusu bez według daty, AI pisze drugą niemal identyczną funkcję. Po kilku miesiącach kod to muzeum prawie-duplikatów, każdy subtelnie inny.
Powierzchnia błędu to nie crash. To fakt, że poprawka w jednej kopii nie naprawia innych, a założyciel nie ma sposobu, by dowiedzieć się, która kopia działa na produkcji dla której funkcji.
Poproś AI, by kod był bardziej odporny, a chętnie owinie rzeczy w bloki try/except, które cicho połykają błędy. Awarie, które powinny kogoś zawiadomić, trafiają do konsoli — albo gorzej, w ogóle nie są logowane. Dane, które powinny spowodować twardy stop, cicho stają się null i przepływają dalej. Produkt „nigdy się nie crashuje". Ale też nigdy nie mówi Ci, że coś jest nie tak.
Stripe, SendGrid, Supabase, OpenAI — asystenci AI są świetni w szkielecie pierwszej integracji. Ale retry, idempotentność, weryfikacja webhooków, rate limiting, obsługa błędów gdy dostawca jest down — to są rzeczy pomijane, bo prompt o nie nie pytał. Założyciel dowiaduje się dopiero przy pierwszym podwójnym obciążeniu karty, pierwszym przegapionym mailu rejestracyjnym, albo pierwszej awarii kaskadującej przez produkt, bo jedna usługa upstream zawiodła.
Nie musisz przepisywać MVP generowanego przez AI, by było bezpieczne. Potrzebujesz wzorca przeglądu — krótkiej listy pytań, które ktoś technicznie kompetentny przechodzi co kilka tygodni, plus raz przed każdym znaczącym kamieniem milowym klienta lub inwestora.
Praktyczny rytm:
To nie jest pełny audyt za każdym razem. To rutyna — odpowiednik wymiany oleju w samochodzie, którym jeździsz codziennie. Pomijana rutynowo, produkuje dokładnie ten tryb awarii, w którym kończy większość MVP generowanych przez AI: OK, OK, OK, katastrofa.
Założyciel zbudował narzędzie B2B z asystentem AI w trzy weekendy. Pozyskał pięciu płacących klientów w sześć tygodni. W jedenastym tygodniu jeden z tych klientów — przez przypadek, przez zakładkę w przeglądarce — załadował dashboard innego klienta. Poprawka to dwie linie. Szkoda to email, który założyciel musiał wysłać.
Przegląd, który by to wyłapał, 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 zły pomysł. To świetny sposób, by tanio dojść do sygnału product-market fit. Ale psują się w konkretnym kierunku: kod wyglądający prawdopodobnie, który pada pod realnymi warunkami. Koszt lekkiego, zaplanowanego przeglądu jest trywialny. Koszt pierwszego incydentu, którego można było uniknąć, nie jest.
Jeśli zbudowałeś swoje MVP głównie z pomocą AI, najcenniejsza rzecz, jaką możesz zrobić w tym miesiącu, to dać przeczytać je komuś, kto nie jest AI — i nie jest Tobą.
Rozmowa zapoznawcza jest bezpłatna. 30 minut. Powiem Ci szczerze, czy audyt lub naprawa pasuje do Twojej sytuacji — albo czy żadne nie pasuje.
Umów rozmowę zapoznawczą →