vibe coding

Vibe coding to tworzenie aplikacji albo stron przez opisywanie ich modelowi językowemu i przyjmowanie wygenerowanego kodu bez jego czytania. Termin wprowadził Andrej Karpathy w lutym 2025 roku; opisał styl pracy, w którym „zapomina się, że kod w ogóle istnieje” ^[1]. Simon Willison zawęża pojęcie do budowania oprogramowania z modelem bez przeglądania kodu, który model pisze ^[1]. Jeśli programista przejrzał kod, przetestował go i umie wyjaśnić, jak działa, to według Willisona jest to zwykłe tworzenie oprogramowania, a nie vibe coding ^[1].

Jak działa

Użytkownik opisuje zwykłym językiem, co program ma robić. Model odpowiada kodem, użytkownik go uruchamia, a gdy coś nie działa, wkleja modelowi komunikat błędu i prosi o poprawkę. Kryterium odbioru jest to, czy aplikacja działa, a nie to, czy jest poprawna i bezpieczna. Niebezpiecznik, prowadząc szkolenie z tej metody, zapowiada, że będzie zniechęcał do podejścia „YOLO vibecoder” ^[8].

Praca w tym trybie oznacza też stały przepływ danych do dostawcy modelu. Willison radzi zachować ostrożność przy danych prywatnych i wiedzieć, czy informacje opuszczają komputer użytkownika ^[1]. Theprotocol.it wylicza, co najczęściej trafia do modelu razem z kodem: klucze API, hasła, fragmenty danych osobowych używanych w testach, nazwy serwerów, wewnętrzne adresy IP i ścieżki plików ^[7]. Klucze i hasła to dane uwierzytelniające, które po wycieku dają bezpośredni dostęp do systemów.

Granicę między vibe codingiem a programowaniem wspomaganym przez AI wyznacza przegląd kodu, nie samo użycie modelu ^[1].

Zagrożenia i skutki

Błędy bezpieczeństwa w wygenerowanym kodzie. Veracode w raporcie z 30 lipca 2025 roku przetestował ponad 100 modeli językowych na zadaniach w Javie, Pythonie, C# i JavaScripcie ^[4]. W 45% próbek kod nie przeszedł testów bezpieczeństwa i wprowadzał podatności z listy OWASP Top 10 ^[4]. Przed XSS (Cross-Site Scripting) modele nie zabezpieczyły kodu w 86% próbek, których dotyczył ten test ^[4]. Raport odnotowuje też, że wyniki bezpieczeństwa nie poprawiały się wraz z rozmiarem modelu ^[4]. Theprotocol.it zwraca uwagę, że modele uczone na niesprawdzonych zbiorach powielają niebezpieczne wzorce, takie jak SQL injection, XSS czy hasła przechowywane otwartym tekstem ^[7].

Sekrety w kodzie. Willison przestrzega, że kto używa w projekcie sekretów, musi uważać, by ich przypadkiem nie ujawnić, a do tego trzeba rozumieć, jak działa kod ^[1]. Klucz API wklejony do skryptu po stronie przeglądarki to hasło zaszyte w kodzie, widoczne dla każdego odwiedzającego; zob. zarządzanie sekretami. Willison opisuje też przypadki, w których funkcja zbudowana tą metodą na płatnym API bez limitu wydatków wygenerowała rachunki na tysiące dolarów ^[1].

Zmyślone biblioteki. OWASP opisuje ryzyko, w którym model proponuje niebezpieczne albo nieistniejące biblioteki, a napastnik publikuje złośliwe pakiety pod nazwami, które modele często wymyślają ^[3]. Ten wariant ataku na łańcuch dostaw nazywa się slopsquatting. Zespół Spracklena przeanalizował 576 000 próbek kodu: odsetek zmyślonych pakietów wyniósł co najmniej 5,2% dla modeli komercyjnych i 21,7% dla otwartych, a badacze zebrali 205 474 unikalne zmyślone nazwy ^[2]. Przebieg ataku pokazuje schemat poniżej.

RYS. 1Zmyślony pakiet w projekcie vibe coding

W WordPressie

Na stronach WordPress vibe coding przybiera zwykle postać własnej wtyczki albo fragmentu kodu wklejonego do functions.php motywu. Taki kod ma te same obowiązki co każda wtyczka: dokumentacja WordPressa każe nie ufać danym od użytkownika, z zewnętrznych API ani nawet z bazy bez weryfikacji ^[5]. Dane wejściowe trzeba walidować i poddać sanityzacji, a dane wyjściowe escapować możliwie późno ^[5].

Szczególnie łatwo przeoczyć kontrolę uprawnień. Dokumentacja o nonce zaznacza, że nonce chroni między innymi przed CSRF (Cross-Site Request Forgery), ale nigdy nie może służyć do uwierzytelniania, autoryzacji ani kontroli dostępu; funkcje trzeba chronić wywołaniem current_user_can() ^[6]. Kod, który działa w teście administratora, może więc przepuszczać żądania subskrybenta, co daje brak kontroli uprawnień. Przykład obsługi formularza w panelu z wymaganymi sprawdzeniami:

check_admin_referer( 'zapisz_ustawienia' );          // nonce: ochrona przed CSRF
if ( ! current_user_can( 'manage_options' ) ) {      // uprawnienie, nie nonce
    wp_die( 'Brak uprawnień' );
}
$tytul = sanitize_text_field( wp_unslash( $_POST['tytul'] ?? '' ) );

Dobre praktyki

• Czytać każdą zmianę przed wdrożeniem i umieć ją wyjaśnić; to granica, którą wskazuje Willison ^[1].
• Sprawdzać w rejestrze każdą bibliotekę zaproponowaną przez model; OWASP zaleca niezależną weryfikację wygenerowanych treści i ustalone praktyki bezpiecznego programowania ^[3].
• Nie wklejać do rozmowy z modelem kluczy, haseł ani danych testowych z prawdziwymi danymi osobowymi; theprotocol.it wskazuje metadane i sekrety jako największe zagrożenie przy pracy z asystentem ^[7]. Niekontrolowane użycie narzędzi AI w firmie opisuje hasło shadow AI.
• Uruchamiać kod najpierw w środowisku testowym, a przed publikacją poddać go skanowaniu podatności.
• Dawać wygenerowanemu kodowi i kluczom API tylko te uprawnienia, których potrzebują, zgodnie z zasadą najmniejszych uprawnień.

Znaczenie

Vibe coding obniża próg wejścia: Niebezpiecznik reklamuje szkolenie jako sposób na tworzenie aplikacji z AI także przez osoby, które nie potrafią programować ^[8]. Ta sama cecha przenosi ryzyko na autora, który nie jest w stanie ocenić, co opublikował. Z punktu widzenia bezpieczeństwa kod z modelu jest kodem od nieznanego dostawcy i wymaga tej samej kontroli co wtyczka pobrana z niesprawdzonego źródła.