Musimy przestać nazywać wszystko „vibe coding”

Wróciłem do programowania po długiej przerwie i to w Lovable podjąłem się tego ponownie. Aplikacje wyglądały świetnie, działały na pierwszy rzut oka i powstały w kilka godzin. Na początku wydawało się to niezwykłe. Jednak przestało być wystarczające w momencie, gdy chciałem dowiedzieć się, co kod robi – i dlaczego. To był moment, w którym moje podejście zaczęło się zmieniać.

Różnica nie dotyczy narzędzia ani tego, ile kodu AI napisało za Ciebie. Chodzi o umowę, którą przyjmujesz wobec swojego wyniku: czy potrafisz wyjaśnić to, co właśnie wypuściłeś na świat, czy nie.

Vibe coding, w swoim pierwotnym znaczeniu, oznacza przyjmowanie oprogramowania generowanego przez SI bez właściwego zbadania lub zrozumienia, co leży pod jego powierzchnią. Rozwój wspomagany SI jest inny. Model może nadal pisać większość kodu, ale osoba budująca system pozostaje odpowiedzialna za zrozumienie jego zachowania, testowanie założeń i decydowanie, czy jest gotowy do wypuszczenia.

Dla jednorazowego eksperymentu, który nigdy nie opuszcza własnego komputera, rozróżnienie może mieć niewiele konsekwencji. Gdy oprogramowanie zostaje wdrożone, używane przez innych lub podłączone do rzeczywistych danych, ma to ogromne znaczenie.

Jak „vibe coding” straciło znaczenie

Termin „vibe coding” został wymyślony w lutym 2025 przez Andreja Karpathy’ego, współzałożyciela OpenAI. Jego przykład był celowo swobodny: „rzutowy projekt weekendowy” zbudowany poprzez automatyczne klikanie „Accept All”, ignorowanie różnic i pozwalanie kodowi rosnąć poza jego zrozumienie.

Tydzień później deweloper i twórca narzędzi Simon Willison zauważył, że termin jest używany zupełnie inaczej: jako zamiennik dla wszelkiego programowania wspomaganego SI, co jego zdaniem rozmywa znaczenie i daje fałszywe wyobrażenie o tym, co odpowiedzialny rozwój wspomagany SI może osiągnąć.

Ciekawe jest to, że Karpathy ostatecznie się zgodził. Rok później wprowadził inny termin dla bardziej zdyscyplinowanej pracy z agentami kodującymi. Opisał „agentic engineering” jako przepływ pracy, w którym deweloperzy kierują i nadzorują agentów zamiast po prostu akceptować to, co produkują. Rozróżnienie ma znaczenie: profesjonalny rozwój wspomagany SI wymaga planowania, wnikliwości i odpowiedzialności w sposób, którego swobodne vibe coding nie zapewnia.

Granica to odpowiedzialność

Zasada Willisona jest prosta i działa jako test dla każdego: nie zatwierdzaj kodu, którego nie potrafisz wyjaśnić innemu. To nie znaczy czytanie każdej linii: przy generowaniu setek linii jednocześnie, nawet doświadczeni programiści już tego nie robią. Chodzi o zrozumienie podstawowej logiki i umiejętność uzasadnienia, dlaczego kod robi dokładnie to, co robi. Jeśli potrafisz, nie ma znaczenia, czy model go napisał, czy Ty: to nie jest vibe coding, to używanie narzędzia do budowania oprogramowania.

Badania opublikowane w grudniu 2025 potwierdzają to rozróżnienie. Na podstawie obserwacji terenowych i jakościowej ankiety wśród profesjonalnych deweloperów, badacze stwierdzili, że doświadczeni praktycy zachowali kontrolę nad projektowaniem i implementacją oprogramowania, zamiast przekazywać cały proces SI. Traktowali agentów jako współpracowników, starannie planowali swoją pracę i pozostawali zaangażowani w nadzór.

Tak więc samo doświadczenie tego nie wyjaśnia. Chodzi o to, czy jesteś gotów wziąć odpowiedzialność za to, co wygenerowała SI. To decyzja, którą każdy programista podejmuje na nowo przy każdym projekcie.

Co się dzieje, gdy brakuje kontroli

Konsekwencje wypuszczenia oprogramowania bez zrozumienia lub weryfikacji jego bezpieczeństwa nie są abstrakcyjne. Tea, aplikacja mająca pomóc kobietom pozostać bezpiecznym podczas randek, ujawniła dziesiątki tysięcy zdjęć dokumentów i ponad milion prywatnych wiadomości w dwóch incydentach bezpieczeństwa. Błędy obejmowały niezaszyfrowany bucket przechowywania oraz osobną bazę danych dostępną bez uwierzytelnienia.

