18 czerwca brytyjski National Cyber Security Centre — część agencji wywiadu sygnałowego GCHQ — opublikował wpis „The 'vibe coding spectrum' approach to AI-assisted software development", ostrzegający, że vibe coding, czyli pisanie oprogramowania przez AI z minimalnym nadzorem człowieka, może mieć katastrofalne skutki dla bezpieczeństwa. W tym tygodniu, około 22 czerwca, materiał odbił się szerokim echem w mediach branżowych — i słusznie, bo to nie jest panika ani zakaz, lecz coś bardziej wartościowego: rządowa agencja kalibruje, kiedy oddawanie kodu AI jest rozsądne, a kiedy lekkomyślne.
Dla cyberflux to jest moment domykający najważniejszy wątek tego roku. Przez miesiące opisywaliśmy AI po stronie znajdowania błędów — Codex znajdujący HTTP/2 Bomb, 429 łatek Chrome z AI-fuzzingu, dwuletni błąd w Redisie. NCSC nazywa teraz drugą stronę tego samego medalu: AI nie tylko znajduje błędy. Pisząc kod bez nadzoru, równie skutecznie je tworzy.
Sednem nie jest „nie używaj" — jest „gdzie na spektrum"
Najważniejsze w stanowisku NCSC jest to, czego ono nie mówi. Agencja nie odradza vibe codingu. Mówi wprost: czy to znaczy, że nie powinieneś używać vibe codingu? Niekoniecznie — zależy od tego, co budujesz.
I tu jest kluczowy niuans, który gubi większość omówień, a który jest sednem oryginału: NCSC nie ujmuje tego jako wyboru zero-jedynkowego, ale jako spektrum. Na lewym końcu — ręczne pisanie kodu z asystą AI: autouzupełnianie w IDE, które akceptujesz tabem albo nie, pełna kontrola człowieka, AI tylko podpowiada. Na prawym końcu — pełny vibe coding: dajesz wysokopoziomowy, czasem niejednoznaczny prompt, a AI ma autonomię nad architekturą, kodem, modułami i testami; nie edytujesz ani nie czytasz dogłębnie kodu, tylko oceniasz wynik i promptujesz dalej. Zalecenie brzmi: zastanów się, co budujesz, zrozum ryzyko i przesuń się po tym suwaku odpowiednio.
NCSC podaje konkretne kotwice na obu końcach. W stronę „pełnego vibe" przesuwasz się, gdy budujesz prototypy lub proof-of-concept, gdzie liczy się szybkość, albo wewnętrzne narzędzie dla zespołu o ograniczonym ryzyku. W stronę pełnej kontroli — gdy piszesz logikę uwierzytelniania dla publicznej strony, kod przetwarzający wrażliwe dane klientów, cokolwiek obsługującego tajne tokeny lub poświadczenia, albo kod krytyczny dla bezpieczeństwa w systemie infrastruktury krytycznej czy odpowiedzialny za sterowanie samolotem. Konsekwencje błędu bezpieczeństwa w tych obszarach bywają poważne: wycieki danych, przejęte konta, naruszenia regulacyjne albo gorzej.
Sami autorzy ujmują to jednym zdaniem: ryzyko nie leży w używaniu AI. Ryzyko leży w niezastosowaniu właściwych zabezpieczeń, gdy stawka jest wysoka. Chodzi o rozpoznanie, że różny kod zasługuje na różny poziom troski i nadzoru.
Jest jeszcze drugie, subtelniejsze zagrożenie, które NCSC wskazuje, a które łatwo przeoczyć. Baza kodu aplikacji może stać się skomplikowana i trudna do zrozumienia, prowadząc do dalszych problemów z utrzymaniem w przyszłości. To nie jest o pojedynczym błędzie. To jest o tym, że kod, którego nikt do końca nie rozumie — bo napisała go AI, a człowiek tylko zaakceptował wynik — staje się długiem technicznym, który kumuluje ryzyko. Nie da się zabezpieczyć tego, czego się nie rozumie.
Zdanie, które jest sednem
NCSC kończy myślą, którą warto zapamiętać bardziej niż jakiekolwiek konkretne ostrzeżenie. Modele AI szybko się poprawiają — możliwe, że z czasem będziemy ufać vibe codingowi bardziej, w miarę jak staną się bardziej niezawodne, a ich wyniki bardziej godne zaufania. Spektrum może się przesunąć; to, co dziś wydaje się ryzykowne, za rok może być rutyną. Ale jeszcze tam nie jesteśmy. Kalibruj swoje podejście według dzisiejszej rzeczywistości, nie jutrzejszego potencjału.
To jest najlepsze jednozdaniowe ujęcie problemu, jakie padło w tej dziedzinie. Cała dyskusja o AI w bezpieczeństwie jest skażona myleniem tego, co modele będą potrafić, z tym, co potrafią dziś. Entuzjaści projektują na kod produkcyjny zdolności, których modele jeszcze nie mają. NCSC mówi: oceniaj narzędzie po tym, czym jest teraz, nie po tym, czym może się stać — i bądź gotów przesunąć suwak, gdy rzeczywistość faktycznie się zmieni, nie wcześniej. To jest ta sama dyscyplina epistemiczna, którą staraliśmy się utrzymać przy całej serii Mythos — oddzielać diagnozę od histerii, mierzyć rzeczywistość, nie projekcję.
Dlaczego to domyka nasz wątek roku
Warto zobaczyć to ostrzeżenie w kontekście tego, co opisywaliśmy — bo dopiero wtedy widać, że NCSC zamyka pętlę.
Pokazywaliśmy AI jako narzędzie obrońcy znajdujące błędy szybciej niż człowiek. Pokazywaliśmy AI jako narzędzie atakującego, które z publicznej łatki buduje exploit. Pokazywaliśmy nawet vibecoded exploit, który atakujący napisał AI i który działał wadliwie — dowód, że AI obniża barierę także dla niekompetentnych. NCSC dorzuca brakujący element: AI pisząca kod produkcyjny wprowadza podatności na taką samą skalę, na jaką inna AI je znajduje.
To zamyka obraz w niepokojącą symetrię. Po jednej stronie maszyny generują kod z prędkością, której człowiek nie dorówna. Po drugiej te same albo inne maszyny ten kod skanują i znajdują w nim dziury. NCSC zauważa rzecz, która to spina: wskaźnik defektów na linię kodu pozostaje zasadniczo stały, ale ilość kodu źródłowego w systemach rośnie. Jeśli odsetek błędów się nie zmienia, a kodu jest gwałtownie więcej — bo AI go produkuje szybciej — to całkowita liczba podatności rośnie. To jest matematyczne źródło „patch wave", przed którą NCSC ostrzegała już w maju, i którą rekord 429 łatek Chrome zilustrował w praktyce.
Spójna linia, nie jednorazowy alarm
Warto odnotować, że to ostrzeżenie nie jest odosobnione — wpisuje się w konsekwentną linię NCSC ciągnącą się od wiosny, co dodaje mu wagi i pokazuje, że to przemyślane stanowisko, nie reakcja na pojedyncze wydarzenie.
W marcu, na konferencji RSAC, szef NCSC Richard Horne wezwał branżę, by potraktowała eksplozję vibe codingu jako szansę na bezpieczniejsze oprogramowanie — pod warunkiem wbudowania zabezpieczeń od początku. Jego argument był wyważony: skoro ręcznie pisane oprogramowanie jest „konsekwentnie podatne", to dobrze wytrenowane narzędzie AI piszące kod bezpieczny z założenia mogłoby odmienić wyniki bezpieczeństwa na lepsze. Ale dodał warunek: narzędzia AI muszą być projektowane i trenowane od samego początku tak, by nie wprowadzać ani nie propagować niezamierzonych podatności.
CTO NCSC sformułował wtedy serię „przykazań" dla bezpiecznego vibe codingu, które warto znać, bo są konkretne: wbudować w narzędzia praktyki bezpieczne z założenia, by AI generowała utwardzony kod od razu; przyjąć podejście „ufaj, ale weryfikuj" z dowodliwym pochodzeniem modelu, by wykluczyć złośliwe backdoory; używać AI do audytu całego kodu — i ludzkiego, i tego pisanego przez AI; oraz egzekwować deterministyczne zabezpieczenia ograniczające, co kod może zrobić, nawet jeśli jest złośliwy lub niebezpieczny.
To ostatnie jest najgłębsze i warte podkreślenia. NCSC pyta wprost: jak użyć deterministycznej architektury — znanych kontroli zaimplementowanych w regułach i kodzie — by ograniczyć, co kod może zrobić, zamiast oczekiwać, że jedna AI ograniczy drugą AI? To jest dokładnie ten sam wniosek, do którego doszedł OWASP i który powtarzaliśmy przy Agentjacking: nie da się zabezpieczyć AI inną AI proszoną o pilnowanie. Jedyną twardą granicą są deterministyczne kontrole — reguły i kod, które fizycznie ograniczają, co system może zrobić, niezależnie od tego, co model „postanowi".
AI jako rozwiązanie, nie tylko problem
Jest w stanowisku NCSC element, który warto wydobyć, bo równoważy ostrzeżenie i jest praktycznie użyteczny: ta sama AI, która tworzy ryzyko, jest też częścią rozwiązania.
NCSC wskazuje konkretne, pozytywne zastosowania. Zdolność użycia AI do utwardzenia hostingu lub kodu starszej — nawet wycofanej z użycia — krytycznej aplikacji spłaciłaby dużo długu technicznego i bezpieczeństwa, który organizacja dźwiga. AI może pomagać w higienie bezpieczeństwa: od drobnych zadań, jak utrzymywanie listy dozwolonych URL-i, z którymi aplikacja może się komunikować, po większe, jak przepisanie krytycznych komponentów w języku bezpiecznym pamięciowo albo we frameworku chroniącym przed typowymi błędami z założenia.
To jest ważne zrównoważenie. NCSC nie mówi „AI psuje kod, trzymaj się z dala". Mówi: AI pisząca kod bez nadzoru wprowadza ryzyko, ale AI używana świadomie — do audytu, utwardzania, przepisywania legacy, pilnowania higieny — może spłacić dług bezpieczeństwa nagromadzony przez dekady. CTO podkreśla, że trzeba zacząć wdrażać te zabezpieczenia teraz, bez czekania pięciu lat na „wibracyjną przyszłość". Różnica między dobrym a złym użyciem nie leży w samym narzędziu, ale w tym, czy człowiek zachowuje nadzór i gdzie na spektrum świadomie się ustawia.
Co zrobić
Pozycjonuj się na spektrum według profilu ryzyka, nie według entuzjazmu. Proof-of-concept dla interesariuszy albo wewnętrzne narzędzie o niskim ryzyku — możesz przesunąć się w stronę pełnego vibe. Logika uwierzytelniania, kod dotykający wrażliwych danych, obsługa poświadczeń, systemy krytyczne — przesuń się ku pełnej kontroli, z przeglądem i zrozumieniem tego, co AI napisała. To jest najprostsza i najważniejsza zasada z całego stanowiska NCSC.
Nie akceptuj kodu, którego nie rozumiesz. Drugie ostrzeżenie NCSC — o bazie kodu, która staje się niezrozumiała — jest często ważniejsze niż pojedynczy błąd. Jeśli zespół nie potrafi wyjaśnić, jak działa wygenerowany komponent, to jest dług, który kiedyś zostanie ściągnięty. Wymagaj, by kod pisany przez AI był przeglądany i rozumiany jak kod od juniora, którego się mentoruje, nie jak wyrocznia, której się ufa.
Używaj AI do audytu całego kodu — ludzkiego i maszynowego. To jest „przykazanie" NCSC, które warto wdrożyć od razu: skoro AI dobrze znajduje błędy, skieruj ją na własny kod, zanim zrobi to ktoś inny. To samo zalecenie, które płynęło z całej serii o AI-fuzzingu.
Buduj deterministyczne zabezpieczenia, nie polegaj na tym, że AI dopilnuje AI. Listy dozwolonych operacji, sandbox, kontrola tego, co kod może zrobić w czasie wykonania — to są twarde granice, które działają niezależnie od jakości wygenerowanego kodu. To ten sam wniosek, który powtarzaliśmy przy Claude Code, Gemini i AutoJack.
Przygotuj się na „patch wave". Jeśli AI produkuje więcej kodu przy stałym wskaźniku błędów, to więcej podatności — i więcej łatek do wdrożenia. Organizacje z automatyzacją łatania i bieżącym zarządzaniem podatnościami przejdą przez tę falę; te bez niej będą tonąć. To jest operacyjna konsekwencja, którą NCSC sygnalizuje od maja.
Źródła
NCSC — oryginalny wpis z 18 czerwca „The 'vibe coding spectrum' approach to AI-assisted software development": https://www.ncsc.gov.uk/blogs/the-vibe-coding-spectrum-approach-to-ai-assisted-software-development
Cybernews — omówienie z 22 czerwca z kluczowym cytatem o kalibracji według dzisiejszej rzeczywistości: https://cybernews.com/ai-news/britain-cyber-ai-code-security-disasters/
NCSC / IT Pro — analiza stanowiska o deterministycznych zabezpieczeniach i wskaźniku defektów na linię kodu: https://www.itpro.com/security/ncsc-warns-vibe-coding-poses-a-major-risk
Infosecurity Magazine (RSAC) — „przykazania" CTO NCSC dla bezpiecznego vibe codingu: https://www.infosecurity-magazine.com/news/rsac-uk-ncsc-urges-vibe-coding/
The Record — kontekst SaaSpocalypse i przewidywania NCSC o rynku oprogramowania: https://therecord.media/vibe-coding-uk-security-risk
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł