84% programistów korzysta już z narzędzi do vibe codingu, ale tylko 29% im ufa — i te liczby nie są przypadkowe. Niezależne testy Veracode na ponad 100 modelach językowych pokazały, że 45% kodu generowanego przez AI wprowadza podatności z listy OWASP Top 10. Skanowanie ponad 1400 aplikacji zbudowanych z pomocą AI (Escape.tech) wykazało problemy bezpieczeństwa w 65% z nich, a krytyczną podatność w 58%. Jeśli Wasza aplikacja powstała głównie w Lovable, Cursorze, Bolcie czy podobnym narzędziu, i nigdy nie przeszła profesjonalnego audytu, statystycznie jest bardziej prawdopodobne, że ma problem, niż że go nie ma. Poniżej wyjaśniamy, na czym dokładnie polega ryzyko i jak wygląda solidny audyt przed wdrożeniem na produkcję.
Dlaczego dług techniczny z vibe codingu jest inny niż zwykły dług techniczny
Programista, który pisze szybkie, niedoskonałe rozwiązanie, zwykle wie, że to robi. Pamięta, gdzie i czemu poszedł na skróty. Może to wyjaśnić następnej osobie. Kod ma swojego „właściciela” — kogoś, kto rozumie decyzje, które za nim stoją.
Kod wygenerowany przez AI nie ma takiego właściciela. Działa, ale często nikt do końca nie wie, czemu działa akurat tak. Gdy coś się psuje w środku nocy, ktoś czyta kod, którego nie napisał, próbując zrozumieć logikę, której nigdy się nie uczył. To właśnie nazywa się długiem strukturalnym bez autorstwa — i jest trudniejszy do spłacenia niż klasyczny dług techniczny, bo nikt nie ma pełnego obrazu, co dokładnie trzeba naprawić.
Konkretne dane, nie wrażenia
Skala problemu jest dobrze zmierzona, nie tylko odczuwana:
- Liczba podatności (CVE) przypisanych kodowi generowanemu przez AI rośnie wykładniczo. W styczniu 2026 roku było ich 6. W lutym już 15. W marcu — 35. Badacze z Georgia Tech szacują, że rzeczywista liczba w całym ekosystemie open source jest 5-10 razy wyższa, bo większość narzędzi AI nie zostawia metadanych pozwalających jednoznacznie zidentyfikować pochodzenie kodu.
- Konkretny, udokumentowany przykład: badacz przeanalizował 50 aplikacji zbudowanych w popularnych narzędziach AI. W 88% z nich zabezpieczenia na poziomie wierszy w bazie danych (Row-Level Security) były całkowicie wyłączone — nie błędnie skonfigurowane, po prostu wyłączone. Baza zwracała każdy rekord na każde zapytanie, bez żadnej kontroli dostępu.
- Duplikacja kodu wzrosła o 48%, a aktywność refaktoryzacji spadła o 60% po masowym przyjęciu narzędzi AI w zespołach (dane Pixelmojo, 2026) — zespoły generują więcej powtarzalnego kodu i robią mniej, żeby go uporządkować.
- Koszt utrzymania kodu wygenerowanego przez AI rośnie o około 300% w ciągu pierwszych 18 miesięcy w porównaniu do kodu pisanego tradycyjnie, według branżowych analiz z 2026 roku.
Dlaczego samo automatyczne skanowanie nie wystarcza
Naturalnym odruchem jest poprosić AI o sprawdzenie własnego kodu, albo puścić automatyczny skaner bezpieczeństwa. To pomaga, ale nie wystarcza samo w sobie.
Automatyczne narzędzia (SAST sprawdzające sam kod, SCA sprawdzające zależności, DAST testujące działającą aplikację) wychwytują znane, powtarzalne wzorce błędów. Nie wychwytują błędów logiki biznesowej — na przykład sytuacji, w której użytkownik technicznie może zobaczyć dane innego użytkownika, bo nikt nie zaprojektował odpowiedniej kontroli dostępu na poziomie aplikacji. Tego typu błędów łapie tylko doświadczony człowiek, czytający kod z pytaniem „co się stanie, jeśli ktoś spróbuje to obejść”.
Podobny problem dotyczy testów. Jeśli AI wygenerowało zarówno kod, jak i testy do niego, testy często mają te same, niewidoczne wady co sam kod — bo powstały z tego samego, błędnego rozumienia problemu. Wysoki procent pokrycia testami niczego nie gwarantuje, jeśli testy sprawdzają złe rzeczy. Skuteczniejszym sposobem weryfikacji jakości testów jest mutation testing — technika, w której do kodu wprowadza się drobne, sztuczne błędy i sprawdza, czy testy je wychwytują. Jeśli nie wychwytują, to sygnał, że testy tylko wyglądają dobrze na papierze.
Siedem sygnałów, że aplikacja potrzebuje audytu
- Aplikacja działa tylko wtedy, gdy użytkownik robi dokładnie to, co przewidziano — każde odstępstwo powoduje błąd.
- Każda nowa funkcja psuje coś, co wcześniej działało poprawnie.
- Nikt w zespole nie potrafi wyjaśnić, czemu dany fragment kodu działa.
- Ten sam problem został rozwiązany w kilku miejscach, na kilka różnych sposobów.
- Klucze API i hasła są zapisane bezpośrednio w kodzie, nie w bezpiecznym magazynie zmiennych środowiskowych.
- Nie ma pewności, czy jeden użytkownik może zobaczyć dane innego użytkownika.
- Środowisko testowe i produkcyjne to w praktyce jedno i to samo miejsce.
Rozpoznanie choćby dwóch lub trzech z tych sygnałów to wystarczający powód, żeby zrobić profesjonalny audyt, zanim aplikacja obsłuży większy ruch albo realne dane klientów.
Co obejmuje solidny audyt vibe codingu
Pełny audyt aplikacji zbudowanej z pomocą AI powinien objąć kilka warstw naraz, nie tylko sam kod:
- Architektura i struktura projektu — nie tylko to, co jest źle napisane teraz, ale też to, co utrudni rozwój aplikacji za pół roku.
- Bezpieczeństwo zgodnie z OWASP Top 10 — autoryzacja na każdym endpoincie, walidacja danych wejściowych, ochrona przed wstrzyknięciem kodu, wyeksponowane dane dostępowe.
- Refaktoryzacja tam, gdzie faktycznie potrzebna — ujednolicenie wzorców i usunięcie duplikatów, bez przepisywania rzeczy, które działają poprawnie.
- Testy automatyczne dla kluczowych ścieżek, weryfikowane pod kątem tego, czy faktycznie łapią realne błędy.
- Model danych i wydajność — miejsca, w których aplikacja zwolni przy większym obciążeniu.
- Rozdzielenie środowisk — testowego od produkcyjnego, z procesem wdrożenia i monitoringiem błędów.
Kiedy vibe coding jest w porządku bez profesjonalnego audytu
Nie każda aplikacja zbudowana z pomocą AI potrzebuje natychmiastowego audytu. Szybkie prototypy, wewnętrzne narzędzia bez dostępu do realnych danych klientów, oraz projekty testujące pomysł przed inwestycją w pełne wdrożenie mogą bezpiecznie działać w obecnej formie przez jakiś czas. Granica przebiega tam, gdzie aplikacja zaczyna obsługiwać prawdziwych użytkowników, prawdziwe dane albo płatności — od tego momentu koszt błędu przestaje być teoretyczny.
Przykład z praktyki (Klient S, startup B2B budujący panel klienta — przykład poglądowy, dane uśrednione dla tej skali projektu)
Zespół zbudował działający MVP panelu klienta w jednym z popularnych narzędzi do vibe codingu w ciągu trzech tygodni. Aplikacja działała dobrze na demo dla pierwszych klientów. Przed podpisaniem pierwszej większej umowy klient korporacyjny zapytał o zabezpieczenia i sposób przechowywania danych.
Szybki audyt wykazał, że kontrola dostępu na poziomie bazy danych była w praktyce wyłączona — każdy zalogowany użytkownik mógł teoretycznie odpytać dane innej firmy, zmieniając tylko identyfikator w adresie zapytania. Naprawa tego jednego problemu, wraz z uporządkowaniem duplikującej się logiki w trzech miejscach kodu, zajęła dwa tygodnie — znacznie mniej, niż kosztowałaby naprawa po realnym wycieku danych klienta korporacyjnego.
FAQ
Czy kod napisany przez AI może być bezpieczny na produkcji? Tak, ale wymaga świadomej weryfikacji. Problem nie leży w samej AI — leży w przyjmowaniu jej wyników bez sprawdzenia. Kod AI może być produkcyjny, jeśli ktoś go rozumie, przetestował rygorystycznie i zweryfikował granice bezpieczeństwa.
Czy automatyczny skaner bezpieczeństwa wystarcza do audytu aplikacji z vibe codingu? Nie w pełni. Automatyczne narzędzia (SAST, SCA, DAST) wychwytują znane wzorce błędów, ale przeoczają błędy logiki biznesowej i decyzji architektonicznych, które wymagają ręcznego przeglądu przez doświadczonego programistę.
Jak długo trwa audyt aplikacji zbudowanej w Lovable, Cursorze albo podobnym narzędziu? Wstępna ocena, czy aplikacja kwalifikuje się do naprawy czy wymaga większej przebudowy, zajmuje zwykle około 48 godzin. Pełny audyt i naprawa, w zależności od skali problemów, trwa od kilku tygodni do kilku miesięcy.
Czy trzeba przepisać całą aplikację, jeśli powstała z pomocą AI? Zwykle nie. Dobry audyt rozróżnia to, co działa poprawnie i można zostawić, od tego, co faktycznie wymaga naprawy — refaktoryzacja punktowa jest częstsza niż przepisanie od zera.
Co jest największym, najczęściej ignorowanym ryzykiem w aplikacjach z vibe codingu? Wyłączona lub źle skonfigurowana kontrola dostępu do danych na poziomie bazy danych — sytuacja, w której technicznie każdy użytkownik może odpytać dane innego użytkownika, mimo że interfejs aplikacji tego nie sugeruje.
Zbudowaliście aplikację w Lovable, Cursorze, Bolcie, v0, Replicie, Base44 albo Windsurfie i nie jesteście pewni, czy jest gotowa na prawdziwy ruch? Sprawdźcie naszą bezpłatną wstępną ocenę kodu — w ciągu 48 godzin powiemy, czy aplikacja kwalifikuje się do naprawy, czy wymaga większej przebudowy.
