Vibe coding wkracza do akcji – jak AI zmienia zasady bezpieczeństwa aplikacji

Aplikację „napisała” sztuczna inteligencja, działa jak złoto, demo zachwyca. Tylko dlaczego anonim może właśnie skasować produkt w bazie bez logowania?

Vibe coding – tworzenie softu przez podpowiedzi dla agentów AI – pędzi jak TGV, ale z hamulcami od roweru. W styczniu 2026 pojawiły się analizy pokazujące, że vibowane aplikacje są pełne wtop w logice uprawnień i biznesie, a eksperci ostrzegają przed „wybuchami” w produkcji w 2026 roku. Przy takiej skali adopcji pytanie nie brzmi czy, tylko kiedy i gdzie to strzeli.

Warto się zatrzymać, bo ten trend nie jest niszą. Narzędzia AI do kodowania są już powszechnie używane, a vibe coding demokratyzuje tworzenie aplikacji poza działami IT. To przyspiesza wdrożenia i obniża koszty, ale też wynosi na produkcję kod bez recenzji, testów i podstawowych zabezpieczeń. Ryzyko jest realne: od wycieku danych, przez naruszenia zgodności, po zwykłe „zbrickowanie” biznesu. [7]

O co w ogóle chodzi

Vibe coding przenosi rolę programisty z klepiącego kod na reżysera: opisujesz, co chcesz, a agent tworzy aplikację. Termin spopularyzował Karpathy – i nieprzypadkowo. To jest wygodne, często działa, czasem wręcz imponująco. Problem? AI optymalizuje pod „działa”, nie pod „działa bezpiecznie”. [7]

Na chłodno: co faktycznie przecieka

Ori David z Tenzai poprosił pięć agentów (m.in. Cursor, Claude Code, Replit, Devin, Codex) o zbudowanie trzech aplikacji z tych samych promptów. Każda implementacja miała podobną liczbę usterek, a niektóre – w tym Claude, Devin i Codex – generowały błędy krytyczne. Klasyczna wpadka: endpoint kasowania produktu w e-commerce. Jeśli użytkownik był zalogowany, kod sprawdzał, czy ma prawo do usunięcia. Jeśli nie był? Żadnych kontroli – rekord znikał. W testach „happy path” wszystko wyglądało poprawnie. Do czasu.

Agenci byli względnie odporni na oczywiste klasy błędów (SQLi, XSS), ale słabo radzili sobie z autoryzacją i logiką biznesową. Większość pozwalała zamawiać ujemną liczbę sztuk albo ustawiać ujemne ceny. Do tego dochodził SSRF i brak podstawowych nagłówków bezpieczeństwa. Innymi słowy: mniej „hakerskich sztuczek”, więcej banalnych, ale zabójczych dziur w fundamentach.

To nie tylko błąd maszyn

” W 2026 będzie dużo vibowanych aplikacji w produkcji – świetnie dla prędkości, kiepsko dla bezpieczeństwa. Będą duże eksplozje” – przewiduje David Mytton z Arcjet. Czy porównania są przesadzone? Być może. Ale mechanika ryzyka jest banalna: więcej linii kodu powstaje szybciej, mniej ludzi rozumie, co faktycznie robią.

Warto też odróżnić korzystanie z asystenta w IDE od vibe codingu. To pierwsze stało się normą, to drugie bywa pełnym oddaniem sterów. Tam, gdzie AI jest redaktorem – pomaga. Gdy jest „autorem i architektem” – lubi minąć się z intencją.

Gdzie vibe coding ma sens, a gdzie prosi się o kłopoty

Mytton stawia rozsądne granice: świetne do prototypów „na wyrzucenie”, drobnych edycji i implementacji w dobrze opisanych ramach (testy, sprawdzone SDK). Zła idea: wymyślanie bezpieczeństwa od zera. „Nie pisz własnej kryptografii” to mantra, która w erze AI nabiera nowego znaczenia – niech AI sięga po walidowane biblioteki z dorobkiem zamiast składać własne protezy.