Ten sam podstawowy problem – oprogramowanie wydawało się działać, podczas gdy logika autoryzacji była niebezpiecznie błędna – pojawił się w aplikacji zbudowanej na platformie Lovable: badania bezpieczeństwa wykazały odwróconą logikę autoryzacji, blokując zalogowanych użytkowników i jednocześnie pozwalając nieautoryzowanym atakującym na swobodne wejście, dotykając ponad 18 000 użytkowników, w tym studentów.

To nie są odosobnione przypadki, które zdarzają się tylko w „złych” projektach. Według raportu Google DORA z 2025, 90 % deweloperów używa teraz SI w pracy, podczas gdy około jedna trzecia zgłasza niewielkie lub żadne zaufanie do tego, co generuje.

Użycie SI jest teraz powszechne, mimo że zaufanie pozostaje ograniczone. Dlatego dokładny przegląd jest szczególnie ważny, gdy generowany kod obsługuje uwierzytelnianie, uprawnienia lub wrażliwe dane.

Kontrola jest budowana warstwowo, nie jednorazowo

W moim przypadku nie zaczynałem od formalnego audytu bezpieczeństwa. Po prostu odmawiałem kontynuacji, gdy nie mogłem wyjaśnić, dlaczego coś zachowuje się w określony sposób – naturalny instynkt, który przenoszę do pracy jako analityk. Zależy mi mniej na składni niż na tym, czy wynik odpowiada temu, czego pierwotnie potrzebowaliśmy. Gdy nie, wciąż drążę problem.

Mój przepływ pracy stał się bardziej ustrukturyzowany, gdy projekty stawały się poważniejsze. Zamiast polegać wyłącznie na promptach, zacząłem przygotowywać specyfikacje przed generowaniem czegokolwiek. Udokumentowałem wymagania biznesowe, stos technologiczny i integracje. Następnie pojawiły się testy jednostkowe i testy Playwright dla głównych ścieżek użytkownika.

Kontrole bezpieczeństwa dodawane były w podobny sposób. Przeglądałem biblioteki wybrane przez SI i wprowadziłem skanowanie pod kątem malware dla przesyłanych plików. Każda kontrola wynikała z pytania, co może pójść nie tak dalej, a nie z listy kontrolnej przygotowanej na początku.

Ten nawyk wykrył problem w jednym projekcie. SI wprowadziło bibliotekę niekompatybilną z wersją frameworka, którego używałem. Aplikacja nie zawiodła od razu, więc niekompatybilność mogła łatwo pozostać niezauważona. Wykrycie jej później znacznie utrudniłoby ustalenie przyczyny.

W porównaniu z przypadkami Tea i Lovable, był to zwykły problem. Znalazłem go wcześnie, naprawiłem i poszedłem dalej. Tak zazwyczaj wygląda przegląd w praktyce. Najczęściej zapobiega on małym problemom przed przekształceniem się w większe.

Nie podchodzę z nieufnością do kodu jedynie dlatego, że został wygenerowany przez SI. Nie ufam mu też po prostu dlatego, że aplikacja działa. Testy i przegląd to sposób, w jaki ustalam, czy zachowuje się zgodnie z zamierzeniami.

Od „vibe coding” do „agentic engineering”

Odejście Karpathy’ego od „vibe coding” w kierunku „agentic engineering” nie jest jedynie zmianą słownictwa. „Agentic engineering” daje nam użyteczniejszą nazwę dla kierunku, w którym zmierza profesjonalny rozwój. Deweloperzy mogą pisać mniej linii samodzielnie, ale nie zmniejsza to ich odpowiedzialności. Przesuwa to ich pracę w stronę określania, co system ma robić, kierowania agentami, testowania ich wyników i decydowania, co jest bezpieczne do wypuszczenia.

Niebezpieczeństwo nie polega na tym, że AI szybko generuje kod.. Gdy to się dzieje, pozorna produktywność ukrywa ryzyka, które nikt nie zbadał dokładnie.

Zasada, którą warto zachować

Przestań używać „vibe coding” jako etykiety dla każdej formy rozwoju wspomaganego SI – rozmywa to termin i usuwa rozróżnienie w kontroli, które ma znaczenie. Ustal prostą regułę: nie wypuszczaj tego, czego nie potrafisz wyjaśnić. I buduj kontrolę w projekcie w miarę jego rozwoju, warstwa po warstwie, dodając kontrole w rytmie pojawiających się ryzyk.

AI może napisać większość kodu. Nie może wziąć odpowiedzialności za jego wypuszczenie. To nadal należy do nas.