Lovable, Bolt, v0, Cursor — Co Zrobić, Gdy Kod z AI Się Psuje

Scena, którą widzę niemal co tydzień. Ktoś w weekend skleja w Lovable, Bolt albo v0 działające demo, cieszy się, pokazuje znajomym. Potem chce dodać jedną rzecz - płatność BLIK, logowanie, kolejny ekran - i wszystko zaczyna się sypać. Prosi AI o naprawę. Naprawia. Po godzinie psuje się coś, co działało. Znowu prosi o poprawkę. Po dziesiątej rundzie kod jest taki, że ani on, ani AI nie rozumieją już, co się dzieje. Klasyczne utknąłem.

Jeśli rozpoznajesz tu siebie - to nie twoja wina i nie oznaka braku kompetencji. Te narzędzia są zrobione właśnie po to: szybko pokazać pomysł. Problem zaczyna się, gdy próbujesz z demo zrobić prawdziwy produkt, który oddasz użytkownikom. W tym artykule otwarcie pokażę, gdzie konkretnie każde narzędzie dochodzi do swojej ściany, dlaczego AI naprawia i znowu psuje, co przygotować przed kontaktem oraz kiedy w ogóle warto ratować istniejący kod, a kiedy taniej przepisać na czysto.

Mówię nie z teorii. Takie projekty widzę bez przerwy, a moja droga z nimi jest zawsze ta sama: zepsutego kodu z Lovable czy Bolt nie przejmuję i nie łatam, tylko traktuję prototyp jako specyfikację i buduję produkt od zera - tak, żeby działał na produkcji, z prawdziwymi użytkownikami i pieniędzmi, z BLIK-iem w kasie, logowaniem przez bank i gotowością na KSeF. Chcę, żebyś wiedział to od razu, bo zmienia to, o co w ogóle warto prosić.

Dlaczego AI dowozi do 80% i tam staje

Lovable, Bolt i v0 wspaniale szybko robią tę część, która jest widoczna - przyciski, formularze, ekrany, ładny układ. To mniej więcej 80% tego, co wygląda jak aplikacja. Ale pozostałe 20% - płatności, logowanie, baza danych, deploy, bezpieczeństwo, RODO, przypadki brzegowe - to najtrudniejsza, najdroższa i właśnie ta część, dzięki której aplikacja w ogóle działa z prawdziwymi ludźmi. AI tam nie dopracowuje, tam się rozbija.

Powód jest prosty. Ta widoczna warstwa jest szablonowa: podobnych formularzy i ekranów są w internecie miliony, AI je widziało i odtwarza w mgnieniu oka. A pozostałe 20% jest unikalne dla twojego projektu i wymaga decyzji, które trzeba podjąć, rozumiejąc całość - jak płyną dane, gdzie są przechowywane, kto co może zobaczyć, co się dzieje, gdy płatność P24 nie przejdzie. To nie kopiowanie, lecz inżynieria. I właśnie tam wszystko zaczyna się psuć.

Gdzie psuje się według narzędzia

Każde narzędzie ma swój charakter i swoje typowe miejsce awarii. Znając je, znacznie szybciej rozumiesz, co tak naprawdę masz w rękach.

Lovable — deploy i baza danych

Lovable buduje pełną aplikację (React + Supabase) i sporo ogarnia samo, dlatego na początku wygląda magicznie. Ale psuje się zwykle w dwóch miejscach. Po pierwsze - baza Supabase: gdy model danych robi się bardziej złożony, zaczyna się chaos reguł RLS (bezpieczeństwo na poziomie wiersza), relacje między tabelami się plątają, a zapytania zwracają albo za dużo, albo nic. Po drugie - deploy i środowiska: lokalnie albo w podglądzie Lovable działa, a na prawdziwej domenie z realnymi zmiennymi przestaje, bo klucze, adresy czy CORS skonfigurowano tylko pod tryb demo.

Bolt — state i integracje

Bolt świetnie i bardzo szybko generuje interaktywny frontend. Ściana pojawia się, gdy w aplikacji robi się dużo stanu (state): koszyk, zalogowany użytkownik, filtry, formularze zależne od siebie. Ten state zaczyna uciekać - klikasz w jednym miejscu, odświeża się coś niepowiązanego gdzie indziej. Drugi ból Bolta to integracje z prawdziwymi systemami: płatności, e-mail, zewnętrzne API. Na poziomie demo Bolt pokazuje, jak by to wyglądało, ale do realnego podpięcia BLIK-a czy Przelewy24 potrzebna jest warstwa serwerowa, zarządzanie sekretami i obsługa błędów, których szybkie generowanie nie dowozi.

