Strona z Lovable, v0 albo ChatGPT bez programisty - 5 ryzyk, o których nikt ci nie powie

Wpisałeś w Lovable albo ChatGPT dwa zdania o swojej firmie i po kwadransie miałeś stronę. Wyglądała dobrze. Formularz działał. I pojawiło się pytanie, na które tutoriale nie odpowiadają: czy to może być moja strona firmowa? Taka, którą podlinkuję na wizytówce, do której podepnę zapisy na wizyty i na którą przez rok nikt nie będzie musiał patrzeć.

Zastrzeżenie na start, jak w każdym wpisie z tej serii: zarabiam na budowaniu stron, więc mam interes w tym, żebyś jednak zlecił ją komuś. Jednocześnie AI jest stałym elementem mojego warsztatu - pracuję z Claude Code i Copilotem codziennie, o czym pisałem przy plusach i minusach strony wygenerowanej przez AI. Nie mam więc powodu, żeby straszyć narzędziem. Mam powód, żeby powiedzieć ci, gdzie kończy się prototyp, a zaczyna odpowiedzialność - i uczciwie, kiedy vibe coding w zupełności wystarczy.

Krótka odpowiedź (dla niecierpliwych)

Vibe coding, czyli generowanie strony z kodu w Lovable, v0, Bolt albo ChatGPT, to świetny sposób na prototyp, narzędzie wewnętrzne albo test pomysłu. I ryzykowny sposób na stronę firmową, która zbiera dane klientów, ma być w Google i ma działać za rok. Granica nie leży w narzędziu. Leży w pytaniu: kto odpowiada za tę stronę, gdy przestanie działać albo gdy wycieknie z niej formularz.

Sam termin jest młody - pochodzi z lutego 2025, gdy Andrej Karpathy opisał tak budowanie programów przez opisywanie ich słowami, bez czytania kodu, który powstaje. To ostatnie jest kluczowe. Kod z AI bywa dobry. Problem w tym, że nikt go nie czyta.

Co to właściwie jest vibe coding - i czym różni się od Wixa i od WordPressa

W dyskusjach o "stronie z AI" mieszają się trzy różne rzeczy, a od tego, którą masz, zależy, ile z tego wpisu cię dotyczy.

Kreator w abonamencie (Wix, Framer, Squarespace). Platforma trzyma stronę, ty płacisz co miesiąc, kodu nie masz. Ale ktoś - platforma - odpowiada za to, że serwer stoi, a formularz nie wycieka. Porównanie kreatorów z WordPressem rozpisałem we wpisie Wix czy WordPress.

Vibe coding (Lovable, v0, Bolt, ChatGPT plus hosting). AI pisze prawdziwy kod, najczęściej w React lub Next.js, czasem z bazą danych w Supabase. Ten kod formalnie jest twój. I nikt poza tobą za niego nie odpowiada. To jest kluczowa różnica i oś całego tekstu.

WordPress od wykonawcy. Kod i dane są twoje, a za ich działanie odpowiada konkretny człowiek z umową. Ile to kosztuje i za co płacisz, opisałem we wpisie ile kosztuje strona WordPress.

Jedno rozróżnienie, które obniża temperaturę tego wpisu dla większości czytelników. W praktyce większość "stron z AI", z którymi styka się mała firma, to statyczny HTML: kilka podstron, zdjęcia, teksty, jeden formularz. Bez bazy danych, bez logowania. Taka strona nie ma czego "wyciec" poza tym formularzem, a jej realne ryzyka to skrypty, które dokłada wygenerowany kod, utrzymanie i SEO. Pełna aplikacja z Lovable - baza, konta użytkowników, rezerwacje z płatnością - to wszystkie pięć ryzyk naraz. Sprawdź, którą masz, zanim czytasz dalej.

Co naprawdę dostajesz po godzinie promptowania

Dostajesz działający interfejs i często działającą bazę. To prawda i to robi wrażenie - nie zamierzam udawać, że jest inaczej.

Dostajesz też rzeczy, których nie widać na ekranie: kilkadziesiąt do kilkuset pakietów, z których zbudowany jest projekt i które ktoś musi aktualizować; konfigurację hostingu; bazę danych z regułami dostępu albo bez nich; klucze do zewnętrznych usług wpisane w pliki; politykę prywatności wygenerowaną "przy okazji", która opisuje stronę, jakiej nie masz.

"Kod jest twój" znaczy tyle, że możesz go pobrać. Nie znaczy, że umiesz go przeczytać, że wiesz, co robi z danymi, ani że ktokolwiek to sprawdził. To jak dostać samochód bez przeglądu: jedzie, ale nikt nie zajrzał pod maskę.

Do tego dochodzi cennik, który wygląda niewinnie. Według stanu na wrzesień 2026 Lovable w planie Pro kosztuje 25 USD miesięcznie za 100 kredytów, Bolt w planie Pro także 25 USD, a v0 w planie Plus 30 USD za użytkownika - czyli rząd wielkości 90-110 zł miesięcznie, zależnie od kursu. Kredyty to jednak nie miesiące. Płacisz za każdą próbę, nie za efekt, a polskie recenzje Lovable zgodnie zauważają, że sto kredytów na średnim projekcie znika szybciej, niż się wydaje. Hosting i baza, gdy projekt rośnie, to osobny rachunek.

5 ryzyk, o których nie mówią tutoriale

1. Bezpieczeństwo - kod działa, ale nie jest sprawdzony

To nie jest teoria. Veracode w raporcie GenAI Code Security 2026 sprawdził, jak modele AI radzą sobie z zadaniami programistycznymi: około 44% wygenerowanych rozwiązań zawierało lukę bezpieczeństwa, a w 85% przypadków kod nie bronił się przed jednym z najstarszych ataków na strony (XSS). Rok wcześniej było 45%, więc nic się nie poprawia mimo lepszych modeli.

Jeszcze bliżej tematu jest badanie Escape.tech z początku 2026 roku. Zespół przeskanował 1 400 publicznie dostępnych aplikacji zbudowanych w Lovable, Bolt i podobnych narzędziach. Wynik: ponad 2 000 podatności o wysokiej krytyczności, ponad 400 ujawnionych sekretów (kluczy API, tokenów) i 175 przypadków wystawionych na widok danych osobowych, w tym numerów kont bankowych.

I konkret z tego roku. W lutym 2026 badacz wykazał 16 podatności w jednej aplikacji na Lovable, z których sześć było krytycznych, a aplikacja ujawniała dane ponad 18 tysięcy osób. Równolegle sama platforma łatała lukę w swoim backendzie, przez którą dało się dostać do kodu, danych dostępowych i historii czatów cudzych projektów. Nie piszę tego, żeby powiedzieć "Lovable jest złe". Platforma reagowała. Piszę, bo tak wygląda ryzyko w modelu, w którym nikt nie robi przeglądu, zanim strona zacznie zbierać dane.

Co z tym zrobić: zanim podepniesz formularz z danymi, poproś kogoś, kto czyta kod, o jeden przegląd. Jeśli masz bazę, niech sprawdzi, czy każda tabela ma reguły dostępu, nie tylko pierwsza. Klucze do usług nie mogą leżeć w kodzie. Przy stronie statycznej sprowadza się to do trzech rzeczy: formularz przez sprawdzone narzędzie zewnętrzne, żadnych kluczy w plikach, HTTPS.

2. RODO - ty jesteś administratorem, nawet jeśli kod napisała AI

Formularz kontaktowy, zapisy na wizyty, newsletter - to przetwarzanie danych osobowych. Odpowiada za nie administrator, czyli twoja firma. Nie Lovable, nie OpenAI, nie hosting. Wygenerowana polityka prywatności zwykle opisuje coś innego niż to, co strona faktycznie robi: nie wie, gdzie fizycznie leży baza, kto jest podmiotem przetwarzającym ani jak długo trzymasz dane.

Dwie rzeczy warto sprawdzić samemu, bez prawnika. Po pierwsze serwery: w jakim regionie stoi strona i baza (Supabase, Vercel i podobni dają wybór, ale AI wybiera domyślny) i czy dane nie wychodzą poza Europę bez podstawy. Po drugie ciasteczka i skrypty: wygenerowany kod ma zwyczaj dokładać zewnętrzne skrypty - analitykę, fonty z serwerów Google, mapy, widżet czatu - które ustawiają cookies, zanim ktokolwiek wyraził zgodę. To da się ogarnąć narzędziem do zgód typu Cookiebot lub podobnym, ale najpierw ktoś musi wiedzieć, że te skrypty w ogóle tam są.

