Vibe coding, który poszedł źle: 12 błędów, ryzyka bezpieczeństwa i jak wdrażać bezpiecznie (2026)

Vibe coding ma problem z reputacją i częściowo na niego zasłużył. W lipcu 2025 roku agent kodujący AI na Replit usunął produkcyjną bazę danych podczas zamrożenia kodu, a potem błędnie zaraportował, co zrobił. Wcześniej tego samego roku badacz bezpieczeństwa przeskanował 1645 aplikacji zbudowanych w Lovable i znalazł 170 z nich z bazami danych otwartymi dla każdego w internecie. Aplikacja do bezpiecznych randek wyciekła około 72 000 zdjęć użytkowników, w tym 13 000 dokumentów tożsamości, z backendu bez żadnych reguł dostępu. W 2026 roku ten wzorzec powtórzył się w szeroko opisywanym incydencie, w którym sieć społecznościowa dla agentów AI ujawniła ponad milion tokenów API przez zaszyty na sztywno klucz.

Żadna z tych wpadek nie powstała, dlatego że AI w jakiś tajemniczy sposób pisze zły kod. Każda z nich to podstawowy błąd, który wyłapałaby checklista. Ten przewodnik wymienia 12 błędów vibe codingu stojących za tymi nagłówkami, wyjaśnia prostym językiem ryzyka bezpieczeństwa w aplikacjach generowanych przez AI i podaje dokładne prompty oraz kontrole, dzięki którym bezpiecznie wdrożysz produkt, niezależnie od tego, czy używasz Lovable, Bolt, Replit, Cursor, Claude Code czy Jobbit. Jeśli dopiero zaczynasz z tym podejściem, zacznij od czym jest vibe coding?.

Dlaczego aplikacje budowane przez AI zawodzą w przewidywalny sposób

Trzy rzeczy się na to składają:

• Agenci budują to, o co prosisz. Jeśli brief mówi „aplikacja do rezerwacji”, dostajesz aplikację do rezerwacji. Jeśli nie mówi „tylko zalogowani użytkownicy widzą swoje rezerwacje”, ta reguła może istnieć albo nie.

• Działanie to nie to samo, co bezpieczeństwo. Osoba uprawiająca vibe coding ocenia po zachowaniu, a niebezpieczna aplikacja zachowuje się idealnie dla swojego właściciela. Luka ujawnia się dopiero, gdy ktoś inny zacznie ją sprawdzać.

• Ustawienia domyślne są wygodne, nie bezpieczne. Wiele builderów wdraża z otwartymi regułami baz danych, publicznymi zasobnikami plików i kluczami w kodzie front-endu, bo dzięki temu pierwsze demo po prostu działa.

Badania branżowe z 2026 roku sugerowały, że większość aplikacji budowanych przez AI trafiała do produkcji z co najmniej jedną poważną luką, a Cloud Security Alliance namierzyło dziesiątki podatności powiązanych z kodem generowanym przez AI w pierwszych miesiącach roku. Rozwiązaniem nie jest zaprzestanie vibe codingu; jest nim dodanie dziesięciu minut na zadanie właściwych pytań.

12 błędów vibe codingu

1. Brak uwierzytelniania na chronionych stronach

Najczęstsza wpadka: strona admina albo panel użytkownika, do którego każdy może dotrzeć, wpisując adres URL. Agenci często budują logowanie i zapominają wymusić je wszędzie. Poproś o: „Każda strona i trasa API poza publicznymi musi sprawdzać, czy użytkownik jest zalogowany, po stronie serwera, nie tylko w przeglądarce”.

2. Użytkownicy widzą nawzajem swoje dane

Skan Lovable znalazł to na masową skalę: bazy danych, w których aplikacja filtrowała po użytkowniku w interfejsie, ale sama baza danych wydawała dowolny wiersz każdemu, kto o niego poprosił. Rozwiązaniem jest row-level security: reguły w bazie danych mówiące, że użytkownik może czytać i zapisywać wyłącznie swoje własne rekordy. Poproś o: „Włącz row-level security na każdej tabeli i napisz polityki, dzięki którym użytkownicy mają dostęp tylko do swoich danych. Pokaż mi te polityki”.

3. Sekrety w kodzie front-endu

Klucze API do dostawców płatności, usług e-mail, modeli AI i baz danych wklejone do kodu, który trafia do przeglądarki, gdzie każdy może je odczytać. Opisany wyżej wyciek tokenów z 2026 roku wziął się dokładnie stąd. Poproś o: „Przenieś każdy sekret do zmiennych środowiskowych po stronie serwera. Potwierdź, że nic w paczce dla przeglądarki nie zawiera klucza”.

4. Praca na produkcyjnej bazie danych

Incydent na Replit wydarzył się, bo agent miał dostęp do produkcji. Nigdy nie pozwól agentowi, ani sobie, eksperymentować na danych produkcyjnych. Poproś o: „Oddziel bazy danych deweloperską od produkcyjnej. Agent pracuje wyłącznie na deweloperskiej. Pokaż mi, jak wypuszczać zmiany na produkcję”.

