Vibe coding – świetny start, ale ktoś musi zrobić prawdziwą robotę

Kilka dni temu rozmawiałem z założycielem startupu, który w weekend zbudował działającą aplikację webową przy pomocy AI. Bez dyplomu z informatyki, bez bootcampu, po prostu jasny pomysł i dobre prompty. Szczerze mówiąc, zrobiło to na mnie wrażenie. System logowania, dashboard, trwałość danych – wszystko działało w niecałe trzy doby.

A potem zapytał, czy mogę pomóc mu to wdrożyć do prawdziwych użytkowników.

I tutaj zaczęła się prawdziwa zabawa.

Prototyp a produkcja – ta przepaść jest realna

Prototyp działał, bo był tylko jeden użytkownik. Gdy tylko spróbowaliśmy dodać drugą osobę, pojawiły się błędy współbieżności. Baza danych nie miała migracji schematu, więc cofnięcie zmian oznaczałoby utratę danych. Nie było testów, co oznaczało, że każda refaktoryzacja była jak rozminowywanie bomby z zawiązanymi oczami. A deployment to była ręczna robota z zerową dokumentacją.

Projekt weekendowy? Świetny proof of concept. Produkcja? Absolutnie nie.

Tego właśnie nie widać w całej tej dyskusji o vibe codingu. Narzędzia są realne, szybkość jest realna, demokratyzacja tworzenia oprogramowania naprawdę cieszy. Ale jest różnica między generowaniem kodu a inżynierią oprogramowania. I ta różnica ma znaczenie – zwłaszcza gdy o trzeciej w nocy coś pada.

Jedyna metryka, która się liczy

Zadaję sobie jedno pytanie, gdy widzę kod wygenerowany przez AI: czy można to bezpiecznie zmergować do wspólnego codebase'u?

Nie "czy działa". Nie "czy demo zrobiło furorę". Bezpiecznie zmergować. To słowo "bezpiecznie" waży naprawdę dużo. Oznacza, że kod może zostać przejrzany przez kogoś, kto go nie pisał. Że testy weryfikują zachowanie, a nie tylko to, że program się nie wysypuje. Że rollback jest możliwy bez utraty danych. Że zmiana jest na tyle wąska, że da się ją zrozumieć i wyjaśnić.

Vibe coderzy mierzą sukces czasem do pierwszej działającej wersji. To użyteczna metryka na etapie odkrywania i prototypowania. Ale gdy software trafia do współdzielonego środowiska, ta metryka przestaje mieć sens. Teraz mierzysz czas do bezpiecznego merga, a to obejmuje koszt review, jakość testów, ryzyko wdrożenia, nakład koordynacji i przyszły ciężar utrzymania.

Inżynier myśli o całym tym cyklu od początku. Vibe coder często odkrywa te kwestie później – gdy kosztują znacznie więcej.

Generowanie vs. posiadanie

Jest subtelna, ale kluczowa zmiana, która zachodzi, gdy AI generuje Twój kod. Wynik nie jest jeszcze Twoją pracą. To punkt wyjścia, który trzeba przekształcić w coś, co naprawdę posiadasz.

Posiadanie oznacza kilka rzeczy. Możesz wyjaśnić każdą istotną decyzję w zmianie. Rozumiesz, dlaczego każdy plik istnieje i co robi. Zawęziłeś zmianę dokładnie do tego, co było potrzebne – bez zbędnego boilerplate'u czy niezwiązanego sprzątania. Napisałeś lub zweryfikowałeś testy, które sprawdzają zachowanie, a nie tylko pokrycie kodu. Pomyślałeś o ścieżce rollbacku.

To jest praca, której AI nie może wykonać za Ciebie. AI generuje. Ty decydujesz. A "decydujesz" oznacza, że przemyślałeś alternatywy, rozważyłeś kompromisy i zrozumiałeś konsekwencje.

Gdy patrzę na kod wygenerowany przez AI, który nie został odpowiednio "przyjęty na własność", widzę te same problemy. Zmiany za duże, bo model wygenerował więcej niż potrzeba. Pakiety dodane bez jasnego uzasadnienia. Testy wyglądające jakby zostały napisane po to, żeby zadowolić narzędzie do pokrycia kodu, a nie żeby łapać prawdziwe błędy. Boilerplate, który istnieje, bo model domyślnie tworzy szkielet zamiast prostoty.

To nie wina AI. To efekt autora, który potraktował wynik generowania jako postęp, a nie jako surowiec.

Problem review, o którym nikt nie mówi

Jest coś, co nie daje mi spać: AI-generowany kod zmienia równanie przeglądu kodu.

Gdy inżynier-ludzik pisze kod, zwykle jest ślad decyzji. Możesz się nie zgadzać z ich wyborami, ale przynajmniej są jakieś wybory. Możesz zapytać, dlaczego użyli tej abstrakcji, dlaczego walidacja jest tam, dlaczego wybrali tę bibliotekę. Odpowiedzi mogą być "nie pomyślałem o tym" albo "wydawało się rozsądne wtedy", ale przynajmniej jest ktoś, kogo możesz zapytać.

Z AI-generowanym kodem niektóre z tych "decyzji" w ogóle nie są decyzjami. To uzupełnienia. Model wybrał wzorzec, bo był statystycznie prawdopodobny, nie dlatego, że pasował do Twojego problemu. A jeśli autor nie zamienił tego uzupełnienia w pracę, którą naprawdę rozumie, przegląd staje się o wiele trudniejszy.

Nie możesz zapytać modelu, dlaczego wybrał to podejście. Nie możesz zapytać autora, dlaczego podjął tę decyzję, jeśli jej tak naprawdę nie zna. Więc albo problemy wychodzą przy bolesnej metodzie prób i błędów, albo w ogóle nie wychodzą.

Dlatego uważam, że najważniejsza umiejętność w erze AI-assisted development to nie prompting. To umiejętność wzięcia wygenerowanego wyniku i przekształcenia go w kod, który rozumiesz wystarczająco głęboko, żeby go posiadać, wyjaśnić i utrzymywać.

Co to oznacza dla Twojego zespołu

Jeśli budujesz prototyp, żeby przetestować pomysł, vibe coding to legitymacyjne podejście. Szybkość uczenia się ma znaczenie, gdy wciąż walidujesz założenia. Używaj narzędzi, działaj szybko, zbuduj coś do pokazania ludziom.

Ale jeśli ten prototyp ma stać się prawdziwym produktem, w pewnym momencie wygenerowany kod musi przejść przez filtr kogoś, kto myśli jak inżynier. Nie po to, żeby gatekeepować. Nie po to, żeby zwalniać. Po to, żeby upewnić się, że to, co trafia do produkcji, to kod, który zespół może zrozumieć, utrzymywać i któremu może zaufać.

W NameOcean widzimy ten wzorzec cały czas. Startupy, które szybko idą z AI, żeby zwalidować pomysły, a potem uderzają w ścianę, gdy muszą skalować. Te dobre wtedy ściągają pomoc inżynieryjną. Te złe nadal dorzucają ficzery do codebase'u, którego nikt naprawdę nie rozumie.

Cel nie jest taki, żeby unikać AI-assisted development. Cel jest taki, żeby być uczciwym co do tego, gdzie praca się zaczyna i gdzie się kończy. AI może generować kod. Ty musisz inżynierować oprogramowanie.

Podsumowanie

Vibe coding to fantastyczny start. Sposób na szybkie testowanie pomysłów, naukę tego, co możliwe, przejście od koncepcji do czegoś namacalnego bez miesięcy tradycyjnego developmentu.

Ale inżynieria oprogramowania to pełny cykl życia. Kod, który Twój zespół może przeglądać, utrzymywać i któremu ufa, gdy o drugiej w nocy coś idzie nie tak. Zmiany na tyle wąskie, że da się je zrozumieć i cofnąć, jeśli trzeba. Branie odpowiedzialności za decyzje – nawet gdy te decyzje były zasugerowane przez AI.

Najlepsi developerzy, których znam, używają AI tooli intensywnie. Po prostu robią to z otwartymi oczami. Wiedzą, że wygenerowany kod to surowiec, nie gotowy produkt. I wiedzą, że w pewnym momencie ktoś musi wykonać pracę inżynieryjną, która robi różnicę między fajnym demem a softwarem, który naprawdę da się wdrożyć.

Więc tak, vibe coduj do woli. Buduj szybko, eksperymentuj swobodnie, używaj każdego dostępnego narzędzia. Ale wiedz, kiedy nadszedł czas, żeby przerzucić się z vibe na engineering. Twoja przyszła wersja i Twój przyszły zespół Ci za to podziękują.