Nie jestem prawnikiem i to nie jest porada prawna. Wpis pokazuje tylko, gdzie są pytania. Fundacja Panoptykon opisała, jak RODO wpisuje się w tworzenie narzędzi informatycznych - to dobry punkt wyjścia do rozmowy z kimś, kto się na tym zna.

3. Utrzymanie - kto zaktualizuje to za pół roku

Aplikacja z Lovable czy v0 to projekt w React lub Next.js z dziesiątkami zależności, do których łatki bezpieczeństwa wychodzą co tydzień. W WordPressie aktualizacje klika się w panelu - też trzeba, ale to kliknięcie. W projekcie wygenerowanym z kodu aktualizację robi się w kodzie, a pierwsza niekompatybilna wersja pakietu zatrzymuje wszystko i wysyła cię z powrotem do promptowania.

Polskie recenzje narzędzi opisują ten sam wzorzec: na małym projekcie AI radzi sobie świetnie, ale im dalej w las, tym trudniej zapanować nad zależnościami między elementami i każda zmiana w jednym miejscu psuje coś w drugim. Nie jest to liczba, jest to doświadczenie ludzi, którzy próbowali.

Co z tym zrobić: albo ktoś, kto rozumie kod, bierze projekt pod opiekę - koszt porównywalny z opieką nad stroną WordPress, czyli rzędu kilkuset złotych miesięcznie - albo świadomie przyjmujesz, że strona ma datę ważności.

4. Koszty - kredyty, hosting i "jeszcze jeden prompt"

Mechanika, której nie widać w cenniku: każda poprawka to kredyty, także "przesuń przycisk w lewo". Gdy AI trafia na błąd, którego nie umie naprawić, kredyty lecą w pętli, a ty spędzasz trzeci wieczór na tym samym problemie. To najczęstsza skarga w recenzjach, polskich i zagranicznych.

Policzmy uczciwie, metodą z wpisu o rachunku po dwóch latach. Plan narzędzia to około 100 zł miesięcznie, hosting i baza poza planem, gdy projekt urośnie, plus twój czas w wieczory. Vibe coding jest tańszy w pieniądzu na starcie praktycznie zawsze - i tego żaden wykonawca nie powinien ci wmawiać inaczej. Droższy staje się w jednym momencie: przy pierwszej awarii, której nie umiesz naprawić. Wtedy płacisz za diagnozę kodu, który nie ma autora, a to w znanej technologii zwykle kosztuje więcej niż zbudowanie tego samego od nowa. Pisałem o tym mechanizmie szerzej we wpisie o tym, dlaczego dobre strony nie staniały: narzędzie potaniało, odpowiedzialność nie.

5. Nikt nie jest właścicielem problemu

To ryzyko spina pozostałe cztery. W kreatorze za działanie strony odpowiada platforma, w granicach regulaminu. U wykonawcy - wykonawca, z umową, gwarancją i opieką, tak jak opisuję to w procesie współpracy. W vibe codingu odpowiadasz ty. Bez narzędzi, żeby to udźwignąć, i często bez świadomości, że w ogóle coś udźwignąć trzeba.

Żadne z tych pięciu ryzyk nie jest "wadą Lovable". To granice modelu, w którym kod pisze się bez czytania. Granice, nie wady. I są sytuacje, w których te granice nie mają żadnego znaczenia.

Kiedy vibe coding wystarczy (mówię to bez bólu)

Nie każdy projekt potrzebuje kogoś takiego jak ja. Vibe coding jest dobrym, a czasem najlepszym wyborem, gdy:

• robisz prototyp, żeby pokazać pomysł wspólnikowi, inwestorowi albo pierwszym klientom - tu iteracja kosztuje minuty i zlecanie nie ma sensu,
• budujesz narzędzie wewnętrzne dla trzech osób w firmie, bez danych klientów: kalkulator, checklistę, prosty panel do zadań,
• stawiasz landing bez formularza albo z formularzem przez zewnętrzne, sprawdzone narzędzie, na jeden sezon,
• chcesz zrozumieć, jak działa twój produkt cyfrowy, zanim zlecisz go komuś - wygenerowana strona to najlepszy brief, jaki możesz przynieść wykonawcy,
• to projekt hobbystyczny, gdzie awaria nikogo nie kosztuje.