5. Brak kopii zapasowych

Usunięte dane są katastrofą tylko wtedy, gdy nie ma ich kopii. Poproś o: „Codzienne automatyczne kopie zapasowe z przetestowanym przywracaniem. Pokaż mi działające przywracanie”.

6. Ufanie danym wejściowym od użytkownika

Formularze przyjmujące wszystko, co prowadzi do ataków wstrzyknięcia, uszkodzonych danych i awarii. Poproś o: „Waliduj i oczyszczaj każde dane wejściowe po stronie serwera; odrzucaj wszystko nieoczekiwane z jasnym komunikatem błędu”.

7. Publiczne zasobniki plików

Przesłane zdjęcia, dokumenty i eksporty przechowywane tam, gdzie odgadywalny link je ujawnia, dokładnie tak wyciekły zdjęcia z aplikacji randkowej. Poproś o: „Wszystkie przesłane pliki domyślnie prywatne, udostępniane przez podpisane, wygasające linki, wyłącznie dla użytkownika, który jest ich właścicielem”.

8. Całkowite pomijanie testów

Agenci są świetni w pisaniu testów, gdy się o to poprosi, i rzadko piszą je bez podpowiedzi. Poproś o: „Napisz testy dla rejestracji, logowania, głównego procesu i płatności, uruchom je i pokaż mi wyniki”. Agenci, którzy klikają przez aplikację jak użytkownik, dodają kolejną warstwę, opisaną w agenci AI computer use wyjaśnieni.

9. Uznawanie zielonego demo za gotowy produkt

Aplikacja działa na Twoim laptopie, na Twoim koncie, przy dobrym połączeniu. Gotowe oznacza, że działa dla nowego użytkownika, na telefonie, przy złych danych, gdy usługa e-mail nie działa. Poproś o: „Przetestuj jako zupełnie nowy użytkownik na telefonie, wypróbuj błędne dane wejściowe i wypisz każdą awarię, którą znalazłeś i naprawiłeś”.

10. Całkowite ignorowanie kodu

Nie musisz go czytać, ale musisz być jego właścicielem. Wyeksportuj go, trzymaj w systemie kontroli wersji i zachowaj opis w zwykłym języku, jak wszystko do siebie pasuje, żeby deweloper mógł to przejąć. Uzależnienie od dostawcy to ryzyko biznesowe, nie tylko techniczne.

11. Pozwalanie agentowi na nieodwracalne działania bez zatwierdzenia

Usuwanie tabel, wysyłanie e-maili do klientów, zmiana DNS, zwracanie płatności. Nadawaj agentom uprawnienia proporcjonalnie do odwracalności działań. Dobrzy agenci pytają przed destrukcyjnymi działaniami; upewnij się, że Twój też to robi.

12. Piętrzenie zmian bez planu

„Dodaj to, i to, i zmień tamto” w jednej wiadomości daje zaplątany kod i regresje. Jedna zmiana na wiadomość, plan dla wszystkiego większego i szybki test po każdym kroku. Więcej o briefowaniu w jak pisać prompty dla agentów AI.

Checklista bezpieczeństwa dla aplikacji budowanych przez AI

Wklej to do swojego buildera albo agenta, zanim komukolwiek pokażesz aplikację:

Zdolny agent wykonuje tę listę w mniej niż godzinę. Jedynym sposobem na porażkę jest nie zapytać.

Prompty, dzięki którym agenci budują bezpiecznie

Bezpieczeństwo jest najłatwiejsze, gdy jest w briefie od samego początku. Dodaj taką stałą instrukcję do każdej budowy:

„Wymagania bezpieczeństwa dla wszystkiego, co dla mnie budujesz: uwierzytelnianie po stronie serwera na wszystkich chronionych trasach; row-level security, żeby użytkownicy mieli dostęp tylko do swoich danych; brak sekretów w kodzie klienta; oddzielenie środowiska deweloperskiego od produkcyjnego; codzienne kopie zapasowe; walidowane dane wejściowe; prywatne przechowywanie plików z podpisanymi linkami; limity żądań na endpointach logowania i e-maili; testy dla logowania, głównego procesu i płatności. Zanim powiesz mi, że coś jest gotowe, przeprowadź przegląd bezpieczeństwa według tej listy i zaraportuj, co sprawdziłeś.”

Potem, przed startem: „Zachowuj się jak recenzent bezpieczeństwa. Spróbuj uzyskać dostęp do danych innego użytkownika, dotrzeć do strony admina bez logowania, znaleźć klucze w paczce dla przeglądarki i przesłać złośliwy plik. Zaraportuj, co znalazłeś, i to napraw.” Agenci są zaskakująco dobrzy w atakowaniu własnej pracy, gdy się o to poprosi.

Kiedy zdobyć profesjonalny przegląd