v0 — ładny UI, ale backend wymaga sprawdzenia

v0 (od Vercela) jest najlepszy z tej grupy w jednym - stworzyć naprawdę ładny komponent interfejsu React/Next.js albo cały widok strony. Potrafi też wygenerować bazę danych, logowanie i logikę serwerową, ale jego mocną stroną jest interfejs. Ludzie utykają, bo mają wspaniale wyglądający ekran i myślą, że zostało tylko podpiąć - a realnie najtrudniejsza część (bezpieczeństwo, logika danych, obsługa błędów) wciąż nie jest sprawdzona.

Cursor — generuje, ale ty musisz rozumieć

Cursor jest inny niż trzy powyższe - to edytor z potężnym AI, dla kogoś, kto już umie czytać kod. Potrafi napisać dużo i szybko. Ale jeśli nie umiesz ocenić tego, co napisał, on po prostu pozwala ci szybciej naprodukować tego, czego nie rozumiesz. Typowy scenariusz: Cursor generuje złożoną logikę, prawie działa, prosisz o poprawkę detalu, on przepisuje więcej, niż trzeba, i nagle masz 2 000 linii, których nie da się ani przeczytać, ani bezpiecznie zmienić. Cursor jest wspaniały dla profesjonalisty i niebezpieczny dla kogoś, kto liczy, że on sam wszystko ogarnie.

Dlaczego AI naprawia i znowu psuje

To jedno z najczęstszych pytań, które słyszę: dlaczego naprawia jedno, a psuje drugie? Odpowiedź to utrata kontekstu. AI nie widzi całego twojego projektu naraz jako spójnego systemu. Przy każdej poprawce pracuje na ograniczonej, widocznej części, pamięta tylko tyle, ile się mieści, i zgaduje resztę. Naprawiając miejsce A, nieświadomie zmienia coś, od czego zależy miejsce B, o którym wtedy nie wiedziało.

Im większy projekt, tym szybciej to koło się rozkręca. Na początku, gdy plików jest mało, AI jeszcze trzyma wszystko w głowie i wygląda wspaniale. Po przekroczeniu pewnego rozmiaru każda nowa poprawka ma coraz większe prawdopodobieństwo, że coś złamie. Prosisz o naprawę częściej, on przepisuje coraz więcej, kod robi się coraz bardziej rozrzucony - i nagle jesteś w kole, z którego AI cię nie wyciągnie, bo to ono jest przyczyną tego koła. To jest dokładnie ten moment, w którym narasta dług techniczny.

Człowiek łamie to koło prosto: trzyma całą architekturę w głowie, rozumie przyczynę, a nie tylko objaw, i naprawia raz tak, żeby zostało naprawione. Tam, gdzie AI łata dziesięć razy, rozumiejący człowiek naprawia raz.

Co zrobić PRZED kontaktem

Jeśli zdecydowałeś, że istniejący kod ma naprawiać człowiek - osoba, która go napisała, albo inny programista - są trzy rzeczy, które przygotowane sprawiają, że wycena idzie szybko i trafnie, a nie jako drogie zgadywanie. Możesz to zrobić sam w pół godziny.

Z tymi trzema rzeczami programista dość szybko powie, czy wystarczą punktowe poprawki, czy taniej przepisać, i jaka jest realna cena. Bez nich - tylko ogólniki, których nikomu nie trzeba. Jeśli wybierasz czyste przepisanie u mnie, z tej listy potrzebuję tylko trzeciego punktu i linku do prototypu: kodu nie przejmuję, więc dostęp do repozytorium nie jest potrzebny.

Ratować czy przepisać?

Najważniejsza decyzja - i możesz ją podjąć sam. Wbrew temu, czego można się spodziewać, nie zawsze poprawną odpowiedzią jest porzuć wszystko i pisz od zera. Logika jest mniej więcej taka.

Sytuacja	Co wybrać
Interfejs porządny, problemy lokalne (nie podpinają się płatności, psuje się deploy, jedna integracja)	Ratować. Punktowe poprawki - sam albo z osobą, która to zbudowała. Często najtańsza droga.
Frontend dobry, ale brak prawdziwego backendu lub modelu danych	Mieszanie. Zostawić frontend i pod nim zbudować czysty backend może autor kodu albo inny programista.
Logika rozrzucona, każda poprawka psuje coś innego, nikt nie rozumie struktury	Przepisać. Wizual staje się specyfikacją, kod pisany jest na czysto od zera - i to jest właśnie moja praca.
To wewnętrzne narzędzie albo demo, nie dla realnych klientów i pieniędzy	Może AI ci wystarczy. Powiem wprost, jeśli nie potrzebujesz mnie.

Chcę podkreślić ostatni wiersz. Jeśli twój projekt to hobby, wewnętrzne narzędzie dla kilkuosobowego zespołu albo wizualizacja pomysłu - AI naprawdę ci wystarczy i właśnie to ci powiem. Nie wciskam pracy tam, gdzie jej nie trzeba. Równie wprost mówię, co robię sam: tylko czyste przepisanie od zera - ratowanie i łatanie zostawiam tobie albo osobie, która zbudowała projekt.

Które narzędzie do czego — i gdzie jego ściana

Krótka tabela, żebyś nie pogubił się przy wyborze. To nie ranking najlepszy-najgorszy, lecz mapa, do jakiej pracy każde jest przeznaczone i gdzie kończy się jego możliwość.

Narzędzie	Do czego się nadaje	Gdzie jest ściana
Lovable	Pełne demo z bazą i logowaniem, szybkie MVP do weryfikacji pomysłu	Reguły Supabase, deploy na prawdziwą domenę, rosnący model danych
Bolt	Interaktywny prototyp frontendu, szybki obraz, jak by to działało	Złożony state, prawdziwe integracje, płatności, warstwa serwerowa
v0	Ładne komponenty i strony React/Next.js, baza UI	Backend, baza i logowanie są generowane, ale wymagają starannej weryfikacji
Cursor	Szybsze tworzenie dla kogoś, kto umie czytać i oceniać kod	Bez zrozumienia szybko produkujesz to, czego już nie kontrolujesz

Jeśli chcesz szerzej o tym, dlaczego prototyp z AI to jeszcze nie produkt i co odróżnia działa na moim ekranie od działa dla realnych użytkowników, pisałem o tym osobno w artykule o vibe codingu. A o ukrytych kosztach darmowych rozwiązań AI przeczytasz w tekście o prawdziwym koszcie darmowej strony z AI.

Realne ramy cenowe

Otwarcie, bo nikt nie mówi tego wprost. Naprawy ani dokończenia na istniejącym kodzie nie oferuję, więc poniżej są moje ceny za czyste przepisanie od zera, w którym twój prototyp staje się specyfikacją (w euro, rozliczenie na fakturę VAT netto):

• MVP / PWA z logowaniem, danymi i deploy (iOS i Android z jednego kodu): od 2 900 €
• Aplikacja biznesowa z płatnościami BLIK/P24 i integracjami, z zachowaniem dobrego wizualu jako specyfikacji: od 6 900 €
• Złożona platforma z kilkoma typami użytkowników i wieloma integracjami: od 14 900 €

Cena zależy od tego, co produkt ma robić, a nie od stanu twojego kodu - dlatego do wyceny kod nie jest mi nawet potrzebny. Lokalne integracje (KSeF, InPost Paczkomaty, raty) wchodzą w zakres projektu - zwykle to poziom aplikacji biznesowej od 6 900 €. Pracuję na stałą cenę za projekt, na fakturę VAT netto, a kod jest twój - bez lock-inu.

Najczęściej zadawane pytania

Czy możesz przejąć mój projekt z Lovable?

Nie. Cudzego ani wygenerowanego przez AI kodu nie przejmuję, nie naprawiam i nie kontynuuję - nawet jeśli jest zsynchronizowany z GitHubem. Zamiast tego przepisuję produkt czysto od zera, a twój prototyp z Lovable traktuję jako specyfikację i wzór wyglądu: ekrany, przepływy i logika, którą wypracowałeś, nie przepadają. Tak jest dla ciebie korzystniej: nie płacisz za rozplątywanie cudzego kodu, nie dziedziczysz chaosu reguł Supabase ani ukrytych luk, a dostajesz porządny fundament, który może utrzymywać każdy programista. Jeśli chcesz kontynuować na istniejącym kodzie, możesz to zrobić sam albo z osobą, która go napisała.