Jeśli to twój przypadek, nie potrzebujesz mnie. Kilka rad na drogę, żeby nie było to za rok twoje zmartwienie: nie zbieraj danych, których nie musisz. Formularz podepnij przez sprawdzone narzędzie zewnętrzne zamiast własnej bazy. Kluczy do usług nigdy nie zostawiaj w kodzie. Wyeksportuj kod do własnego repozytorium od pierwszego dnia. A zanim podepniesz cokolwiek, co dotyka danych klientów, poproś kogoś, kto czyta kod, żeby raz na to spojrzał.

Sygnały, że pora oddać to komuś, kto czyta kod

Lustro poprzedniej sekcji. Pięć sygnałów, że strona z generatora przestała być prototypem:

1. Strona zbiera dane klientów - formularz, rezerwacje, konta - a nikt nie sprawdził, kto ma do nich dostęp.
2. "Jeszcze jeden prompt" trwa trzeci wieczór, a błąd wraca.
3. Chcesz podpiąć płatności, faktury albo integrację z programem, na którym działa firma.
4. Strona ma być w Google na frazy usługowe, a to wymaga kontroli nad strukturą, szybkością i danymi schema.org - o tym, dlaczego to dziś dotyczy też asystentów AI, pisałem we wpisie Wix czy WordPress.
5. Liczysz kredyty i wieczory, i suma zbliża się do wyceny wykonawcy.

Co wtedy? Dwie drogi, obie uczciwe. Pierwsza to przegląd i przejęcie istniejącego kodu - ma sens, gdy projekt jest mały i czysty. Druga to przepisanie na sprawdzoną technologię z zachowaniem treści i adresów URL, tak jak przy przebudowie bez utraty SEO. W obu przypadkach wygenerowana strona nadal jest najlepszym briefem, jaki wykonawca może dostać. Nic z tych wieczorów się nie marnuje.

Masz już taką stronę? Lista kontrolna na dziś

Siedem punktów, które sprawdzisz sam, bez wiedzy technicznej:

1. Czy formularz wysyła dane przez HTTPS? Kłódka przy adresie w przeglądarce. Jeśli jej nie ma, nie zbieraj niczego.
2. Czy w kodzie leżą klucze do usług? Pobierz projekt i wyszukaj w plikach słowa "key", "secret", "token". Jeśli obok nich są długie ciągi znaków, masz problem.
3. Czy baza ma reguły dostępu na każdej tabeli? W Supabase to zakładka "Policies" - każda tabela z danymi powinna je mieć, nie tylko pierwsza.
4. Czy polityka prywatności wymienia realnych dostawców? Hosting, baza, narzędzie do formularza, analityka. Jeśli wymienia "naszą firmę" i nic więcej, jest wygenerowana, nie napisana.
5. Czy strona ustawia ciasteczka przed zgodą? Otwórz stronę w trybie prywatnym, wejdź w narzędzia deweloperskie przeglądarki, zakładka cookies. Albo podepnij baner zgód typu Cookiebot, który sam wykrywa skrypty.
6. Czy masz kopię kodu poza platformą? Repozytorium na GitHubie albo choćby archiwum na dysku. Jeśli nie, strona istnieje tylko dopóki istnieje twoje konto.
7. Czy wiesz, kto odbierze telefon, gdy strona padnie? Jeśli odpowiedź brzmi "nikt", to nie masz strony. Masz zobowiązanie, o którym jeszcze nie wiesz.

Jeśli odhaczyłeś wszystkie siedem, twoja strona z AI jest w lepszym stanie niż większość. Jeśli utknąłeś na drugim albo trzecim punkcie, wróć do sekcji o sygnałach.

Podsumowanie

Vibe coding to najlepszy sposób na prototyp i najgorszy sposób na udawanie, że masz produkt. Różnica nie jest w narzędziu, tylko w tym, czy ktoś czyta kod i odpowiada za wynik. Jeśli strona ma zbierać dane i zarabiać, ktoś musi być jej właścicielem - w sensie odpowiedzialności, nie licencji.

Jeśli nie wiesz, po której stronie tej granicy jest twój projekt, umów bezpłatną konsultację. Przyjdź z linkiem do tego, co wygenerowałeś. Powiem ci, czy wystarczy jeden przegląd, czy potrzebna jest przebudowa - a jeśli to prototyp, który robi swoje, powiem, żebyś niczego nie zmieniał.