Czy da się zrobić aplikację z AI (vibe coding) — i gdzie to się kończy?

Co realnie powstaje z generatora AI?

Ekran, formularz i prosta operacja na danych — w kilkanaście minut i w granicach limitu, który cennik podaje wprost. To, co dziś nazywa się „vibe coding”, nie jest zabawką: prototyp do pokazania klientowi powstaje szybciej niż makieta rysowana ręcznie.

Limity są policzalne. Bolt w planie darmowym daje 1 mln tokenów miesięcznie i 300 tys. dziennie, a plan Pro za 25 USD miesięcznie — 10 mln tokenów bez limitu dziennego (cennik producenta, odczyt 31 sierpnia 2026 r.).

v0 od Vercela ogranicza plan darmowy do 7 wiadomości dziennie i 5 USD kredytów miesięcznie; plan Plus kosztuje 30 USD za użytkownika miesięcznie. Replit ma plan Starter darmowy, Core za 20 USD i Pro za 100 USD miesięcznie (cenniki producentów, odczyt 31 sierpnia 2026 r.).

Lovable rozlicza się kredytami budowy: 5 dziennie i najwyżej 30 miesięcznie w planie darmowym, 5 dziennie bez limitu miesięcznego w planach płatnych. Kwot miesięcznych planów nie znaleźliśmy na stronie cennika na dzień 31 sierpnia 2026 r.; dokumentacja podaje doładowania: 0,30 USD za kredyt w Pro i 0,60 USD w Business.

Te narzędzia robią dobrze rzeczy, które widać: układ ekranu, warianty tego samego widoku, formularz podpięty do tabeli, publikację pod adresem, który da się wysłać. Dla sprawdzenia pomysłu i rozmowy z pierwszymi użytkownikami to wystarcza.

Ceny i limity zmieniają się w trakcie roku. Data odczytu przy liczbie jest tu ważniejsza niż sama liczba — sprawdź każdą z nich w cenniku, zanim oprzesz na niej decyzję.

Gdzie się kończy generowanie, a zaczyna odpowiedzialność?

Na granicy tego, czego nie widać na ekranie. Veracode w raporcie z 30 lipca 2025 r. sprawdził ponad 100 modeli na 80 zadaniach: 45% próbek kodu oblało testy bezpieczeństwa i wprowadziło podatności z listy OWASP Top 10. Wynik nie poprawiał się wraz z wielkością modelu.

Uprawnienia. Dokumentacja Supabase mówi wprost: tabela w odsłoniętym schemacie bez polityk dostępu jest do odczytu i zapisu dla każdej roli, która ma do niej uprawnienie. Generator tworzy tabelę, żeby aplikacja działała; polityka wymaga wiedzy, kto i co ma widzieć.

Skala tego błędu jest udokumentowana. Wpis CVE-2025-48757 opisuje niewystarczającą politykę dostępu na wierszach w Lovable, która pozwalała niezalogowanemu napastnikowi czytać i zapisywać dowolne tabele generowanych stron — ocena krytyczna, CVSS 9,3 (GitHub Advisory Database, publikacja 30 maja 2025 r.).

Płatności. Stripe pisze w dokumentacji, że bez weryfikacji podpisu napastnik może wysłać fałszywe powiadomienie i wywołać realizację zamówienia albo nadanie dostępu do konta. Dochodzą powtórki: operator ponawia dostarczenie zdarzenia przez trzy dni, więc obsługa musi rozpoznać duplikat po identyfikatorze.

Sekrety. Klucz z prawem zapisu wklejony do frontu jest kluczem publicznym — wystarczy podejrzeć źródło strony. Klucz, który raz trafił do repozytorium, rotujemy od razu, bez dyskusji, także w repozytorium prywatnym; historia pamięta skasowany plik.

Kopie. Kopia, której nikt nie odtworzył, jest plikiem, a nie kopią. Z naszej praktyki: punkt odtworzenia i czas odtworzenia zapisujemy, zanim będą potrzebne — po awarii nie ma czasu na ustalanie, ile danych wolno stracić.

Prawo. Gdy wyciekną dane osobowe, zgłasza je administrator danych, czyli firma, a nie dostawca generatora. UODO wskazuje art. 33 ust. 1 RODO: bez zbędnej zwłoki, w miarę możliwości nie później niż w 72 godziny po stwierdzeniu naruszenia.

Producent narzędzia mówi to samo. Dokumentacja Lovable stwierdza, że to użytkownik odpowiada za spełnienie wymagań bezpieczeństwa właściwych dla zastosowania aplikacji, a wbudowane skany wykrywają typowe problemy, lecz nie gwarantują pełnego bezpieczeństwa (tłumaczenie własne, odczyt 31 sierpnia 2026 r.).

Kiedy przepisać to, co powstało z AI?

Sygnałów jest pięć i każdy znaczy to samo: od tego momentu błąd kosztuje pieniądze albo dane, a nie tylko czas.

• Pierwsza prawdziwa płatność. Wcześniej wszystko da się poprawić bez konsekwencji; potem każdy błąd w rozliczeniu jest sprawą księgową i reklamacyjną.
• Drugi typ użytkownika. Jeden użytkownik nie potrzebuje polityk dostępu. Dwóch potrzebuje ich od pierwszego dnia, a nie od pierwszej skargi.
• Dane osobowe osób trzecich. Wchodzą obowiązki administratora: podstawa przetwarzania, eksport, usunięcie, zgłoszenie naruszenia w terminie.
• Integracja z systemem, którego nie kontrolujesz. Cudze API zmienia się bez pytania i wymaga obsługi błędów, których generator nie przewidział.
• Kod ma utrzymywać ktoś inny niż autor. Kodu, którego nikt nie przeczytał, nikt też nie umie naprawić pod presją czasu.

