Vibe Coding podbija rynek, ale odpowiedzialność człowieka jest ważniejsza niż kiedykolwiek

Termin Vibe Coding, który Andrej Karpathy 2 lutego 2025 roku wykorzystał w publikacji na platformie X, stał się po kolei nazwą trendu, hasłem nowego kursu w programowaniu, Collinsowym Słowem Roku 2025 i w końcu problemem działów bezpieczeństwa.

W rozmowie z ITwiz Judyta Nowak, Team Leader i Senior Software Consultant oraz Łukasz Parczewski, Managing Delivery Architect w Capgemini Polska, tłumaczą, gdzie kończy się eksperyment, a zaczyna inżynieria oprogramowania oraz czym grozi zbytnie poleganie na samym automatycznym kodowaniu.

Andrej Karpathy opisał Vibe Coding jako sytuację, w której „poddajesz się nastrojom (vibe’om – przyp. red.), zapominasz, że kod w ogóle istnieje i akceptujesz zmiany bez czytania diffów”. Sam zastrzegł, że to formuła na „weekendowe prototypy”. Ale ludzie za bardzo kochają szybkość i wygodę, stąd coś, co miało być czymś raczej hobbystycznym, stało się biznesową codziennością. Dlatego rok później mówił już o Agentic Engineering. Agent jest omylny i stochastyczny, a jakość, bezpieczeństwo i utrzymanie zostają po stronie człowieka. Automat jednak wszystkiego sam dobrze nie zrobi.

Judyta Nowak i Łukasz Parczewski opisują dzisiejsze realia vibe-kodowania w organizacji, która pracuje głównie w środowiskach regulowanych. Tłumaczą oni, gdzie kończy się eksperyment, a zaczyna inżynieria i dlaczego klientowi mniej zależy na tym, czy kod napisał model, niż na tym, kto pod nim się podpisze. W takich warunkach „oddanie kontroli modelowi” nie powinno być brane pod uwagę.

Od promptu do „ciemnej fabryki”

W pierwotnej wersji Vibe Coding to prompt, potem kawa, a w międzyczasie oczekiwanie, aż aplikacja sama powstanie. Łukasz Parczewski porównuje to do zamówienia ostrej kuchni chińskiej: „Na kolację ze znajomymi można zaryzykować „niespodziankę”, co może być elementem pewnej wartości dodanej – dreszczyku emocji. Ale co, jeśli danie ma trafić na duży stół, do większej grupy zewnętrznych klientów? Trzeba wiedzieć, z czego powstało, czy jest zdrowe, a na koniec, kto ewentualnie za nie odpowiada, jeśli któryś z gości trafi do szpitala”
– stwierdził.

Ta analogia dobrze oddaje, jak ewoluowało pojęcie Vibe Coding. Najpierw był niekontrolowany eksperyment. Potem pojawił się Context Engineering – świadome budowanie kontekstu, z którego korzystają GitHub Copilot, Claude Code, a także instrukcje w repozytorium czy pliki typu CLAUDE.md. W im większym stopniu zespoły pracują w ten sposób, tym bardziej proces da się zautomatyzować i tym mocniej da się go kontrolować.

Na końcu tej drabiny ewolucji pojawia się retoryka dark factory (produkcji bez udziału ludzi, a więc i potrzebnego ludziom światła, działającej w ciemności). Człowiek definiuje wymagania, a „fabryka agentów” produkuje oprogramowanie samodzielnie, aż po testy i wdrożenie. Człowiek nie stoi już przy taśmie. Pozostaje w roli Demiurga uruchamiającego samoistne procesy.

W przemyśle, zwłaszcza w Chinach, fabryki bez ludzi naprawdę istnieją. W przypadku oprogramowania – zdaniem przedstawicieli Capgemini – pełna autonomia to obecnie raczej hasło sprzedażowe niż stan faktyczny.

„Coraz więcej przedsiębiorstw wskazuje poziom swojej dojrzałości jako odpowiadający etapowi fabryki AI, gdzie agenci generują kod od wymagań aż po produkcję. Z naszego doświadczenia w środowiskach regulowanych wygląda to inaczej: człowiek weryfikuje każdy krok i decyduje, czy output AI może pójść dalej” – mówi Łukasz Parczewski.

