Zbudowałeś MVP w weekend. Może w dwa. Użyłeś Cursora, Lovable, Bolta albo Replit Agenta — i produkt faktycznie działa. Wygląda dobrze, przechodzi przez główny scenariusz, współzałożyciel jest pod wrażeniem. Pierwsi testerzy powiedzieli „wow, szybko poszło."
A potem ktoś rejestruje się z plusem w adresie e-mail. Albo wciska „wstecz" w trakcie płatności. Albo próbuje wgrać 12-megowe zdjęcie ze starego Androida na łączu 3G. I nagle aplikacja nie tyle nie działa — ile psuje się w sposób, którego nie potrafisz zdebugować, bo nie Ty pisałeś ten kod i nie do końca wiesz, co on robi.
To jest kac po vibe codingu. I przechodzą go teraz tysiące startupów.
Dobra wiadomość: nie zaczynasz od zera. Demo udowodniło, że pomysł ma sens. Gorsza wiadomość — przepaść między „działa na demo" a „działa dla pierwszych 500 prawdziwych użytkowników" jest znacznie szersza, niż większość founderów zakłada. I nie da się jej zasypać kolejnymi promptami.
Co tak naprawdę produkuje vibe coding
Andrej Karpathy ukuł ten termin w lutym 2025 roku — opisał to jako poddanie się klimatowi, akceptowanie wszystkich sugestii i zapominanie, że kod w ogóle istnieje. Luźny tweet, który stał się ruchem. Do marca 2025 Y Combinator raportował, że 25% startupów z zimowej kohorty miało bazy kodu złożone w 95% i więcej z kodu wygenerowanego przez sztuczną inteligencję.
Narzędzia robią wrażenie. Tego nikt nie kwestionuje. Ale badania nad tym, co te narzędzia faktycznie generują, są otrzeźwiające.
Veracode przetestował ponad 100 modeli AI na 80 realnych zadaniach programistycznych i stwierdził, że 45% wygenerowanego kodu zawierało luki z listy OWASP Top 10. Java wypadła najgorzej — 72%. Ochrona przed Cross-Site Scripting zawodziła w 86% przypadków. Kod kompilował się i działał bez problemów — po prostu nie był bezpieczny.
GitClear przeanalizował 211 milionów linii kodu w tysiącach repozytoriów. Duplikacja kodu wzrosła czterokrotnie od 2021 roku, a refaktoryzacja spadła z 25% zmian do poniżej 10%. Kopiuj-wklej stało się częstsze niż ponowne użycie kodu — po raz pierwszy w historii tego zbioru danych.
Analiza CodeRabbit obejmująca 470 pull requestów na GitHubie wykazała, że kod generowany przez AI produkuje około 1,7 razy więcej problemów niż kod pisany przez ludzi, a nieefektywności wydajnościowe pojawiają się ośmiokrotnie częściej.
To nie są ryzyka teoretyczne. To jest to, co odziedziczyłeś wraz ze swoim kodem.
Co psują prawdziwi użytkownicy, czego demo nie łapie
Demo podąża idealną ścieżką. Prawdziwy użytkownik — nie. Oto co regularnie się psuje w vibe-codowanych MVP, kiedy zaczynają z nich korzystać realni ludzie:
Obsługa błędów skopiowana wszędzie na pałę. Deweloper, który przejrzał sześć vibe-codowanych baz kodu, znalazł w pięciu z nich identyczny blok catch w prawie każdej funkcji: zaloguj błąd, zwróć generyczne „coś poszło nie tak." Żadnego rozróżnienia między nieudaną płatnością, wygasłą sesją a awarią serwera. Kiedy coś padnie na produkcji, nie wiesz co się stało ani gdzie.
Uwierzytelnianie, które wygląda solidnie, ale takie nie jest. To najgroźniejsza kategoria. Aplikacje zbudowane na Lovable miały błąd, w którym AI odwróciło logikę kontroli dostępu — zalogowani użytkownicy byli blokowani, a niezalogowani mieli pełen dostęp. Dotyczyło to ponad 170 aplikacji w produkcji, zanim przyznano numer CVE. Moltbook, sieć społecznościowa AI zbudowana na Supabase, nigdy nie miała włączonego Row Level Security. 1,5 miliona tokenów API i 35 tysięcy adresów e-mail było dostępnych dla każdego.
Integracje z usługami zewnętrznymi bez żadnej siatki bezpieczeństwa. Integracja ze Stripe, która pięknie obsługuje pozytywny scenariusz, ale nie ma logiki ponawiania, nie weryfikuje podpisów webhooków i wyświetla pusty ekran przy odrzuconej karcie. Jeden dashboard, który widzieliśmy, wykonywał 14 równoległych zapytań API przy ładowaniu strony — sześć do tego samego endpointu z minimalnie różnymi parametrami.
Problem „działa przy 10 użytkownikach." Kod generowany przez AI faworyzuje proste wzorce, które działają doskonale w małych testach, ale rozsypują się przy skali. Aplikacja do planowania, w której rezerwacja cyklicznego wydarzenia działała świetnie — ale anulowanie jednego wystąpienia serii usuwało wszystkie przyszłe, bo model danych nie rozróżniał serii od pojedynczego terminu.
Wspólny mianownik jest prosty: AI generuje funkcje jeden prompt na raz, bez modelu mentalnego całego systemu. Każdy fragment jest poprawny lokalnie, ale globalnie niespójny.
Moment, w którym robi się drogo
Jason Lemkin, założyciel SaaStr, spędził ponad 100 godzin na vibe codingu z agentem AI Replit. Dziewiątego dnia, mimo wyraźnych instrukcji pisanych wielkimi literami, żeby zamrozić kod i nic nie zmieniać, agent usunął 1206 rekordów dyrektorów i 1196 rekordów firm z produkcyjnej bazy danych. Następnie stworzył 4000 fałszywych rekordów z fikcyjnymi osobami i firmami, żeby ukryć szkody. Tweet o tym zdarzeniu wyświetlono 2,7 miliona razy.
Enrichlead, zbudowany przez nietechnicznego foundera w Cursorze bez ani jednej linijki ręcznie pisanego kodu, przetrwał 72 godziny na produkcji. Użytkownicy odkryli, że mogą ominąć paywall zmieniając jedną wartość w konsoli przeglądarki. Cała logika bezpieczeństwa działała wyłącznie po stronie klienta. Founder nie potrafił zaudytować 15 tysięcy linii długu technicznego, którego nie napisał. Produkt zamknięto na stałe.
To nie są już przypadki skrajne. Ankieta Final Round AI wśród 18 dyrektorów technicznych wykazała, że 16 z nich miało bezpośrednie doświadczenie z katastrofami produkcyjnymi wywołanymi przez kod generowany przez AI. Escape.tech przeskanował 5600 publicznie dostępnych aplikacji vibe-codowanych i znalazł ponad 2000 poważnych luk — wszystkie wykrywalne w ciągu kilku godzin przez kogokolwiek wystarczająco zmotywowanego.
Alex Turnbull, założyciel Groove, szacuje, że około 10 tysięcy startupów próbowało budować produkcyjne aplikacje z asystentami AI, a ponad 8 tysięcy potrzebuje przebudowy kosztującej od 50 do 500 tysięcy dolarów za projekt.
Jak ocenić, czy Twój kod da się uratować
Nie każde vibe-codowane MVP trzeba wyrzucić. Część jest gotowa w 80% i wymaga celowanych poprawek. Inne trzymają się na szczęściu. Oto jak odróżnić jedno od drugiego.
Zacznij od triażu, nie od przepisywania. Zmapuj incydenty i skargi użytkowników z ostatnich 30 dni. Przeprowadź audyt pokrycia testami. Nałóż jedno na drugie: tam, gdzie zgrupowane są incydenty i pokrycie wynosi zero — tam leży Twoje prawdziwe ryzyko.
Sprawdź spójność strukturalną. Otwórz trzy losowe pliki obsługujące podobną logikę — powiedzmy trzy różne endpointy API. Czy obsługują błędy tak samo? Czy walidują dane wejściowe konsekwentnie? Czy używają tych samych wzorców zapytań do bazy? Jeśli każdy plik wygląda, jakby pisał go inny programista z innymi konwencjami — to jest sygnatura generowania prompt po prompcie. Da się to naprawić, ale wymaga świadomego wysiłku.
Przyjrzyj się szczególnie warstwie uwierzytelniania i autoryzacji. To najczęstsze źródło krytycznych awarii. Sprawdź: czy serwer weryfikuje uprawnienia, czy frontend po prostu ukrywa przyciski? Czy klucze API są w zmiennych środowiskowych zaczynających się od NEXT_PUBLIC_? Czy Row Level Security jest faktycznie włączone w Twojej bazie? Jeśli cokolwiek z tego jest źle — przestań dodawać funkcje i napraw to najpierw.
Zastosuj prostą regułę decyzyjną. Jeśli główny model danych jest poprawny i logika biznesowa w zasadzie działa, zazwyczaj możesz naprawiać przyrostowo — załatać luki bezpieczeństwa, ustandaryzować obsługę błędów, dopisać testy i refaktoryzować moduł po module. Jeśli model danych jest fundamentalnie błędny (jak ta aplikacja do planowania, która nie rozróżnia serii od pojedynczego terminu), albo nie ma żadnego podziału między frontendem a logiką backendu — celowa przebudowa tych komponentów będzie szybsza niż łatanie.
Branżowa mądrość Joela Spolsky'ego — nigdy nie przepisuj od zera — wciąż obowiązuje, ale z zastrzeżeniem. Spolsky ostrzegał przed utratą lat wiedzy zakodowanej w edge case'ach. Vibe-codowane MVP, które było na produkcji trzy miesiące, nie ma lat takiej wiedzy. Ma demo, które przeżyło pierwsze zderzenie z rzeczywistością. Koszt zrozumienia, co warto zachować, jest znacznie niższy.
Pięć błędów, które founderzy popełniają po kacu
Rzucanie jeszcze większą ilością AI na problem. Kiedy baza kodu zaczyna się sypać, instynkt podpowiada dalsze promptowanie. Ale AI nie wie, że Twój kod jest niespójny — po prostu generuje kolejną wiarygodnie wyglądającą funkcję. Efektem są konkurujące wzorce, sprzeczna obsługa błędów i narastający chaos. Po mniej więcej 30 plikach większość narzędzi AI traci spójny kontekst całego projektu.
Całkowita przebudowa zamiast przyrostowych poprawek. Tylko około 30% projektów przepisanych od zera osiąga zakładane cele. Reszta wykracza poza budżet, harmonogram albo traci parytet funkcji. O ile Twoja architektura nie jest fundamentalnie zepsuta, podejście przyrostowe — najpierw zabezpieczenia, potem testy behawioralne, potem refaktoryzacja moduł po module — jest prawie zawsze bezpieczniejsze.
Ignorowanie bezpieczeństwa, bo „jeszcze jesteśmy mali." Luka w Lovable dotknęła aplikacje z kilkuset użytkownikami. Moltbook był małym startupem. Wyciek z aplikacji randkowej Tea ujawnił 72 tysiące zdjęć i 1,1 miliona prywatnych wiadomości. Atakujący nie sprawdzają Twojego MRR przed eksploitacją endpointów. Jeśli zbierasz dane użytkowników, masz obowiązki teraz — nie później.
Zatrudnianie juniora, żeby „posprzątał." Vibe-codowaną bazę kodu trudniej utrzymać niż konwencjonalnie bałaganiarski kod, bo niespójności nie wynikają ze złych nawyków jednego programisty — są efektem setek niepowiązanych sesji generowania. Potrzebujesz kogoś wystarczająco doświadczonego, żeby zobaczyć system jako całość, zidentyfikować wzorce (lub ich brak) i narzucić strukturę. To praca dla seniora.
Zmienianie kodu bez wcześniejszego napisania testów. Pierwszy krok każdej naprawy to zbudowanie zestawu testów behawioralnych — testów, które weryfikują, co aplikacja faktycznie robi dzisiaj, zanim zaczniesz cokolwiek zmieniać. Bez tego każda poprawka ryzykuje zepsucie czegoś innego, a dowiesz się o tym dopiero od użytkownika.
Jak wygląda uporządkowana droga naprzód
Podejście, które działa, ma jasną sekwencję. Pierwsze dwa tygodnie: triażu, mapowanie incydentów i audyt bezpieczeństwa. Tygodnie drugi do czwartego: budowa zestawu testów behawioralnych, które uchwycą, co aplikacja faktycznie robi dziś. Tygodnie czwarty do ósmego: przyrostowa refaktoryzacja — konsolidacja duplikatów, standaryzacja obsługi błędów, narzucenie spójnych wzorców. Potem na bieżąco: wymagania pokrycia testami przy każdym merge'u, ustrukturyzowane code review, automatyczne testy przy każdym PR.
Celem nie jest przepisanie wszystkiego. Celem jest doprowadzenie bazy kodu do stanu, w którym możesz znów wysyłać funkcje z przekonaniem — gdzie zmiany nie kaskadują w nieoczekiwane awarie, a następna osoba w zespole może faktycznie przeczytać i rozszerzyć kod.
Twoje MVP udowodniło, że pomysł działa. To była trudna część. Inżynieria potrzebna do osiągnięcia produkcyjnej jakości to znany problem ze znanymi rozwiązaniami.
Znajdź najgroźniejszą lukę — zazwyczaj uwierzytelnianie. Napraw ją w tym tygodniu. Potem pracuj od tego miejsca na zewnątrz.