Jedno badanie psuje tu wygodną intuicję. METR w kontrolowanym eksperymencie opublikowanym 10 lipca 2025 r. dał 16 doświadczonym programistom 246 zadań w projektach, które dobrze znali. Z narzędziami AI pracowali 19% dłużej, choć sami oceniali, że pracowali 20% szybciej.

Wniosek z tego nie brzmi „nie używać”, tylko „mierzyć”. Przyspieszenie bywa realne przy nowym kodzie i przy rzeczach, które widać; w dojrzałym kodzie, którego się nie zna, bywa odwrotnie — a wrażenie przyspieszenia zostaje mimo to.

Jak my z tego korzystamy?

Pracujemy z agentami AI pod nadzorem człowieka i stąd wiemy, gdzie leży granica. Role są rozdzielone: autor, weryfikator, redaktor. To nie jest jedna maszyna, która sama siebie sprawdza i sama sobie stawia ocenę.

Między rolami stoją bramki maszynowe: lint, testy, sprawdzenie parytetu. Bramka nie ocenia, czy funkcja jest dobra — odrzuca to, co da się rozstrzygnąć regułą, żeby człowiek patrzył na resztę.

Decyzje i odpowiedzialność zostają po stronie człowieka. To rozróżnienie jest tu całą treścią: model potrafi napisać politykę dostępu, ale za to, czy ona faktycznie zamyka cudze dane, odpowiada człowiek, który ją przeczytał.

Skala, o której możemy mówić: budujemy i utrzymujemy kilkanaście aplikacji i serwisów na tym samym stosie. Rząd wielkości to setki kont w pojedynczej aplikacji dla firm i tysiące wizyt miesięcznie na pojedynczy serwis.

Stąd bierze się lista rzeczy sprawdzanych zawsze, bo każda z nich kosztuje więcej po starcie niż przed: API bazy zwraca domyślnie najwyżej 1000 wierszy i lista „wszystkich” rekordów cicho się ucina; rola zalogowanego użytkownika w politykach dostępu to nie administrator; identyfikator w adresie nie jest hasłem.

Dalej: ograniczenie uprawnień do kolumn bez polityki na wiersze jest pozorne, a podmiana widoku potrafi zgubić ustawienie, które kazało widokowi respektować te polityki. Żadnej z tych rzeczy nie widać na ekranie — i żadnej nie wyłapie zrzut ekranu z prototypu.

Co sprawdzić w aplikacji, którą zbudował generator?

Siedem pytań specyficznych dla kodu z generatora — o decyzje, które w projekcie pisanym ręcznie ktoś podejmuje świadomie, a tutaj zapadły przy okazji. Pełny pięciominutowy test dla każdej aplikacji, niezależnie od tego, czym powstała, jest w tekście o zasadach bezpieczeństwa od pierwszego dnia.

1. Ustal, gdzie leży kod i czy da się go zbudować poza narzędziem. Eksport do własnego repozytorium i uruchomienie u innego dostawcy to różnica między przeniesieniem aplikacji a przepisaniem jej od zera.
2. Sprawdź, czy w wygenerowanej bazie w ogóle są polityki dostępu — na każdej tabeli, nie tylko na tej z danymi klientów. To ten sam brak, który opisuje przywołany wyżej wpis CVE-2025-48757.
3. Zapytaj, gdzie narzędzie trzyma klucz do bazy: w ustawieniach projektu czy w kodzie, który samo wygenerowało. Klucz z prawem zapisu we froncie jest kluczem publicznym niezależnie od tego, kto go tam wpisał.
4. Sprawdź, czy płatność zapisuje powiadomienie od operatora, a nie ekran „dziękujemy”. Przycisk zapłaty i powrót do aplikacji generator zrobi sam; obsługa powiadomienia po stronie serwera jest osobną pracą.
5. Ustal, czy ktoś przeczytał wygenerowane zapytania do bazy — te, które rozstrzygają, kto widzi który rekord. To jedyna pozycja z tej listy, której nie sprawdzisz z poziomu przeglądarki.
6. Zrób kopię danych i kodu poza narzędziem i sprawdź, czy da się z niej wystartować bez konta u dostawcy generatora. Kopia trzymana wyłącznie wewnątrz narzędzia dzieli los tego konta.
7. Ustal, kto po stronie firmy zgłasza naruszenie w 72 godziny i pod jaki adres. To obowiązek administratora danych, czyli firmy — dostawca narzędzia go nie przejmuje.

Ta lista nie zastępuje audytu i nie ma takiej ambicji. Pyta o to, czego generator nie rozstrzygnął za nikogo: gdzie leży kod, kto ma dostęp do danych, skąd bierze się informacja o wpłacie i kto odpowiada, gdy coś wypłynie.

Trzy rachunki należą do innych serwisów i tutaj ich nie robimy: ile aplikacja kosztuje w trzy lata, czym ją w ogóle budować i czyj jest kod napisany przez AI.

Obowiązki, które AI Act nakłada na aplikacje z modelem w środku, mają swoje daty — zebrał je kalendarz terminów AI Act. Koszt utrzymania rozwiązania bez kodu przy rosnącej liczbie kont opisuje osobne zestawienie.