„Sam autor pojęcia odszedł od własnej radykalnej definicji. Ludzie mają definiować wymagania oraz nadzorować i testować to, co wygenerował model. Minęły już czasy bezgranicznego zaufania i pomijania analizy diffów, bo takie podejście może mieć poważne konsekwencje. Jest to inżynieria realizowana z agentami, a nie oddanie kluczy stażystom – agentom AI” – dodaje Judyta Nowak.

Andrej Karpathy sam zresztą porównywał dzisiejszych agentów do stażystów. Bywają szybcy i pomocni, ale też niespójni, gadatliwi w kodzie i skłonni do nieoczywistych skrótów.

Różnica jak ze starego dowcipu, między teoretycznie a praktycznie, jeszcze nigdy nie była tak wyraźna i widoczna. Teoretycznie każdy może dziś „zostać programistą”, zlecić modelowi napisanie aplikacji, a wkrótce nawet nie będzie musiał pisać promptu, bo wystarczy wydanie polecenia głosowego.

Skala zjawiska i gdzie statystyki się rozjeżdżają

Vibe Coding nie jest już niszowym eksperymentem dla weekendowych hobbystów. Rynek narzędzi łączonych z tym trendem szacuje się na ok. 4,7 mld USD w roku 2026, przy wzrostach rzędu 38% rocznie. W materiałach branżowych można przeczytać, że 92% deweloperów w USA korzysta z AI do kodowania codziennie.

Twarde badania są nieco ostrożniejsze. Stack Overflow Developer Survey 2025 podaje, że 84% deweloperów używa lub planuje użyć narzędzi AI, ale bliżej 50% wykorzystuje je w codziennej praktyce. Jet Brains w 2026 roku raportował już bardzo wysokie użycie agentów kodujących w cyklu tygodniowym. Różnice wynikają z tego, czy pytamy o „kiedykolwiek”, „co tydzień”, czy „codziennie” oraz czy próbie poddane są startupy, czy banki.

Podobnie jest z udziałem kodu. Często przywoływane 41% to zwykle kod „dotknięty” albo wspomagany przez AI, niekoniecznie w całości przez niego napisany. Sonar – w badaniu z początku 2026 roku – mówił o 42% committowanego (wprowadzonego do repozytorium – przyp. red.) kodu jako generowanego lub asystowanego.

Rygorystyczne pomiary kodu w pełni autorstwa modeli schodzą zwykle do przedziału 22-29%. Różnica między asystą a autorstwem nie jest kosmetyczna. W startupach, zwłaszcza tych z ostatnich naborów Y Combinatora, ten udział bywa znacznie wyższy. Pojawiały się deklaracje, że 95% kodu aplikacji pochodzi z modeli LLM. To zupełnie inny poziom niż bankowe systemy transakcyjne.

Mimo że bez doświadczonego programisty Vibe Coding obarczony jest dużym ryzykiem, to obecnie aż 63% osób zajmujących się nim nie jest programistami. Takie proporcje dotyczą zwłaszcza platform typu Lovable, Bolt, Replit czy v0. Narzędzia typu Copilot i Cursor wciąż obsługują przede wszystkim zespoły inżynierskie. Zatem z jednej strony demokratyzacja wytwarzania oprogramowania jest realna i wyraźnie widoczna (choć kursy dla Vibe Coderów nie należą do najtańszych i obiecują zielone buildy na GitHubie już po wprowadzeniu kilku ustawień), ale z drugiej – demokratyzacja odpowiedzialności już niekoniecznie.

Kiedy produkt trafia do klienta, odpowiedzialność wciąż ponosi człowiek. Jeśli rozwiązanie nie działa, osoba znająca jedynie podstawy Vibe Codingu nie będzie w stanie ani zagwarantować bezpieczeństwa kodu, ani skutecznie usunąć problemu.

Już prawie co drugi fragment kodu z luką