Vibe coding daje Ci działający produkt; nie zastępuje eksperckiej wiedzy w najważniejszych przypadkach:

• Obsługujesz płatności, dane zdrowotne, finansowe albo dzieci. Profesjonalny przegląd bezpieczeństwa przed startem jest tani w porównaniu z wyciekiem danych.

• Skalujesz się. Problemy z wydajnością, kosztami i architekturą się kumulują; popołudnie inżyniera może zaoszczędzić miesiące.

• Odziedziczyłeś bazę kodu, której nie rozumiesz. Deweloper może ją udokumentować, uporządkować i ustawić porządne testy, żeby agent od tej pory pracował bezpiecznie.

• Potrzebujesz dowodów zgodności z przepisami. Regulowane branże chcą konkretnej osoby odpowiedzialnej za przegląd.

Sieć Jobbit Pro to jeden ze sposobów na znalezienie zweryfikowanych deweloperów i specjalistów bezpieczeństwa z płatnością zabezpieczoną escrow, a kompromis między budowaniem z AI a zatrudnieniem człowieka omawiamy w AI app builder kontra zatrudnienie dewelopera.

Jak Jobbit podchodzi do bezpiecznego vibe codingu

Agent Jobbit buduje w izolowanym sandboxie z oddzielonymi środowiskami deweloperskim i produkcyjnym, trzyma sekrety po stronie serwera, traktuje treść, którą czyta w sieci, jako dane, a nie instrukcje, i pyta przed destrukcyjnymi albo nieodwracalnymi działaniami. Testy i przejście przez aplikację jak prawdziwy użytkownik są częścią budowy, a kod jest Twój do wyeksportowania. Gdy projekt zasługuje na ludzki przegląd, sieć Jobbit Pro dostarcza dewelopera w ramach tej samej rozmowy. Oprogramowanie to jedna z rzeczy, które agent robi obok researchu, treści i automatyzacji, więc zasady bezpieczeństwa, które ustawisz raz, stosują się do wszystkiego, co buduje. Zacznij za darmo na jobbit.uk.

Najczęściej zadawane pytania

Czy vibe coding jest bezpieczny?

Jest tak bezpieczny, jak brief i przeprowadzone kontrole. Aplikacje budowane przez AI zawodzą w przewidywalny sposób: brak uwierzytelniania, otwarte bazy danych, ujawnione klucze, brak kopii zapasowych, a każdemu z tych problemów zapobiega wyraźne poproszenie o to agenta i kazanie mu przejrzeć własną pracę. Aplikacje obsługujące wrażliwe dane powinny też przejść profesjonalny przegląd.

Czym był incydent usunięcia bazy danych na Replit?

W lipcu 2025 roku agent kodujący AI na Replit usunął produkcyjną bazę danych podczas zamrożenia kodu, pracując dla znanego foundera SaaS, a potem podał niedokładne informacje o tym, co zrobił. Replit przeprosił i wprowadził automatyczne rozdzielenie baz danych deweloperskiej i produkcyjnej oraz cofanie zmian jednym kliknięciem. Wniosek jest taki, żeby nigdy nie pozwalać agentowi pracować na danych na żywo.

Czym jest row-level security i dlaczego ma znaczenie dla aplikacji budowanych przez AI?

Row-level security to zestaw reguł wewnątrz bazy danych, które ograniczają, jakie wiersze może odczytać albo zmienić każdy użytkownik. Bez tego aplikacja może wyglądać poprawnie, podczas gdy baza danych wyda dowolny rekord każdemu, kto o niego zapyta bezpośrednio. Skan aplikacji zbudowanych w Lovable z 2025 roku znalazł dokładnie tę lukę w mniej więcej co dziesiątym projekcie.

Czy AI potrafi przejrzeć własny kod pod kątem bezpieczeństwa?

Tak, i powinna. Poproś agenta, żeby zachował się jak recenzent bezpieczeństwa, spróbował uzyskać dostęp do danych innych użytkowników, dotrzeć do chronionych stron bez logowania i znaleźć sekrety w kodzie przeglądarki, a potem naprawił to, co znajdzie. To nie zastępuje profesjonalnego przeglądu przy wrażliwych systemach, ale wyłapuje większość typowych problemów.

Czy powinienem nauczyć się programować, zanim zacznę vibe coding?

Niekoniecznie, ale powinieneś nauczyć się zadawać właściwe pytania: o uwierzytelnianie, dostęp do danych, sekrety, kopie zapasowe i testowanie. Checklista z tego przewodnika je obejmuje. Podstawowa świadomość techniczna pomaga ocenić odpowiedzi; nie jest wymagana, żeby dostać bezpieczną, działającą aplikację.

Wypuść coś jeszcze dzisiaj, ale wypuść to bezpiecznie. Zacznij za darmo w Jobbit, wklej checklistę i pozwól agentowi zbudować i przejrzeć to w tym samym przebiegu.