Aplikacja zbudowana w Lovable wystawiła na świat dane 18 697 osób przez 48 dni. Wystarczyło polecenie cURL z przeglądarki, bez logowania, bez tokenu, bez nawet wpisanego adresu mailowego. Wśród poszkodowanych byli studenci z Berkeley, a poza tym dzieci ze szkół podstawowych w Szwecji, Belgii, Hiszpanii i na Filipinach. Aplikacja była polecana na stronie głównej platformy, dlatego miała 100 tysięcy wyświetleń i 400 polubień, a jej autor był pewny, że ma działający produkt.
Pewność wzięła się stąd, że aplikacja faktycznie działała. Tworzyła egzaminy, oceniała odpowiedzi, na przykład pokazywała statystyki w czasie rzeczywistym. Demo zachwycało, prezentacja na Discoverze platformy zachwycała, co więcej, użytkownicy się zachwycali. Jednak w produkcji zachwyt skończył się w chwili, gdy ktoś otworzył terminal. Pokazujemy, dlaczego AI-generowany kod tak często wybucha tuż po wdrożeniu, jakie są trzy najczęstsze pułapki i co zrobić, żeby twoje MVP nie zostało następne na liście.
Co AI buduje za fasadą działającego dema
Demo i produkcja to dwa różne zwierzęta. To jak różnica między mieszkaniem pokazowym deweloperskim a tym, w którym faktycznie zamieszkasz. Pokazowe ma świetne światło, idealne meble i zerową szafę z butami. Twoje natomiast musi pomieścić życie, dwoje dzieci, niedzielne błoto i awarię ogrzewania w styczniu.
AI generuje świetne mieszkanie pokazowe. Jest tam logika biznesowa, formularze, ładny interfejs i ścieżka, którą prześledzi tester demo. Jednak brakuje wszystkiego, co jest potrzebne, kiedy aplikacja zaczyna obsługiwać prawdziwych ludzi. Po pierwsze, kontroli dostępu, która nie pozwoli losowemu cURL-owi wyciągać dane. Dalej, ograniczeń żądań, które wytrzymają botów. Z kolei logów, które pokażą, że ktoś próbuje się włamać. Na koniec sekretów schowanych w sejfie zamiast wklejonych do repo.
AI w ciągu godziny zbuduje ci aplikację. Tylko nikt cię nie ostrzegł, że godzina pisania to dwie doby gaszenia pożarów po wdrożeniu.
Wśród programistów ten sam moment otrzeźwienia powtarza się tysiącami głosów. Aplikacja przeszła testy, klient się ucieszył, ponieważ wszystko działało na demie. Potem jednak zaczął używać i wszystko zaczęło zgrzytać. Auth wycieka, błędy nikomu nie są pokazywane, sekrety leżą w kodzie, dlatego każdy ruch produkcyjny wymaga przerabiania połowy aplikacji. Ten sam wzorzec opisaliśmy szerzej w tekście czym jest vibe coding i czy zastąpi programistów, kiedy hype dopiero się rozkręcał.
Dlaczego AI domyślnie pisze niebezpieczny kod
Liczby z niezależnych badań są bezlitosne. Na przykład firma Escape.tech przeskanowała 5 600 publicznie wdrożonych aplikacji zbudowanych przez Lovable, Bolt i Base44. W rezultacie znaleźli ponad 2 000 krytycznych podatności, 400 ujawnionych sekretów (kluczy API, tokenów dostępowych) i 175 wycieków danych osobowych, w tym dokumentacji medycznej oraz informacji płatniczych. To nie były laboratoryjne testy. Co więcej, były to działające produkcyjne aplikacje, z których ludzie korzystali w tej chwili.
Skąd taka skala? Powodów jest kilka i splatają się ze sobą. Po pierwsze, modele AI uczyły się na milionach starszych projektów, w których złe praktyki bezpieczeństwa były normą. Na przykład konkatenacja zapytań SQL zamiast bezpiecznych, parametryzowanych wersji. Dalej, walidacja po stronie klienta zamiast serwera. Z kolei klucze API wpisane na sztywno w kod. Wszystko, co ktoś kiedyś popełnił w szybkim prototypie, model uznał za poprawny wzorzec.
Drugi powód jest bardziej miękki, jednak jeszcze ważniejszy. Modele optymalizują się pod sukces zadania, czyli “kod, który się kompiluje i robi to, o co prosiłeś”. Natomiast bezpieczeństwo nie jest częścią tego sukcesu. Jeśli prosisz o system logowania, dostaniesz system, który loguje. Czy ten system odeprze atak na podszycie się pod cudzą sesję, model nie sprawdzi, ponieważ nie zostałeś o to zapytany. W efekcie w 45% przypadków, kiedy AI miała wybór między bezpieczną a szybką implementacją, wybierała szybką, co potwierdziły badania nad lukami z listy OWASP.
Trzeci powód jest statystyczny i mocno mówi sam za siebie. Zatwierdzenia kodu generowane przez AI wprowadzają zaszyte na sztywno hasła i klucze w 3,2% przypadków, podczas gdy ten sam wskaźnik dla kodu pisanego przez samego człowieka wynosi 1,5%. Dwa razy częściej. Mechanizm jest prosty. Programista, który pisze sam, instynktownie myśli “to muszę schować w zmiennej środowiskowej”. Z kolei programista, który tylko akceptuje propozycję AI, często nie zauważa, że klucz właśnie został wkomponowany w szóstą linię trzeciego pliku.
Trzy pułapki, które zabijają produkcyjny MVP
Po incydencie Lovable analitycy bezpieczeństwa zaczęli rozkładać typowy AI-MVP na czynniki pierwsze. Wszystkie wycieki ostatniego roku można sprowadzić do trzech pułapek, które AI niemal zawsze pomija.
Autoryzacja po stronie klienta
Klasyczny błąd. Aplikacja sprawdza, czy użytkownik ma prawo widzieć stronę, w przeglądarce, czyli na maszynie atakującego. W efekcie wystarczy zmienić jedną wartość w konsoli i dostęp jest twój. Na przykład w jednej z aplikacji opisanych przez badacza Taimura Khana użytkownicy odkryli to w 72 godziny. Zmieniła się jedna zmienna w przeglądarce, dlatego otworzyły się wszystkie funkcje płatne. Bez płacenia.
To jak zamek w drzwiach założony na kartonowe pudełko. Może wyglądać jak prawdziwe drzwi, jednak nikt ci nie zagwarantuje, że za chwilę ktoś nie przebije się ręką przez ścianę.
Sekrety zaszyte w repo
Klucz API do bazy danych, token dostępowy do Stripe, hasło administratora. AI zwykle wstawia je tam, gdzie są potrzebne, czyli w samym kodzie. Następnie repo trafia na publiczne repozytoria, kod skompilowany leci do przeglądarek, w efekcie sekret jedzie razem z produktem.
Z raportu Escape.tech wynika, że na 5 600 aplikacji 400 wystawia ujawnione sekrety. Czyli średnio co czternasty publicznie dostępny vibe-MVP wystawia jakiś klucz, którego nie powinien. Co więcej, część z tych kluczy daje pełen dostęp do bazy z danymi klientów.
Domyślnie wyłączone Row Level Security
Najbardziej zdradliwy z trzech, ponieważ niewidoczny w testach. Vibe-narzędzia tworzą bazę danych w Supabase albo podobnym. Domyślnie natomiast ta baza nie ma włączonej kontroli dostępu na poziomie wiersza, czyli funkcji, która sprawdza “czy ten konkretny użytkownik ma prawo widzieć ten konkretny rekord”. Bez tego twój klient widzi wszystkie zamówienia, nie tylko swoje. Z kolei atakujący widzi je z jednym wywołaniem cURL.
Dokładnie ten mechanizm zawiódł w Lovable w lutym 2026. Aplikacja sprawdzała tożsamość użytkownika, jednak baza za nią nie sprawdzała już niczego. Działa to jak hotel, który wpuszcza gości za potwierdzeniem rezerwacji, jednak każde drzwi w środku otwiera ten sam klucz.
Kurs n8n 2.0 · Kodożercy
n8n + AI = automatyzacje, które naprawdę myślą
n8n pozwala podłączyć modele AI do swoich workflow – wysyłać dane do ChatGPT, analizować wyniki, reagować automatycznie. Kurs n8n 2.0 na Kodożercach pokaże Ci jak to połączyć.
Sprawdź jak to działa →
Jak vibe-codować, żeby wdrożenie nie było eksplozją
Odpowiedź nie brzmi “przestań używać AI”. Brzmi “zatrzymaj się przed wdrożeniem i zrób cztery rzeczy, które AI ci pominęła”. Nazywamy to wewnętrznie “produkcyjnym audytem” i w projektach z klientami stosujemy go zawsze, zanim cokolwiek pójdzie pod prawdziwy ruch.
Po pierwsze: audyt tego, co AI faktycznie zbudowała. Otwierasz pliki i czytasz wszystkie miejsca, gdzie pojawia się słowo “auth”, “token”, “key”, “secret”. Każde znalezisko musi być w zmiennej środowiskowej, nie w kodzie. Co więcej, każda kontrola dostępu musi się dziać po stronie serwera, nie przeglądarki. Z kolei każda baza musi mieć włączoną kontrolę dostępu na poziomie wiersza, nawet jeśli AI o tym nie wspomniała.
Po drugie: nudna warstwa infrastruktury. Limity żądań, polityka błędów, walidacja danych wejściowych, polityka kopii zapasowej. Niczego z tego AI nie zaproponowała sama, ponieważ nikt o to nie pytał. To jak budowanie domu i zapomnienie o rynnach. Wygląda dobrze przez tydzień, dopóki nie spadnie deszcz.
Po trzecie: obserwowalność. Logi, metryki, śledzenie żądań. Bez tego nie wiesz, kiedy ktoś próbuje się włamać, dopóki nie zobaczysz wpisu w sieci. Zasady budowania systemów AI, które nie zawodzą w trakcie pracy, opisaliśmy w artykule 12 zasad budowania agentów AI w produkcji, ponieważ te same reguły dotyczą każdego AI-MVP.
Po czwarte, najczęściej pomijane: piaskownica przed światem. Wdrażasz na adres, którego nikt nie zna. Następnie zapraszasz pięciu znajomych, żeby spróbowali coś popsuć. Patrzysz, co się dzieje w logach. Dopiero potem otwierasz drzwi szerzej. AI tej piaskownicy nie wymyśli za ciebie. To etap, na którym ty jesteś inżynierem, a nie operatorem narzędzia.
Vibe coding nie zniknie. Ale produkcja jest pierwszym miejscem, w którym ten sposób pracy traci magię. Tam już potrzebny jest człowiek, który wie, co AI pominęła.
Podsumowanie
Vibe coding skraca pisanie aplikacji z tygodni do godzin. To prawda. Jednak ta sama godzina pracy generuje aplikację, która często nie ma autoryzacji po stronie serwera, ma sekrety w repo i wyłączoną kontrolę dostępu w bazie. W efekcie wystawienie takiego MVP do produkcji to nie wdrożenie, tylko otwarte zaproszenie.
Co zyskujesz? Szybkość, której nie miałeś dwa lata temu. Co tracisz, jeśli zatrzymasz się tylko na demie? Wszystko, co zbudujesz na tym fundamencie. Wybór nie polega na tym, czy używać AI. Polega na tym, czy traktować jej kod jak gotowy produkt, czy jak szkic do solidnej weryfikacji. Co więcej, dziesiątki głośnych incydentów ostatniego roku pokazały, która z tych dwóch opcji się sprawdza.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