Raport Veracode „2025 GenAI Code Security Report” potwierdza to, o czym Judyta Nowak i Łukasz Parczewski rozmawiali w podcaście i potwierdzali liczbami, których nie da się zbyć byle anegdotą. Ponad 100 modeli otrzymało 80 zadań, w których mogły wybrać implementację bezpieczną albo podatną. Model otrzymywał kod z luką do wypełnienia oraz neutralny opis funkcji, projektował kod, który następnie był weryfikowany narzędziem Veracode SAST. W ten sposób sprawdzono, czy wybrana implementacja zawierała znane błędy lub podatności. I tak, w 45% przypadków modele AI, realizując postawione im zadanie, wprowadziły do istniejącego kodu lukę z listy OWASP Top 10. Dla Javy (języka wciąż kluczowego w aplikacjach komercyjnych) odsetek ten wyniósł ok. 72%. Python, C# i JavaScript plasowały się w przedziale 38-45%. Najgorzej modele radziły sobie z XSS i log injection (odpowiednio: 86% i 88% nieudanych prób obrony).

Judyta Nowak zwraca uwagę na coś, co w marketingu narzędzi AI zwykle umyka. Modele LLM może i są coraz bardziej rozbudowane, w domyśle „inteligentne”, ale nie przekłada się to na poziom cyberbezpieczeństwa. Kolejna edycja badania Veracode z 2026 roku pokazała praktycznie płaski wskaźnik poziomu bezpieczeństwa. Modele urosły, składnia jest niemal zawsze poprawna, ale odsetek luk prawie się nie zmienił (ok. 55-56% „czystych” próbek wobec 55% rok wcześniej). Większy model nie tylko nie oznacza bezpieczniejszego kodu, ale też szybsze mnożenie tego samego ryzyka.

Do podatności dochodzi kwestia rozpoznawalnego „looku” kodu aplikacji z Vibe Codingu. Wygląda tak charakterystycznie, że często nie trzeba nawet otwierać repozytorium, by to potwierdzić. Frontend powtarza te same wzorce. Komponenty korzystają z różnych bibliotek w odniesieniu do tego samego zadania. Brakuje wspólnej abstrakcji. Kodu jest zdecydowanie za dużo.

Doświadczona osoba wykonująca code review widzi to od razu, podobnie jak czytelnik LinkedIna szybko rozpoznaje typowy AI slop. Łukasz Parczewski podkreśla też tego nieoczywistą konsekwencję.

„Nawet jeśli ‘jakoś to działa’, to bez ludzkiej interwencji otrzymujemy ‘osiedle’ zbudowane przez wielu autorów bez wspólnego planu, na którym każdy pobiera wodę i prąd na własną rękę. Początkowo takie osiedle sprawia wrażenie dobrze funkcjonującego, jednak w dłuższej perspektywie staje się niezwykle trudne i kosztowne w utrzymaniu” – mówi.

Przegląd takiego kodu trwa dłużej, bo materiału jest więcej, a spójności mniej. „Kod można wygenerować w kilka minut, lecz jego wdrożenie w regulowanej organizacji nadal wymaga wielu tygodni, a niekiedy miesięcy pracy. Paradoksalnie zdarza się, że wykorzystanie AI nie przyspiesza tego procesu, a wręcz go wydłuża” – stwierdza Łukasz Parczewski. To niewygodna uwaga dla narracji o 10-krotnym przyspieszeniu prac dzięki Vibe Coding. Ale w regulowanym środowisku Enterprise jest często bliższa prawdy.

Wąskim gardłem nie jest już samo napisanie funkcji, ale udowodnienie, że można ją bezpiecznie wpuścić na produkcję.

Kto odpowiada za produkt wdrażany przez osobę, która nie jest programistą?

Ktoś buduje aplikację za pomocą promptów, wdraża ją, a czasem nawet sprzedaje. Dopiero po kilku dniach ujawniają się jednak luki i błędy. Kiedy klient wraca z reklamacją, okazuje się, że twórca nie rozumie kodu, ponieważ sam go nie napisał, a często nie potrafi go nawet „odczytać”. Testy świecące się na zielono, wygenerowane przez ten sam model, nic nie mówią. A nie mówią, bo testują najbezpieczniejszy scenariusz, nie atak i nie przypadek brzegowy.

