Polityka vibe-coding — Lovable/Bolt/v0 na MVP, Cursor/Claude na produkcję
Pytanie ze scorecard: Jak używasz narzędzi vibe-coding typu Lovable / Bolt / v0 / Replit Agent? Odpowiedź na maks (3 pkt): Świadomie wybieram per-task: vibe-coding na MVP/lead magnety, Cursor/Claude Code na produkcję.
Dlaczego to ważne w 2026
Dział zatytułowany „Dlaczego to ważne w 2026”Narzędzia vibe-coding to przełomowa kategoria softu 2025–2026. Lovable, Bolt.new, v0, Replit Agent, Base44, Figma Make, Magic Patterns — powierzchnia “prompt-to-app” jest wszędzie i dla właściwego zadania jest o rząd wielkości szybsza niż kodowanie ręczne w agencie terminalowym. Pułapka: te same narzędzia, które zmieniają piątkowy pomysł w zdeployowany landing page w dwadzieścia minut, produkują też kod, który w 45% przypadków zawiera podatności bezpieczeństwa, generuje inny wzorzec async w każdej rozmowie i ignoruje design tokeny Twojego zespołu. Maksymalna odpowiedź na Q19 w 2026 to nie “używam narzędzi vibe-coding” i nie “nie tknę ich” — to “mam politykę per-task, która routuje robotę do właściwego tieru”. Ta polityka odróżnia założycieli, którzy wysyłają pięć lead magnetów miesięcznie, od tych, którzy albo wysyłają wolno z prawdziwym codebase, albo szybko ze stertą długu technicznego. Q19 w gruncie rzeczy bada, czy zinternalizowałeś tieringową logikę — tak samo jak Q1 bada agentów terminalowych, a Q3 routing modeli. Odpowiedź, której szuka scorecard: “tak, wiem kiedy każdy tier jest właściwy i potrafię obronić wybór dla dowolnego zadania.”
Jak naprawdę wygląda maksymalny wynik (drzewo decyzyjne per-task)
Dział zatytułowany „Jak naprawdę wygląda maksymalny wynik (drzewo decyzyjne per-task)”Setup na maksymalną Q19 to spisana lub prawie spisana reguła decyzyjna, która siedzi Ci w głowie i którą umiesz wyartykułować w piętnaście sekund. Kształt to krótkie drzewo decyzyjne: kim jest odbiorca, jaki jest okres życia, jakie ryzyko. Używaj narzędzi vibe-coding (Lovable / Bolt / v0 / Replit Agent), gdy artefakt to strona marketingowa, lead magnet, wewnętrzne demo, jednorazowy prototyp, landing page eksperymentu, który ubijesz za trzy tygodnie, albo mock UI, który rzucisz userom na Discordzie w piątek. Używaj agentów terminalowych (Claude Code / Codex CLI / Cursor Agents), gdy artefakt przenosi realne dane userów, ma horyzont utrzymania powyżej trzech miesięcy, integruje się z billingiem lub auth na Twojej platformie, musi pasować do wspólnego codebase albo siedzi gdziekolwiek na ścieżce od “pierwszy płacący klient” do “produkcji”. Używaj obu, sekwencyjnie, gdy output vibe-coding to punkt wyjścia, który przeniesiesz do prawdziwego codebase — wygeneruj UI w v0, skopiuj komponenty do repo produkcyjnego, potem każ Claude Code dopasować je do Twojego design systemu, testów i konwencji. Porównaj to z niższymi tierami: vibe-coding do wszystkiego (1 pkt — produkuje UI gotowe do wysłania i dług techniczny gotowy do wysłania w tej samej prędkości), odmowa tykania narzędzi vibe (1 pkt — zostawia 5–10x przyspieszenie na stole dla lead magnetów i MVP, w których są obiektywnie najlepsze) albo używanie ich bez polityki (2 pkt — czasem słusznie, czasem nie, nigdy z pewnością). Znak rozpoznawczy usera na maks: gdy kolega z zespołu pyta “powinienem użyć Lovable do tego?”, odpowiedź nie brzmi “tak” ani “nie” — pyta o trzy rzeczy o odbiorcy, okresie życia i ryzyku, a potem odpowiada.
Aktualny krajobraz (zweryfikowany przez web search)
Dział zatytułowany „Aktualny krajobraz (zweryfikowany przez web search)”Rynek vibe-coding w 2026 skonsolidował się wokół czterech narzędzi, z których każde ma własny pas: Lovable do pełnostackowych aplikacji webowych dla nie-deweloperów, Bolt.new do prototypowania w przeglądarce bez setupu, v0 do komponentów React + Tailwind w workflow Vercel oraz Replit Agent do end-to-end full-stack łącznie z backendem i bazą. Większość poważnych userów paruje jedno z tych narzędzi z Tier 1 agentem terminalowym, zamiast wybierać tylko jedno — ten sam wzorzec “dwóch narzędzi” co w Q1, tylko cross-tier zamiast w tierze.
Lovable (pełnostackowe aplikacje webowe)
Dział zatytułowany „Lovable (pełnostackowe aplikacje webowe)”Lovable produkuje realnie deployowalne aplikacje z autentykacją, integracją z bazą i responsywnym designem out-of-the-box, zablokowane na stos React + Supabase. Mocne strony: dopracowany jednoklikowy deploy, najlepszy UX dla nie-deweloperów na rynku oraz output, który faktycznie wygląda jak prawdziwy produkt, a nie prototyp. Słabości: lock-in React + Supabase oznacza, że nie przeniesiesz kodu do stosu Next.js + Postgres + Drizzle bez przepisania, a abstrakcje ukrywają tyle hydrauliki, że debugowanie problemów produkcyjnych wewnątrz outputu Lovable jest trudniejsze niż debugowanie kodu, który napisał Twój własny agent. Najlepiej pasuje do landing page’y z auth, marketingowych dem od założycieli, lead magnetów wymagających działającego loginu i całej klasy artefaktów “potrzebuję działającej rzeczy w kształcie SaaS na wieczór”.
Bolt.new (oparty na StackBlitz, w przeglądarce)
Dział zatytułowany „Bolt.new (oparty na StackBlitz, w przeglądarce)”Bolt domyka trójkę najszybszym czasem od prompta do preview oraz zerowo-setupowym doświadczeniem w przeglądarce, które robi z niego idealne narzędzie do szybkiego prototypowania i proof-of-concept. Zbudowany na WebContainers od StackBlitza (całe środowisko dev działa w karcie przeglądarki), Bolt pozwala wybrać framework — React, Vue, Svelte, Next.js — i jest częściowo open source. Mocne strony: najszybsze pierwsze preview w kategorii, brak kroku instalacji, swoboda frameworka i najczystsze doświadczenie “podziel się URL-em z działającą apką” do dem. Słabości: cięższe interaktywne ficzery (własne backendy, persistentny storage, długie joby) uderzają w sufit WebContainerów, a model in-browser sprawia, że długie sesje czują się wolniejsze niż w Lovable czy v0, gdy projekt urośnie ponad kilkadziesiąt plików. Najlepiej pasuje do proof-of-concept, artefaktów hackathonowych, porównań frameworków i każdej sytuacji, w której odpowiedź brzmi “muszę po prostu komuś pokazać, jak to by wyglądało”.
v0 od Vercel (komponenty React + Tailwind)
Dział zatytułowany „v0 od Vercel (komponenty React + Tailwind)”v0 ma najgładszy, najszybszy i najbardziej dostępny flow publikacji i deployu spośród wszystkich tych narzędzi, bo siedzi wewnątrz ekosystemu Vercel i wysyła kod prosto na preview URL. Output to domyślnie React + Tailwind, zoptymalizowany pod wzorce komponentów shadcn/ui, celowany w deweloperów, którzy już piszą React i chcą, żeby ktoś zrobił im scaffolding UI. Mocne strony: najczystszy kod wyjściowy w całej kategorii (komponent z v0 możesz wrzucić do prawdziwego repo Next.js niemal bez przepisywania), ścisła integracja z Vercel oraz najlepsze dopasowanie, gdy cel to “wygeneruj UI, potem zabierz go do codebase”. Słabości: słabsze pod kątem full-stack i backendu niż Lovable czy Replit, mniej odpowiednie dla nie-deweloperów, którzy chcą jednoklikowego deployu, a wyrośniesz z niego szybko, jeśli potrzebujesz czegokolwiek poza dopracowanym komponentem albo stroną. Najlepiej pasuje do generowania komponentów, eksploracji designu, sekcji landing page’y oraz workflow “vibe-coding jako punkt wyjścia”, gdzie output ma być przeniesiony.
Replit Agent
Dział zatytułowany „Replit Agent”Tam gdzie Lovable i Bolt.new są przede wszystkim narzędziami frontendowymi, Replit jest full-stack — powiedz mu “zbuduj mi system loginu”, a postawi frontend, backend i bazę w jednym ruchu, bez konieczności łączenia osobnych serwisów. Mocne strony: jedyne narzędzie w kategorii, które realnie ogarnia cały stos wewnątrz jednego workspace, łącznie z hostingiem i deployem; najlepiej pasuje do end-to-end MVP wymagających persistencji i auth bez objazdu przez Supabase; oraz najmocniejsza narracja “mogę przy tym pracować przez tygodnie”, bo workspace to prawdziwe środowisko dev z terminalami i package managementem. Słabości: metafora workspace’a jest cięższa niż wzorzec “prompt-i-deploy” Lovable czy Bolta, więc pierwsze doświadczenie aplikacji jest wolniejsze dla nie-deweloperów, a cennik skaluje się szybciej na długo działających projektach niż na weekendowych prototypach. Najlepiej pasuje do full-stack MVP, narzędzi wewnętrznych, gdzie zarządzasz warstwą danych, oraz projektów pobocznych, które mogą przeżyć demo i potrzebują miejsca na życie.
Gdzie kończy się ich sufit (kod produkcyjny, złożone auth, własne backendy)
Dział zatytułowany „Gdzie kończy się ich sufit (kod produkcyjny, złożone auth, własne backendy)”Wszystkie cztery narzędzia dzielą ten sam sufit i to właśnie tam polityka maksymalnej Q19 zarabia na siebie. Do 45% kodu generowanego przez AI zawiera podatności bezpieczeństwa — niewystarczająca walidacja inputu, domyślne zaufanie do wejścia od usera, SQL injection, XSS oraz flowy auth, które wyglądają OK, ale przeciekają w edge cases. Narzędzia vibe generują kod z generycznych wzorców, nie wiedzą, że istnieje Twoja biblioteka komponentów, nie widziały Twoich design tokenów i nie egzekwują konwencji zespołu — więc output jest luźno połączony z niczym i nie zmerguje się czysto. Priorytetyzują szybkość kosztem przemyślanego designu systemu i generują różne wzorce dla podobnych problemów nawet w tej samej rozmowie (async/await jednego dnia, promise chains następnego). Miejsca, w których realnie się zatykają: produkcyjne flowy auth z obsługą session/token, własne backendy podpięte pod istniejące serwisy, cokolwiek nośnego na realnych danych userów, cokolwiek, co musi wmergować się do wspólnego codebase, oraz cokolwiek z horyzontem utrzymania na tyle długim, że niespójności Cię dogonią. Fix to nie przestać ich używać — fix to wiedzieć dokładnie, do którego pasa należą, i spisać politykę.
Krok po kroku: jak napisać swoją politykę per-task
Dział zatytułowany „Krok po kroku: jak napisać swoją politykę per-task”- Zaudytuj ostatnie dziesięć artefaktów. Dla każdego projektu pobocznego, landing page’a, lead magnetu, MVP i ficzera produkcyjnego zapisz (a) odbiorcę — wewnętrzne demo, marketingowy wizytator, płacący user, (b) okres życia — tydzień, miesiąc, rok+, (c) ryzyko — czy dotyka płatności, auth, danych klientów. Większość ludzi jest zaskoczona, że 6–8 z 10 to obiektywnie niskie ryzyko, krótki okres życia, frontowanie marketingowe — dokładnie tam, gdzie narzędzia vibe są bezkonkurencyjne.
- Spisz swoją trzy-pytaniową regułę. Odbiorca (wewnętrzny/marketingowy/demo vs. płacący klient lub wspólny codebase), Okres życia (≤3 miesiące vs. >3 miesiące), Ryzyko (bez płatności/auth/danych klientów vs. cokolwiek z tych). Jeśli jakakolwiek odpowiedź wskazuje na “produkcję”, routuj task do agenta terminalowego. Jeśli wszystkie trzy wskazują “throwaway”, routuj do narzędzia vibe. Przypnij regułę gdzieś —
CLAUDE.md, strona Notion, karteczka. Nie działa, jeśli nie jest spisana. - Wybierz jedno narzędzie vibe-coding, które przejmie każdy pas. Nie próbuj używać wszystkich czterech. Domyślna rekomendacja: Lovable, jeśli wysyłasz lead magnety i artefakty marketingowe z auth, v0, jeśli generujesz UI, które przeniesiesz do codebase Next.js, Bolt, jeśli potrzebujesz najszybszego prototypu w przeglądarce, Replit Agent, jeśli chcesz jednego workspace na całe MVP. Drugie możesz dodać później, ale start od jednego narzędzia na pas to to, co sprawia, że polityka jest faktycznie wykonalna.
- Zbuduj drill “vibe-to-prod”. Dla artefaktów, które zaczynają w narzędziu vibe i awansują do produkcji, spisz 30-minutową checklistę portu: wyekstrahuj komponenty, wrzuć je do prawdziwego repo, przepuść Claude Code przez katalog z promptem “dopasuj je do naszego design systemu, konwencji i testów”, zreviewuj diff, wyślij. Za pierwszym razem port trwa dwie godziny; za trzecim razem to 30 minut, które zabudżetowałeś. Ten drill sprawia, że vibe-coding to “szybki prototyp ze ścieżką do produkcji”, a nie “throwaway bez awansu”.
- Dodaj test na wyjściu. Każdy artefakt vibe-coded, który zbliża się do prawdziwego klienta, dostaje co najmniej jeden test przed wysłaniem — test Playwright happy-path na zdeployowanym URL, test Vitest na krytycznym helperze, ręczny smoke test ze świeżej przeglądarki. Chodzi nie o pełne pokrycie; chodzi o pokonanie statystyki “45% kodu ma podatności” jednym świadomym sprawdzeniem. Bez tego kroku wracasz na 1 pkt — szybki i zepsuty.
- Ustaw kwartalny review “ubij albo awansuj”. Artefakty vibe-coded mają okres półtrwania. Co kwartał spójrz na to, co wysłałeś przez narzędzia vibe, i zdecyduj dla każdego: ubij (lead magnet zrobił swoje, zdejmij), awansuj (port do prawdziwego codebase drillem z kroku 4) lub przedłuż (zostaw na hostingu narzędzia vibe, bo odbiorca i okres życia się nie zmieniły). Bez tego review throwaways zamieniają się w długoogonowe zobowiązania, bo nikt nigdy nie wraca do oryginalnego założenia o okresie życia.
- Udokumentuj politykę i podziel się nią z zespołem. Jeśli pracujesz sam, to akapit w Twoim
CLAUDE.md. Jeśli z zespołem, to akapit w handbooku inżynierskim plus wątek na Slacku odpowiadający na “kiedy używamy Lovable vs. Claude Code?”. Polityka da maks Q19 tylko wtedy, gdy inni mogą ją stosować bez Ciebie w pokoju. Artefaktem jest spisana reguła, a nie wypowiedziana. - Broń wyboru co najmniej raz w tygodniu. Wypatruj dwóch trybów awarii: kolega routuje ficzer produkcyjny do Lovable, “bo szybciej” (re-routuj do Claude Code, wytłumacz koszt utrzymania), albo kolega koduje ręcznie landing page lead magnetu przez dwa dni, “bo narzędzia vibe są niechlujne” (re-routuj do Lovable, wytłumacz okres życia). Polityka przeżywa, gdy jest broniona w momentach, w których łatwa odpowiedź jest zła. Po jakichś sześciu tygodniach bronienie się kończy, bo zespół zinternalizował wybór.
Częste pułapki
Dział zatytułowany „Częste pułapki”- Deployowanie outputu vibe-coded prosto na produkcję bez portu. Najdroższy błąd Q19. Artefakt wychodzi, zdobywa płacącego usera, założyciel zapomina, że to było vibe-coded, sześć tygodni później jest SQL injection w polityce wiersza Supabase, której nikt nie potrafi znaleźć. Jeśli niesie realne dane userów, portuj go do prawdziwego codebase, zanim dotknie go pierwszy nie-wewnętrzny user. 30-minutowy drill z kroku 4 jest tani; po-incydentalne przepisywanie nie.
- Brak pokrycia testami na zdeployowanym artefakcie. Obietnica “dodam testy później”, która zamieniła się w “nigdy nie dodaliśmy testów” w momencie, gdy artefakt zdobył trakcję. Nawet jeden test Playwright happy-path na żywym URL łapie najgorsze regresje, a kosztuje jakieś pięć minut, gdy masz już harness. Bez tego kroku wracasz do statystyki “45% kodu ma podatności” i wysyłasz to bezpośrednio do klientów.
- Kod vibe poza version control. Lovable i Bolt ułatwiają trzymanie kodu wewnątrz workspace’a narzędzia i niewypchniecie go do GitHuba. To OK dla prawdziwego throwawaya, ale w momencie, gdy artefakt ma płacącego usera albo okres życia powyżej trzech miesięcy, “kod nie w gicie” to single-point-of-failure — outage vendora, utrata konta, przypadkowy delete i kodu nie ma. Wypchnij export do prywatnego repo na GitHubie pierwszego dnia, nawet jeśli nigdy nie będziesz tam edytować.
- Używanie narzędzi vibe-coding do produkcji, “bo szybko”. Najszybsza droga do produkcji w 2026 nie polega na vibe-codingu całego stosu. Polega na vibe-codingu UI, porcie do prawdziwego codebase agentem terminalowym i wysłaniu w jeden dzień. Instynkt “szybko”, który omija port, to ten sam instynkt, który wysyła SQL injection. Szybki i trwały oba przegrywają z szybkim i nieuczciwym.
- Odmowa tykania narzędzi vibe, “bo prawdziwi inżynierowie tak nie robią”. Lustrzany tryb awarii. Założyciel spędza dwa dni, kodując ręcznie landing page lead magnetu, który Lovable wysłałby w dwadzieścia minut, potem nie wysyła kolejnych czterech lead magnetów, bo per-magnet koszt jest za wysoki. Narzędzia vibe są bezkonkurencyjne w swojej konkretnej robocie; artefakt zakodowany ręcznie nie jest bardziej cnotliwy, gdy odbiorca i tak nigdy nie widzi kodu.
- Traktowanie “MVP” jako jedynej kategorii. “MVP” robi za dużo roboty — czasem znaczy “wewnętrzne demo dla zespołu”, czasem “pierwsza wersja, której użyje płacący klient”. Pierwsza zostaje na artefakcie vibe-coded miesiącami; druga musi awansować w dniu, w którym dostanie ruch. Używaj trzy-pytaniowej reguły, a nie słowa “MVP”, do decyzji.
Jak sprawdzić, czy już tam jesteś
Dział zatytułowany „Jak sprawdzić, czy już tam jesteś”- Umiesz wyartykułować swoją trzy-pytaniową regułę decyzyjną (odbiorca / okres życia / ryzyko) w piętnaście sekund bez zaglądania do notatek.
- Polityka jest spisana gdzieś, gdzie zespół może ją znaleźć —
CLAUDE.md, handbook inżynierski albo przypięta wiadomość na Slacku. - Masz jedno narzędzie vibe-coding, które przejmuje każdy pas (np. Lovable na lead magnety, v0 na generowanie UI) — nie cztery otwarte karty.
- Masz drill “vibe-to-prod”, który zajmuje ≤30 minut dla typowego artefaktu.
- Każdy artefakt vibe-coded skierowany do klienta ma co najmniej jeden zautomatyzowany test na zdeployowanym URL.
- Cały kod vibe-coded żyje w prawdziwym repo gita, a nie tylko wewnątrz workspace’a narzędzia.
- Odpalasz kwartalny review “ubij albo awansuj” na wysłanych artefaktach vibe.
- Bronisz wyboru routingu co najmniej raz ostatnio — wytłumaczyłeś koledze, dlaczego nie używać Lovable na produkcję, albo dlaczego użyć go na lead magnet.