Czy kod z Bolt nadaje się na produkcję?

Frontend często wygląda wystarczająco dobrze, ale gotowy na produkcję to nie tylko ładny interfejs - potrzebne jest porządne zarządzanie stanem, bezpieczny backend, prawdziwa baza danych, logowanie, płatności BLIK i Przelewy24 oraz obsługa błędów. Bolt generuje szybkie demo, a nie tę ciężką warstwę. Dlatego kodu z Bolt nie przejmuję: wizual i przepływy projektu traktuję jako specyfikację, a produkt z niezawodnym backendem i integracjami buduję czysto od zera, żeby działał z prawdziwymi użytkownikami i pieniędzmi.

Dlaczego AI ciągle naprawia i znowu psuje ten sam kod?

Bo AI nie widzi całego projektu naraz i nie ma trwałego kontekstu. Przy każdej poprawce pracuje na ograniczonej, widocznej części kodu, więc naprawiając jedno miejsce nieświadomie psuje inne, o którym zapomniał. Im większy projekt, tym szybciej zaczyna się to błędne koło. Człowiek trzyma całą architekturę w głowie i naprawia przyczynę, a nie objaw, dlatego poprawka zostaje poprawką.

Co przygotować przed kontaktem w sprawie zepsutego projektu z AI?

Zależy od tego, którą drogę wybierasz. Jeśli istniejący kod ma naprawiać osoba, która go napisała, albo inny programista, będzie potrzebować trzech rzeczy: dostępu do kodu (repozytorium GitHub albo wyeksportowany projekt, nie zrzuty ekranu), dostępu do usług (Supabase, Vercel, konta płatności P24 lub PayU, wysyłka maili) oraz 5-10 zdań o tym, co aplikacja ma robić i co konkretnie nie działa. Jeśli wybierasz czyste przepisanie u mnie, kod nie jest potrzebny - wystarczy link do prototypu albo zrzuty ekranów, te same 5-10 zdań o tym, co produkt ma robić, i informacja o kontach, które już masz.

Kiedy warto ratować istniejący kod z AI, a kiedy taniej przepisać?

Ratować warto, gdy interfejs i struktura są porządne, a problemy lokalne - nie podpinają się płatności, psuje się deploy, nie działa jedna integracja. Takie poprawki możesz zrobić sam albo z osobą, która zbudowała projekt. Przepisać taniej, gdy logika jest rozrzucona, nie ma prawdziwego backendu ani modelu danych, a każda poprawka psuje coś innego. Ja pracuję wyłącznie tą drugą drogą: cudzego kodu nie przejmuję, a produkt buduję od zera, traktując twój prototyp jako specyfikację.

Ile kosztuje naprawa lub dokończenie aplikacji wygenerowanej przez AI?

Naprawy ani dokończenia na istniejącym kodzie z AI nie oferuję - możesz to zrobić sam albo z osobą, która go napisała. Moje ceny dotyczą czystego przepisania od zera na bazie twojego prototypu: MVP / PWA (iOS i Android z jednego kodu) - od 2 900 €, aplikacja biznesowa z płatnościami i integracjami (BLIK, KSeF, InPost) - od 6 900 €, złożona platforma - od 14 900 €. Wszystko rozliczam na fakturę VAT netto, ze stałą ceną za projekt. Cena zależy od tego, co produkt ma robić, a nie od stanu twojego kodu, więc do wyceny kod nie jest mi nawet potrzebny.

W skrócie

Lovable, Bolt, v0 i Cursor to świetne narzędzia do tego, do czego są zrobione - szybko pokazać pomysł. Psują się nie dlatego, że są złe, lecz dlatego, że próbujesz z demo zrobić to, co wymaga inżynierii: bezpiecznego backendu, prawdziwych integracji jak BLIK czy KSeF, porządnych danych zgodnych z RODO. AI łata objawy i traci kontekst; człowiek naprawia przyczynę. Jeśli twój projekt utknął - nie rób dwudziestej rundy. Zdecyduj, która droga jest twoja: naprawiać istniejący kod (sam albo z osobą, która go napisała) czy przepisać go czysto. Jeśli wybierasz drugą - opisz, co chciałeś osiągnąć, a twój prototyp stanie się specyfikacją: dobrą pracę zachowuję, a pod nią od zera buduję to, co nie pozwoli jej znowu się zawalić - żeby działała i zarabiała, a nie tylko wyglądała.