Judyta Nowak zauważa, że to jeszcze stosunkowo dobra sytuacja, jeśli ktoś w ogóle się pod produktem podpisał. Gorzej, gdy odpowiedzialność rozmywa się w formule „zrobiło to AI”. Dlatego Łukasz Parczewski podkreśla: „Demokratyzacja wytwarzania nic nie zmieniła w regule odpowiedzialności. Autor produktu odpowiada za to, co trafia do klienta, nawet jeśli napisał to model LLM”.

W środowiskach regulowanych klient nie kupuje więc kodu „z garażu”. Specjaliści Capgemini korzystają z AI, ale w trybie inżynierii AI. Człowiek decyduje o architekturze i o tym, czy dany output idzie dalej. Obserwacja Łukasza Parczewskiego jest praktyczna. „Już przy 20-30-proc. udziale AI w procesie widać, że trzeba przebudować sam sposób wytwarzania oprogramowania. Nie po to, aby wyłączyć modele, tylko po to, by dodać je bez utraty kontroli” – uczula.

Mimo to, klienci rzadko pytają, czy rozwiązanie powstało na podstawie Vibe Codingu. Nie musi. Odpowiedzialność spoczywa na dostawcy. Dlatego klienci częściej pytają o wartość biznesową i o to, kto poniesie odpowiedzialność, gdy coś pójdzie nie tak. Korzystanie z narzędzi AI przy pisaniu kodu nie zwalnia z odpowiedzialności i podpisu: dewelopera, testera, Product Ownera. Łańcuch odpowiedzialności pozostaje ludzki, nawet jeśli dźwięków klawiatury już nie słychać tak wyraźnie jak kiedyś.

Zaufanie do agentów spada, zapotrzebowanie na człowieka rośnie

Z raportu Capgemini Research Institute „Rise of agentic AI” (lipiec 2025, oparty na badaniu 1500 przedstawicieli kadry kierowniczej z 14 krajów) wynika, że aktualny łańcuch procesowy nie zniknie szybko. Zaufanie do w pełni autonomicznych agentów spadło z 43% do 27% w ciągu roku!

Na pełną skalę agentów AI wdrożyło 2% organizacji, częściowo 12%. W pilotażach jest to 23%, a 61% firm wciąż tylko eksploruje temat. To znaczy, że aż 71% firm „nie ufa w pełni autonomicznym agentom”. Hype na „łatwo i szybko” się zmniejszył, a świadomość problemu rośnie.

Dodatkowe obawy budzą przypadki, w których autonomiczne agenty AI realizowały zadania w sposób nieprzewidziany przez ich twórców lub przekraczały założone granice działania. Takie sytuacje pokazują, że modele potrafią interpretować cele na własny sposób, co wzmacnia potrzebę ostrożności przy powierzaniu im odpowiedzialnych zadań. Nie był to klasyczny „zły prompt od stażysty”. Agenci zinterpretowali cel ewaluacji na własny sposób i poszli „na skróty”. Tak będzie za każdym razem, ponieważ – jak opisujemy w najnowszym wydaniu magazynu ITwiz 7-8/2026 – modele AI nie kierują się ludzkimi wartościami czy intencjami, dlatego w pewnych warunkach mogą wybierać działania, które maksymalizują realizację celu, nawet jeśli są one niepożądane z perspektywy użytkownika.

Na ten moment człowiek musi czuwać nad każdym wynikiem pracy LLM i opartych na nim agentów. Łukasz Parczewski rozróżnia dwa podejścia. „Jeśli błędny wynik agenta nic nas potencjalnie nie kosztuje – można zaakceptować eksperymentowanie i niepewność, nawet na produkcji. Jeśli jednak chodzi o pieniądze lub reputację, kończy się zabawa i zaczyna inżynieria: wymagania, guardrails i człowiek u bramy” – doradza.

Dyscyplina zamiast poddawania się nastrojowi

