Vibe coding złamał swoją obietnicę

Poświęć godzinę dowolnemu forum osób budujących oprogramowanie i znajdziesz to samo wyznanie w stu różnych wersjach. Ktoś zbudował swoją aplikację w weekend narzędziem z AI. Działała. Wydał ją. Teraz jest poniedziałek, uwierzytelnianie jest zepsute, baza danych po cichu gubi wiersze, a błąd, którego nikt nie umie odtworzyć, to ten, który kosztuje go klientów.

Marzenie, które sprzedawaliśmy sobie pół roku temu, stoi teraz w drzwiach i chce zwrotu pieniędzy.

Chcę być ostrożny w tym, jak to mówię, bo nie sądzę, że osoby, które zbudowały albo używały tych narzędzi, niesłusznie się cieszyły. Skok był prawdziwy. Patrzenie, jak działający interfejs wyłania się z akapitu zwykłej polszczyzny, to jedno z naprawdę magicznych doświadczeń minionej dekady oprogramowania. Ja też to czułem. Wszyscy czuliśmy.

Ale gdzieś między pokazem a wdrożeniem doszło do cichej podmiany. Zaczęliśmy nazywać prototypy produktami. Zaczęliśmy nazywać pokazy oprogramowaniem. A rachunek za to zamieszanie właśnie przychodzi.

Błędna diagnoza

Najczęstsze wyjaśnienie, jakie widzę, obwinia model. AI nie jest jeszcze dość mądra. Konfabuluje. Wybiera złe biblioteki. Pisze kod, który doświadczona osoba z inżynierii wychwyciłaby i przepisała.

To wyjaśnienie jest pocieszające, bo sugeruje rozwiązanie, które już jest w drodze. Poczekaj pół roku. Następny model będzie lepszy. Kiedyś luka się domknie i wszystko będzie działać.

Nie wierzę w to. I nie wierzę, bo sposób, w jaki to zawodzi, nie ma nic wspólnego z tym, jak dobry jest kod.

Microsoft podał przy wynikach za 2025 rok, że około 46 procent całego kodu wysyłanego przez aktywnych użytkowników GitHub Copilot jest teraz generowane przez AI. W tym samym czasie firma zajmująca się bezpieczeństwem aplikacji Veracode opublikowała badanie, według którego kod generowany przez AI wprowadzał luki bezpieczeństwa w około 45 procentach badanych próbek. Te liczby pogorszą się, zanim się poprawią, a mądrzejszy model ich nie naprawi.

Model nie jest problemem. Proces nim jest.

Czego naprawdę brakuje

Przejdź ze mną przez powstawanie aplikacji zrobionej vibe codingiem i wskaż mi, gdzie zapada decyzja architektoniczna.

Opisujesz, czego chcesz. AI wytwarza interfejs i trochę kodu za nim. Patrzysz na interfejs, klikasz, robi mniej więcej to, o co prosiłeś, i ogłaszasz, że gotowe. W żadnym punkcie tej pętli nikt, człowiek ani maszyna, nie zatrzymał się, by określić, co właściwie jest budowane.

Nie ma schematu. Nie ma modelu danych. Nie ma listy stanów, w jakich system może się znaleźć, ani określenia, co uznaje się za poprawne. Nie ma umowy między warstwą frontową a czymś, co udaje zaplecze. Nie ma decyzji o tym, co się stanie, gdy użytkownik zrobi coś, czego generator nie przewidział, bo nikt tego nie przewidział.

To, co zbudowano, jest rzeczą, która przypomina rzecz, o którą prosiłeś, na dokładnie tej ścieżce, którą przypadkiem przeszedłeś w czasie pokazu. Zejdź z tej ścieżki i cała konstrukcja okazuje się rusztowaniem. Pod nim nigdy nie było budynku.

To nie porażka inteligencji. To porażka określenia. I żadna ilość dodatkowej inteligencji zastosowanej do nieokreślonego problemu nie da określonego wyniku. Da tylko bardziej przekonującą wersję tego samego rusztowania.

