Lovable, Bolt, v0: Kiedy vibe-coded MVP staje się kredytem technicznym

Aplikacje tworzone przez vibe-coding, takie jak Lovable, Bolt i v0, sprawdzają się doskonale jako prototypy i zawodzą jako produkcyjne MVPs. Kiedy taki projekt trafia do rąk inżyniera, przebudowa od podstaw jest nieuchronna, bo porządkowanie struktury, hooków i autoryzacji kosztuje więcej niż rozpoczęcie od nowa. Ten artykuł wyznacza granicę między prototypem, który te narzędzia mogą udźwignąć, a MVP, którego nie są w stanie obsłużyć.

Dziś każdy może kodować. Założyciel bez technicznego wykształcenia może w sobotni ranek opisać aplikację SaaS prostym językiem i przed lunchem mieć ją pod publicznym adresem URL. To prawdziwa zmiana w sposobie, w jaki powstaje oprogramowanie, i przeważnie na korzyść. Przyniosła ona jednak nowy rodzaj błędu, który dwa lata temu jeszcze nie istniał: aplikacje produkcyjne, których nikt w firmie nie potrafi odczytać.

Każdego tygodnia rozmowy z założycielami, którzy uruchomili produkt zbudowany w Lovable, pozyskali pierwszych trzech klientów i trafili na mur, którego nie potrafią opisać. Platforma wykonała pracę. Platforma podjęła też każdą decyzję architektoniczną, zanim założyciel zdążył zorientować się, które z nich były istotne.

Ten artykuł nie jest krytyką Lovable, Bolt ani v0. Narzędzia te mają swoje miejsce na etapie prototypu. Chodzi o wyznaczenie granicy po stronie kupującego: co te narzędzia dostarczają, czego potrzebuje MVP, żeby przeżyć z pierwszym płacącym klientem, oraz schemat porządkowania, który pojawia się w każdym dziedziczonym kodzie.

• Vibe-coding wygrywa na etapie prototypu, gdzie szybkość bije strukturę i nic nie trafia do klientów.
• MVPs zawodzą inaczej niż prototypy. Autoryzacja, wielodostępność, panel administracyjny i obserwowalność są niezbędne od chwili, gdy pierwszy prawdziwy klient się loguje.
• Koszt porządkowania to koszt przebudowy. Każdy odziedziczony vibe-coded MVP jest przebudowywany od podstaw. Build w Lovable był kosztem utopionym, nie zaoszczędzonym czasem.
• Schemat jest powtarzalny. Zła struktura, nadużycie useEffect, zbędne przerenderowania, otwarte trasy backendu, wadliwa autoryzacja, w tej kolejności.
• Używaj Lovable do tego, do czego służy. Dema, wewnętrzne makiety, eksploracja pomysłów. Do wszystkiego, za co płaci klient, potrzebni są inżynierowie.

Każdy może teraz kodować (i to w większości dobrze)

Bariera wejścia do "zbudowałem coś" runęła w 2025 roku. v0 generuje komponent Next.js ze zrzutu ekranu, Lovable tworzy szkielet backendu Supabase z akapitu tekstu, Bolt składa wdrożoną aplikację w jednym czacie, a Replit Agent wykonuje cały cykl, dopóki coś się nie skompiluje.

To prawdziwa korzyść dla eksploracji pomysłów. Osoba bez wykształcenia technicznego, która kiedyś spędzała trzy tygodnie na poszukiwaniu freelancera, może teraz w trzy godziny zweryfikować pomysł w rzeczywistych pikselach. Projektant może zbudować demo na potrzeby prezentacji zamiast makietować je w Figmie. Żaden z tych przypadków użycia nie wymaga produkcyjnej dyscypliny.

Problem pojawia się w kolejnym kroku, kiedy prototyp zostaje przemianowany na "MVP", zaprezentowany płacącemu klientowi i traktowany jako oprogramowanie produkcyjne. Narzędzia nie informują, kiedy ta granica zostaje przekroczona. Założyciel rzadko zdaje sobie sprawę, że do tego doszło.

Granica prototypu a granica MVP

Prototyp to pytanie. MVP to kontrakt.

Prototyp pyta: czy ten pomysł ma sens w pikselach? Działa lokalnie, głośno się psuje i nie trafia do żadnych użytkowników. Tryb awarii to "zauważam błąd i poprawiam prompt". Jest artefaktem uczenia się, a jedynymi eksponowanymi osobami są założyciel i zaufany współpracownik.