Techniczne detale też mają znaczenie. Silnie typowane języki zwiększają tarcie – kompilator częściej przerwie bzdurę zanim trafi na produkcję. A jeśli idziesz w dynamiczne stacki, zapłacisz testami end-to-end i monitoringiem. Tak czy inaczej: ktoś musi rozumieć, co wraca z prompta i jak to przetestować.

Co z tym zrobić teraz, nie „kiedyś”

• Traktuj AI jak junior developera. Review, statyczna analiza, testy, przeglądy parzyste. Szybko generuje, ale nie ma intuicji seniora.
• „Shift left” naprawdę. Wymagaj bezpieczeństwa w promptach i w architekturze. AI nie dołoży go, jeśli nie poprosisz – a nawet wtedy trzeba zweryfikować.
• Ogranicz blast radius. Zaczynaj od projektów niekrytycznych, dziel na małe, testowalne moduły, pilnuj uprawnień agentów (żadnego „roota” na pałę).
• Używaj sprawdzonych komponentów. OAuth z biblioteki zamiast własnego „tokenika”, rate limiting z battle-tested SDK, a nie regex z kapelusza.
• Doceniaj compliance. Vibe-kodowane projekty klasyfikuj, dokumentuj źródła danych i licencje, opisuj przepływy.

Lekcja z ostatnich miesięcy jest przyziemna, za to kosztowna: gdy oddajesz stery, oddajesz też odpowiedzialność. Aplikacje budowane „na vibe” często „działają„, ale to tylko przystanek. Pytanie brzmi, jak i kiedy padną – i kogo pociągną za sobą.

Podsumowanie

Vibe coding zostanie. To druga rewolucja „no-code”, tym razem dużo potężniejsza. Daje prędkość i demokratyzuje tworzenie. Ale w bezpieczeństwie prędkość bez kontroli to po prostu szybka porażka. Jeśli chcesz czerpać zyski, ustaw barierki: minimalne uprawnienia, testy, recenzje, gotowe komponenty i świadomość compliance.

FAQ

Czy vibe coding da się stosować bezpiecznie w produkcji?

Tak, ale tylko z mocnymi barierkami: code review, testami E2E, minimalnymi uprawnieniami i gotowymi komponentami bezpieczeństwa. Bez tego ryzyko jest nieakceptowalne.

Kiedy warto użyć vibe codingu, a kiedy unikać?

Warto przy prototypach do wyrzucenia, drobnych zmianach i implementacji w ramach z testami. Nie warto w krytycznych ścieżkach (autoryzacja, płatności, kryptografia) bez nadzoru seniora.

Czy AI potrafi wykryć własne błędy bezpieczeństwa?

Czasem tak, ale nie w sposób gwarantowany. Traktuj AI-audyt jako uzupełnienie, nie substytut SAST/DAST, przeglądów i testów.

Jak testować aplikacje stworzone przez agenta AI?

Najpierw automaty (unit/integration), potem E2E na realistycznych przypadkach, szczególnie logika uprawnień i granice (ujemne ilości, limity, błędne stany). Testy muszą pokrywać misuse, nie tylko happy path.

Czy język programowania ma znaczenie dla bezpieczeństwa vibowanego kodu?

Tak. Silnie typowane języki i rygorystyczne kompilatory zawężają klasę błędów, ale nie zwalniają z testów i review. W dynamicznych stackach tym bardziej potrzebny jest porządny zestaw testów.

Źródła

• [1] https://devclass.com/2026/01/15/vibe-coded-applications-full-of-security-blunders/
• [2] https://thenewstack.io/vibe-coding-could-cause-catastrophic-explosions-in-2026/
• [3] https://techmonitor.ai/comment-2/vibe-coding-lax-security
• [4] https://cyberscoop.com/vibe-coding-ai-cybersecurity-llm/
• [5] https://securityboulevard.com/2025/11/vibe-coding-with-a-conscience-why-security-must-be-in-the-mix/
• [6] https://reversinglabs.com/blog/vibe-coding-lessons
• [7] https://aikido.dev/blog/vibe-coding-security
• [8] https://thehackernews.com/2025/06/secure-vibe-coding-complete-new-guide.html