Vibe coding jest świetny, dopóki najgorszą konsekwencją błędu jest niedziałający przycisk. Pozwala zbudować prototyp w weekend, sprawdzić pomysł i pokazać inwestorowi coś lepszego niż slajdy. Problem zaczyna się wtedy, gdy prototyp dostaje prawdziwych użytkowników, dane i płatności, a autor nadal nie rozumie kodu, który wdrożył.
Moje stanowisko jest proste: vibe coding to narzędzie do walidacji pomysłu, nie metoda utrzymywania produktu. Jeśli kod trafia na produkcję, potrzebujesz testów, review, monitoringu i człowieka odpowiedzialnego za architekturę. W tym momencie kończy się vibe, a zaczyna normalna inżynieria.
Demo działa, więc łatwo pomylić je z produktem
Model potrafi w godzinę zbudować formularz, logowanie i panel z wykresami. Każdy element przechodzi prosty test: klikasz i działa. To daje mocne poczucie postępu, bo wynik jest widoczny natychmiast.
Produkcja sprawdza jednak rzeczy, których demo nie pokazuje. Co się stanie, gdy dwa żądania zapiszą ten sam rekord? Czy użytkownik A może odczytać dane użytkownika B po zmianie identyfikatora w adresie? Czy webhook płatności uruchomiony drugi raz naliczy usługę ponownie? Czy po wygaśnięciu sesji system bezpiecznie odrzuci żądanie?
To nie są rzadkie przypadki. To zwykły wtorek w działającym produkcie.
Badanie Stack Overflow pokazuje skalę rozdźwięku. 84% respondentów używa narzędzi AI lub planuje ich używać, ale tylko 32,7% ufa poprawności odpowiedzi. Aż 45,7% deklaruje brak zaufania. Jednocześnie 66% wskazuje jako główny problem rozwiązania, które są prawie poprawne, a 45,2% narzeka na czas tracony przy debugowaniu kodu wygenerowanego przez AI.
„Prawie poprawne” wystarcza do dema. Na produkcji oznacza incydent czekający na odpowiedni zestaw danych.
Najuczciwszy kontrargument: narzędzia już dojrzały
Zwolennicy mają mocny argument. Vibe coding w 2026 roku nie musi oznaczać bezmyślnego kopiowania odpowiedzi z czatu. Agent czyta repozytorium, zmienia wiele plików, uruchamia testy i poprawia własne błędy. Dobrze opisany proces może obejmować specyfikację, reguły projektu, kontrolę wersji i automatyczne skanowanie bezpieczeństwa.
Jeden z nowszych przewodników przekonuje, że taki proces nadaje się do produkcji, jeśli człowiek odpowiada za architekturę, czyta zmiany linia po linii i wymusza testy oraz analizę bezpieczeństwa. Zgoda.
Tyle że to nie jest już vibe coding. To programowanie wspomagane przez AI z pełnym procesem inżynierskim. Różnica nie leży w tym, kto wpisuje znaki do pliku. Leży w tym, kto rozumie decyzje, potrafi ocenić ryzyko i bierze odpowiedzialność za wynik.
Kod może działać i nadal być niebezpieczny
Najmocniejsze dane dotyczą bezpieczeństwa. Benchmark SusVibes sprawdził agentów na 200 zadaniach z 108 prawdziwych projektów open source. Zadania obejmowały 77 typów podatności i wymagały zmian w dużych repozytoriach, a nie wygenerowania jednej funkcji bez kontekstu.
Najlepsza badana kombinacja dostarczyła funkcjonalnie poprawne rozwiązanie w 61% przypadków. Tylko 10,5% rozwiązań było jednocześnie bezpiecznych. Wśród rozwiązań, które działały, 82,8% nadal zawierało podatność.
To ważne, bo vibe coder zazwyczaj zatrzymuje się przy pierwszym kryterium. Funkcja działa. Test interfejsu przechodzi. Można wdrażać. Ukryty test bezpieczeństwa nie istnieje, a autor nie wie, że powinien go napisać.
Ryzyko rośnie przy:
- logowaniu, sesjach i resetowaniu haseł,
- płatnościach oraz webhookach,
- uprawnieniach do danych różnych użytkowników,
- przesyłaniu plików,
- sekretach, tokenach i konfiguracji chmury,
- integracjach wykonujących operacje w imieniu klienta.
Jeżeli aplikacja dotyka któregokolwiek z tych obszarów, samo „działa u mnie” nie jest kryterium wdrożenia.
Granica między prototypem a produkcją
| Obszar | Prototyp | Produkcja |
|---|---|---|
| Dane | testowe, możliwe do usunięcia | prawdziwe, często osobowe lub finansowe |
| Użytkownicy | autor i kilka zaproszonych osób | nieznane zachowania, błędy i próby nadużyć |
| Błąd | restart lub poprawka promptem | utrata danych, koszt, reklamacja albo incydent |
| Kontrola jakości | ręczne kliknięcie głównej ścieżki | testy automatyczne, review i monitoring |
| Odpowiedzialność | eksperymentujący autor | konkretna osoba i firma |
Vibe coding ma sens po lewej stronie tabeli. Po prawej może nadal generować dużą część kodu, ale nie może być jedyną warstwą kontroli.
Społeczność dochodzi do podobnego wniosku po kilku miesiącach, nie po pierwszym weekendzie. W dyskusjach o utrzymywaniu aplikacji zbudowanych w ten sposób pytanie nie brzmi już „jak szybko wystartowałeś?”, lecz „czy po pół roku nadal potrafisz dodawać funkcje i naprawiać błędy?”. To znacznie lepsza miara jakości produktu.
Doświadczenie z prawdziwego projektu
Przy migracji panelu SaaS dla klienta z logistyki najwięcej czasu nie zabrał widoczny layout. Problemem był przepływ uwierzytelniania: ciasteczko HTTP-only, kod wykonywany po stronie serwera, przekazanie bezpiecznego stanu do przeglądarki i zachowanie sesji między widokami. Opisaliśmy ten przypadek przy porównaniu routerów w Next.js.
Agent może szybko narysować panel ustawień. Produkcyjna wartość powstaje dopiero wtedy, gdy ktoś rozumie, kto ma dostęp do danych, gdzie działa kod i co wydarzy się po wygaśnięciu tokenu.
Minimalny proces przed pierwszym prawdziwym użytkownikiem
Nie musisz wyrzucać prototypu i zaczynać od zera. Musisz przestać traktować kolejne prompty jak proces kontroli jakości.
- Zapisz architekturę, przepływ danych i granice uprawnień.
- Usuń klucze oraz sekrety z kodu i historii repozytorium.
- Dodaj testy logowania, płatności i najważniejszych operacji na danych.
- Uruchom lint, testy typów, skaner zależności i podstawową analizę bezpieczeństwa.
- Zleć review osobie, która potrafi wyjaśnić każdą krytyczną zmianę bez pytania modelu.
- Dodaj logi, monitoring błędów, kopie zapasowe i sprawdzoną procedurę odtworzenia danych.
- Wdrażaj małe zmiany, żeby dało się wskazać przyczynę awarii i szybko ją cofnąć.
Dopiero po przejściu tej listy masz produkt, którym można rozsądnie zarządzać. Wcześniej masz demonstrację z publicznym adresem.
Jeśli prototyp ma obsługiwać prawdziwych klientów, zacznij od technicznego przeglądu aplikacji i planu wdrożenia, zanim dołożysz kolejne funkcje.
Wniosek
Nie walcz z vibe codingiem. Używaj go tam, gdzie jest najlepszy: przy prototypach, narzędziach jednorazowych, eksperymentach i walidacji rynku. Pozwala sprawdzić pomysł taniej niż klasyczny development i to jest realna przewaga.
Nie udawaj jednak, że szybkość generowania kodu usuwa koszt inżynierii. Ona tylko przesuwa ten koszt z pisania na weryfikację, bezpieczeństwo i utrzymanie. Im mniej rozumiesz wygenerowany system, tym wyższy rachunek pojawi się później.
Vibe coding kończy się nie wtedy, gdy wyłączasz agenta. Kończy się wtedy, gdy za aplikację zaczynają płacić prawdziwi użytkownicy. Od tej chwili ktoś musi wiedzieć, dlaczego ten kod działa, jak może się zepsuć i jak bezpiecznie go naprawić.