MVP to pierwsza wersja, której dotykają płacący klienci. W momencie, gdy dochodzi do wymiany pieniędzy lub danych osobowych, zmienia się też kontrakt dorozumiany. Klient oczekuje, że jego login będzie działał, dane pozostaną prywatne, a aplikacja nie utraci sesji tylko dlatego, że useEffect uruchomił się dwukrotnie. To nie są zaawansowane wymagania, to absolutne minimum.

Większość aplikacji vibe-coded przekracza tę granicę po cichu, bo narzędzie przez cały czas mówiło "production-ready", dostarczając prototyp. Kontrola tej granicy należy do człowieka, nie do technologii: do założyciela, który wie, co MVP musi robić, zanim zacznie przyjmować pieniądze.

Gdy stawka jest finansowa, właściwym krokiem jest zatrudnienie inżynierów, nie szybszy prompt. Buildy MVP realizowane są w stałym terminie od 3 do 5 tygodni, z autoryzacją, rozliczeniami, panelem administracyjnym i obserwowalnością wbudowanymi od pierwszego dnia.

Co naprawdę kryje się w vibe-coded codebases

Kiedy założyciel przekazuje projekt z Lovable lub Bolt z prośbą o porządkowanie, schemat jest tak powtarzalny, że wiadomo, co zostanie znalezione, zanim repozytorium skończy się klonować. Pięć problemów, mniej więcej w kolejności, w jakiej bolą.

Zła struktura. Pliki nazwane od promptu, który je wygenerował, komponenty zagnieżdżone cztery poziomy głęboko bez żadnych granic reużywalności, folder "utils" zawierający całą logikę biznesową aplikacji. Codebase jest zapisem myślenia AI, a nie opisem tego, co robi aplikacja. Dodanie funkcjonalności wymaga przeczytania połowy projektu, żeby znaleźć, gdzie żyje stan.

Nadużycie useEffect. Każde pobieranie danych trafia do useEffect, każda zmiana propsa wywołuje ponowne pobieranie, a efekty zależą od obiektów tworzonych na nowo przy każdym renderowaniu. Aplikacja zasypuje backend zduplikowanymi żądaniami przy pierwszym renderowaniu, a potem zawiesza się, gdy jedno z tych żądań cicho zawodzi. Schemat się komplikuje w momencie, gdy dodawane są formularze.

Zbędne przerenderowania. Stan najwyższego poziomu żyje w dostawcy kontekstu owijającym całą aplikację, więc każdy komponent renderuje się ponownie przy każdym naciśnięciu klawisza. Aplikacja jest powolna przy 10 elementach na liście i nieużywalna przy 100. Naprawa wymaga znajomości React, o którą prompt nigdy nie prosił.

Otwarte trasy backendu. Tabele Supabase z wyłączonym RLS lub ustawionym na "authenticated" bez zakresu wierszy, akcje serwerowe ufające user_id wysłanemu przez klienta, funkcje edge przyjmujące dowolny payload, bo walidacja była w formularzu. Użytkownik w oknie incognito może wylistować każdy wiersz w tabeli.

Wadliwa autoryzacja. Sprawdzenia sesji po stronie klienta, sprawdzenia ról przez porównanie ciągów znaków z polami wymyślonymi przez AI, przepływy resetowania hasła wysyłające ten sam format tokena do każdego użytkownika, sekrety JWT w pliku .env.example zacommitowanym do publicznego repozytorium. Niekiedy klucz anonimowy to jedyna bariera między aplikacją a "jestem teraz adminem".

To nie są przypadki brzegowe. To medianowy wynik sytuacji, gdy "AI dostarczyło to bez inżyniera w pętli", co zostało omówione od strony inżynierskiej w artykule dlaczego oprogramowanie generowane przez AI nadal wymaga inżynieryjnego przeglądu.

"Działa" to najgorszy sygnał, któremu można ufać

Aplikacje vibe-coded często przechodzą pierwsze demo i właśnie tam zaczyna się niebezpieczeństwo. Demo działa, pierwszych 10 znajomych się rejestruje, pierwszy klient płaci i założyciel dochodzi do wniosku, że build był w porządku.

Dług techniczny narasta po cichu, dopóki coś nie wyciągnie go na światło dzienne. Czynniki wymuszające ujawnienie są przewidywalne:

• Pierwszy prawdziwy płacący klient. Jego dane przekraczają granicę autoryzacji. Granica jest brakująca lub błędna. Dowiadujemy się o tym przez zgłoszenie do supportu, nie test CI.
• Pierwsza prośba o funkcję po premierze. Model danych AI zakładał jednego użytkownika na workspace. Klient chce dwóch. Dodanie drugiego użytkownika dotyka 14 plików, których nikt nigdy nie czytał.
• Pierwszy przegląd bezpieczeństwa. Potencjalny klient B2B prosi o dokumenty SOC2 lub pentest. Pentester znajduje otwarte trasy w 20 minut. Transakcja staje lub odpada.
• Pierwsza potrzeba administracyjna. Założyciel chce zwrócić pieniądze klientowi, zablokować bota lub sprawdzić rejestracje z ubiegłego tygodnia. Nie ma strony administracyjnej i nie ma możliwości jej dodania bez przebudowania routingu.
• Pierwsze zdarzenie skalowania. Post blogowy trafia do sieci, ruch skacze, a aplikacja pada, bo każde renderowanie pobiera każdy wiersz. Naprawa to problem z przerenderowaniami opisany powyżej.

Każdy z tych czynników zamienia niewidoczny dług w awarię, utraconą transakcję lub zwrot pieniędzy. Oprocentowanie długu vibe-coded jest zmienne, a bank dzwoni w najgorszym momencie.

Zasada stuprocentowej przebudowy

Istnieje zasada dotycząca dziedziczonych vibe-coded MVPs, która nie została jeszcze raz złamana. Przebudowa od podstaw.

Rozumowanie jest arytmetyczne. Aby uratować codebase z Lovable, trzeba przeczytać każdy plik napisany przez AI, udokumentować model danych, którego założyciel nigdy nie widział, rozplątać łańcuch useEffect, zabezpieczyć trasy, naprawić autoryzację i zrefaktorować strukturę do czegoś, co człowiek może rozwijać. Ta praca to pełna przebudowa z dodatkowym ograniczeniem: nie można zepsuć klientów już korzystających z wadliwej wersji.

Czysta przebudowa na docelowym stosie zajmuje od 3 do 6 tygodni. Salwacja trwa od 8 do 12 tygodni, bo każdy krok porządkowania jest ograniczony przez poprzedni schemat i dane produkcyjne. "Oszczędności" z pierwotnego builda w Lovable nie istnieją, zostały pożyczone na poczet następnej rundy pracy.

Uczciwe podsumowanie dla założyciela: build w Lovable zapłacił za walidację. Wprowadził pierwszych klientów, i to ma realną wartość. Sam kod jest kosztem utopionym. MVP zaczyna się teraz.

Jak wygląda prawdziwy MVP

Dla porównania: produkcyjne MVP zostało dostarczone dla serwisu nieruchomościowego wystawiającego certyfikaty finansowania kupującym nieruchomości, z użyciem własnego workflow zamiast vibe-coded scaffoldu.

Build to platforma full-stack z przepływem finansowania jako głównym elementem konwersji, panelem administracyjnym do zarządzania cyklem życia wniosków i automatycznym generowaniem certyfikatów PDF w obiecanym oknie czasowym obsługi. Stos to Next.js z tRPC dla bezpieczeństwa typów end-to-end, Drizzle na Neon Postgres i Better Auth do zarządzania sesjami. Kontrakt oparty był na modelu dostawy z określonym zakresem.

Ten termin nie jest magiczny. Około 85% każdego nowego projektu na tym stosie to okablowanie, które już istnieje z poprzedniego projektu, bo ten sam zestaw Next.js, React 19, tRPC v11, Drizzle, Neon, Better Auth, Polar, AI SDK 6 via Vercel AI Gateway i Inngest jest używany przy każdym zleceniu. Pozostałe 15% to praca naprawdę unikalna dla danego klienta: logika domenowa, model danych, przepływy. Narzędzia AI przyspieszają te 15% wewnątrz istniejącej struktury, nie zastępują jej.

To jest wersja "AI-native MVP", która przeżywa pierwszego płacącego klienta.

Kiedy jednak warto użyć Lovable, Bolt lub v0

Narzędzie dobiera się do etapu: vibe-coding do dem i eksploracji, inżynierowie do płatnych ścieżek produktowych.

Uczciwe podejście założyciela to uruchomienie prototypu na Lovable, walidacja, a następnie zatrudnienie inżynierów przed pojawieniem się pierwszego płacącego klienta. Błędem jest pozwolenie, żeby samo "działa" przeprowadziło build przez tę granicę.

webvise realizuje buildy MVP w od 3 do 5 tygodni na tym samym stosie, który jest używany dla produkcyjnych SaaS. Autoryzacja, rozliczenia, panel administracyjny i obserwowalność są w pakiecie od pierwszego dnia. Jeśli mają Państwo vibe-coded build, który działa dziś, ale zaczyna stawiać opór, opisz, co obserwujesz i otrzymasz szczerą odpowiedź, czy to przypadek porządkowania czy przebudowy. Do tej pory odpowiedź zawsze brzmiała: przebudowa.