Trzy decyzje, których nigdy nie podjęto

Będę konkretny, bo abstrakcje są powodem, dla którego ta rozmowa krąży w kółko.

Uwierzytelnianie nie jest funkcją, którą dodaje się później. To decyzja o tym, kim są twoi użytkownicy, co mogą widzieć i na jakiej granicy zaufania stoi twoja aplikacja. Przykręcanie go do aplikacji zrobionej vibe codingiem dwa tygodnie po starcie to programistyczny odpowiednik wstawiania drzwi wejściowych do domu zbudowanego bez ścian.

Schemat bazy danych nie jest czymś, co AI powinna odgadywać, generując formularz, który do niego zapisuje. Schemat jest kręgosłupem aplikacji. Każda decyzja dalej (co możesz odpytać, co możesz zindeksować, co możesz później zmienić bez łamania wszystkiego) jest ograniczona przez wybory podjęte z góry albo właśnie niepodjęte. Kiedy schemat jest improwizowany, każda przyszła zmiana jest przebudową.

Umowa interfejsu programowania nie jest opcjonalna, a w gospodarce, w której agenty AI korzystają z oprogramowania bezpośrednio, jest bliżej produktu niż interfejs. W chwili, gdy twoja aplikacja rozmawia z czymkolwiek innym (obsługą płatności, usługą poczty, innym oprogramowaniem, agentem AI), musi istnieć określona powierzchnia. Bez niej integracje stają się serią jednorazowych łatek, których nikt nie umie utrzymać i nikt nie chce odziedziczyć.

To nie tematy zaawansowane. To minimum budowania oprogramowania, które żyje dłużej niż jego pierwszy weekend. I dokładnie to jest pomijane, gdy cały proces budowy to opisz, spójrz, wydaj.

Problem 70 procent ma teraz nazwę

Nie sądzę, by ktokolwiek zamierzał zbudować branżę wydającą kruche oprogramowanie. Sądzę, że narzędzia powstałe w tej kategorii optymalizowały moment, który sprzedaje narzędzie: magiczny moment, w którym pomysł zamienia się w działający ekran w mniej niż minutę.

Czas do magii stał się rzeczą mierzalną. Czas do produkcji był problemem kogoś innego.

To rozsądna optymalizacja dla pokazu. To okropna optymalizacja dla kategorii oprogramowania, która odpowiada teraz za wydawanie prawdziwych aplikacji prawdziwym użytkownikom, z prawdziwymi pieniędzmi w grze. Zostawia całe pokolenie twórców na mieliźnie przy 90 procentach, z rzeczą, która działa na ich ekranie i rozsypuje się wszędzie indziej.

Twórcy ze społeczności Lovable nadali temu nazwę: problem 70 procent. Dochodzisz do czegoś, co wydaje się prawie skończone, a potem postęp się zatrzymuje. Każda poprawka psuje coś innego. Pozostała praca nie jest pracą, przez którą da się przejść poleceniami, bo tym, co cię blokuje, nie jest brakujący kod. To brakująca decyzja, podjęta w milczeniu, kilkaset generacji wcześniej.

Brudnym sekretem tej kategorii jest to, że łatwą częścią było pierwsze 90 procent. Kolejne 9 procent, sprawienie, by rzecz naprawdę działała dla więcej niż jednego użytkownika, na więcej niż jednym urządzeniu, w warunkach, których nie przewidziałeś, jest trudniejsze niż pierwsze 90 procent razem. A ostatni procent, część odróżniająca działającą aplikację od kruchej, to część wymagająca, byś przed startem wiedział, co budujesz.

Zasada, której AI nie zmieniła

Oto rzecz, której nikt nie chce słyszeć, bo brzmi jak krok w tył w momencie, który ma być wyłącznie ruchem w przód.

Najlepsze oprogramowanie zawsze zaczynało się od określenia. Architektura przed kodem. Jasny model problemu, zanim napisze się choć jedną linię. Było to prawdą, gdy zespoły pięćdziesięciu osób budowały systemy ręcznie, i jest prawdą teraz, gdy jedna osoba i model mogą zbudować ten sam system w weekend.