Promptowanie głosowe, o którym mówi się jako o kolejnej fali Vibe Codingu, już działa w narzędziach z transkrypcją. Nie zmienia to jednak sedna problemu. Im mniejszą wiedzę o kodzie ma zespół, tym trudniej utrzymać aplikację przez pięć czy dziesięć lat. AI zazwyczaj generuje znacznie więcej kodu niż programista realizujący ten sam zakres funkcjonalny. Dług techniczny nie znika, zmienia jedynie swoją formę. Rozlewa się w zależnościach, które model dodał „na zapas”, i w komponentach, które nie mają wspólnej logiki, tylko kopiują ją w trzech stylach naraz.

Dla osób, które chcą sprzedawać produkty powstałe z pomocą Vibe Codingu AI, Judyta Nowak i Łukasz Parczewski mają listę rekomendacji.

1. Spisać wymagania biznesowe, zanim powstanie linia kodu. Świadomość tego, co aplikacja ma robić, a czego ma nie robić, jest jedynym sensownym wejściem do rozmowy z modelem. Bez tego prompt jest tylko życzeniem, a nie specyfikacją.

2. Znać podstawy języka i architektury na tyle, by widzieć, gdzie jest backend, jak płyną dane między warstwami i które zależności są zbędne. Nie trzeba być seniorem z 10-letnim stażem. Trzeba umieć odróżnić przepływ, który ma sens, od przepływu, który model złożył, bo tak wyglądały przykłady w danych treningowych.

3. Testować przypadki negatywne, nie tylko zielone ścieżki. Judyta Nowak wyraźnie oddziela testy jednostkowe wygenerowane przez AI, które same potrafią być nadto optymistyczne, od analizy wymagań i scenariuszy, w tym potencjalnego ataku, błędu użytkownika oraz niespójnych danych. Zasadę, że zielone światełko na GitHubie nie jest dowodem bezpieczeństwa, należy zapamiętać i powtarzać jak mantrę.

4. Sprawdzać determinizm. Ten sam scenariusz powinien dawać ten sam wynik. LLM jest probabilistyczny. Potrafi za każdym razem ułożyć inną odpowiedź na to samo pytanie i tę samą niekonsekwencję włożyć w kod. Stąd halucynacje, na których boleśnie uczyły się m.in. kancelarie prawne. Podstawowa prawda jest taka, że model nie pamięta faktów, a tylko dopasowuje ciąg tokenów.

Łukasz Parczewski podkreśla, że testów nie da się zastąpić kolejnym poleceniem do modelu. Nawet przy tradycyjnym programowaniu nigdy nie da się sprawdzić wszystkich możliwych sytuacji. Przy kodzie pisanym przez AI tych sytuacji jest więcej, a zrozumienia kodu mniej. W branżach objętych regulacjami Capgemini mówi o uporządkowanej inżynierii z udziałem AI: od wymagań, przez plan i architekturę, po implementację i wdrożenie, z kontrolą na każdym kroku.

Agent może zaplanować pracę, ale człowiek ocenia, czy sam zrobiłby to tak samo. Dopiero wtedy kolejny agent dostaje zadanie implementacji i znowu następuje ocena. Potrzebne są też ograniczenia dla modeli, porządne dane, infrastruktura i jasne procesy. Raport Capgemini Research Institute „Rise of agentic AI” pokazuje, że właśnie tego większości firm brakuje, dlatego ponad 50% zostaje na etapie eksperymentów.

Tworzenie oprogramowania „na wyczucie” obniża próg wejścia. Więcej osób jest w stanie coś złożyć i szybciej sprawdzić, czy pomysł w ogóle działa. Ma to sens przy prototypie i przy narzędziu, z którego korzysta tylko autor. Tam gdzie kod ma żyć latami, a w grę wchodzą pieniądze, dane osobowe i nadzór, niezbędna jest inżynierska dyscyplina – także wtedy, gdy piszą kod agenci AI. Jest bowiem zasadnicza różnica między czymś, co działa w teorii, do czasu, ale powstało szybko i tanio, a produktem, pod którym ktoś naprawdę się podpisze i ten podpis potem obroni.