AI tej zasady nie zmieniła. AI uczyniła ją ważniejszą, nie mniej.

Kiedy koszt wytworzenia kodu zbliża się do zera, koszt wytworzenia złego kodu też zbliża się do zera. To znaczy, że jedyną rzeczą, która wciąż kosztuje, jest ustalenie, jaki kod byłby właściwy. Ta praca (praca określania, praca architektury, część, w której rozstrzygasz, co właściwie budujesz, przed rozpoczęciem budowy) jest jedyną częścią, która nie stała się towarem masowym.

Jest też częścią, którą obecne pokolenie narzędzi pominęło.

Do czego to naprawdę prowadzi

Nie sądzę, że odpowiedzią jest zwolnić. Nie sądzę, że odpowiedzią jest wrócić do pisania wszystkiego ręcznie. Skok był prawdziwy i skok zostaje.

Odpowiedzią jest wbudować krok określania w pętlę, praktykę, którą branża nazywa teraz rozwojem opartym na specyfikacji. Nie jako ręczną bramę, która cię hamuje, ale jako prawdziwy fundament, na którym opiera się reszta pracy. Osoby, które ustalają, jak to robić, pracują nad czymś cichszym niż to, co widziałeś do tej pory. Są bliskie sprawienia, że głośna wersja tej kategorii będzie wyglądała na to, czym zawsze była. O tym, jak wygląda to następne pokolenie, pisałem osobno.

Działający ekran nigdy nie był tym samym co działający system. Wszyscy zaraz sobie przypomnimy dlaczego.

Powiązane lektury

Co zajęło jego miejsce: rozwój oparty na specyfikacji. Jak narzędzia wypadają dziś: najlepsze kreatory aplikacji AI w 2026.

Często zadawane pytania

Co znaczy „vibe coding”? Vibe coding to pisanie oprogramowania przez opisanie w zwykłym języku tego, czego się chce, i przyjęcie tego, co AI wytworzy, bez określania architektury, modelu danych ani umów pod spodem. Andrej Karpathy wprowadził ten termin na początku 2025 roku. Opisuje sposób pracy, a nie kategorię narzędzi: vibe coding jest możliwy w niemal każdym kreatorze z AI.

Dlaczego aplikacje zrobione vibe codingiem pękają w produkcji? Bo awaria jest strukturalna, a nie jest kwestią jakości kodu. Pętla generowania nigdy nie wytwarza schematu, określonego zbioru poprawnych stanów ani umowy między warstwą frontową a zapleczem. Aplikacja działa na ścieżce, na której ją pokazano, i rozsypuje się poza nią. Mądrzejszy model zastosowany do nieokreślonego problemu wciąż daje nieokreślony wynik.

Czym jest problem 70 procent? To wzorzec, w którym aplikacja zbudowana przez AI dochodzi do około 70 procent gotowości i przestaje posuwać się dalej: każda poprawka psuje coś innego, a dalsze polecenia nie domykają luki. Blokadą jest zwykle decyzja architektoniczna podjęta w milczeniu setki generacji wcześniej, której nie da się już zmienić bez przepisania.

Czy kod generowany przez AI jest mniej bezpieczny? Obecne dowody mówią, że wymaga przeglądu. Badanie Veracode wykazało, że kod generowany przez AI wprowadzał luki bezpieczeństwa w około 45 procentach badanych próbek, w momencie gdy Microsoft podawał, że około 46 procent kodu wysyłanego przez aktywnych użytkowników Copilota jest generowane przez AI. Ilość rośnie szybciej niż weryfikacja.

Czy to znaczy, że nie należy używać kreatorów aplikacji z AI? Nie. Do prototypów, pokazów i narzędzi wewnętrznych są naprawdę doskonałe, a szybkość jest prawdziwa. Argument jest tu węższy: działający ekran nie jest działającym systemem, a narzędzia pomijające fazę określania nie mogą wytworzyć drugiego, niezależnie od tego, jak dobry stanie się model.