Przejdź do głównej zawartości

Polityka vibe-coding — per-tier z kryteriami przejścia

Pytanie ze scorecard: Jaka jest polityka zespołu dla Lovable / Bolt / v0 / Replit Agent? Odpowiedź na maks (3 pkt): Świadoma polityka per-tier: vibe-coding na MVP/lead magnety, Cursor/Claude Code na produkcję, jasne kryteria przejścia.

Dlaczego to ważne w 2026 (szybkość prototypu vs ryzyko produkcji)

Dział zatytułowany „Dlaczego to ważne w 2026 (szybkość prototypu vs ryzyko produkcji)”

Vibe-coding ściska pętlę “od pomysłu do interesariusza” z dni do godzin. Założyciel walidujący pozycjonowanie w poniedziałek rano jeszcze niedawno potrzebował designera, frontend engineera i całego sprintu. W połowie 2026 ten sam założyciel otwiera Lovable, wpisuje akapit i wchodzi na call o 11:00 z działającym URL-em, prawdziwym auth i linkiem do Stripe. Ta szybkość nie jest marginalna — to zmiana kategorii w tym, jak produkt, marketing i inżynieria koordynują się w małym zespole.

Ale deployment produkcyjny z tych narzędzi to osobna klasa ryzyka. Do 45% kodu generowanego przez AI zawiera eksploitowalne podatności bezpieczeństwa — niewystarczającą walidację inputu, domyślne zaufanie do wejścia od usera, powierzchnie SQL injection, XSS oraz flowy auth, które wyglądają OK, ale przeciekają w edge cases. Narzędzia vibe-coding generują kod od zera używając generycznych wzorców, nie wiedzą, że Twoja biblioteka komponentów istnieje, nie widziały Twoich design tokenów i nie egzekwują Twoich konwencji. Output nie zmerguje się czysto z prawdziwym codebase. W Q1 2026 CEO Replit publicznie nazwał incydent produkcyjny “nieakceptowalnym i takim, który nie powinien być możliwy” — bo, słowami szeroko udostępnianego wątku, w aplikacji vibe-coding nie ma sposobu wymuszenia code freeze.

Q16 pyta, czy Twój zespół to zinternalizował — nadzwyczajne w produkowaniu działającego oprogramowania w godzinach, jeszcze niegodne zaufania w utrzymywaniu go dla płacących klientów. Odpowiedź na maks nie brzmi “pozwalamy wszystkim używać Lovable” ani “zbanowaliśmy to” — brzmi “mamy politykę per-tier z jawnymi kryteriami przejścia i każdy inżynier umie ją wyartykułować w piętnaście sekund”. To zespołowy odpowiednik indywidualnego vibe-coding-policy z Developer Scorecard: pytanie deweloperskie bada, czy Ty potrafisz wyroutować task; pytanie CTO bada, czy Twój zespół to robi — konsekwentnie, broniąc się, bez Ciebie w pokoju.

Jak naprawdę wygląda maksymalny wynik (dokument polityki per-tier + bramka przejścia)

Dział zatytułowany „Jak naprawdę wygląda maksymalny wynik (dokument polityki per-tier + bramka przejścia)”

Maksymalna polityka zespołowa na Q16 ma cztery widoczne artefakty. Jeśli któregokolwiek brakuje, jeszcze tam nie jesteś.

  • Spisana 1-stronnicowa polityka w handbooku inżynierskim nazywająca, które narzędzia vibe-coding są usankcjonowane, dla których tierów każde jest preferowane oraz kto pilnuje bramki przejścia.
  • Trzy-tierowa klasyfikacja: Tier 0 (terytorium vibe-coding — lead magnety, strony marketingowe, wewnętrzne dema, throwaway prototypy), Tier 1 (mieszane — MVP, które mogą przejść do produkcji), Tier 2 (produkcja — realne dane klientów, auth, płatności, wspólny codebase). Każdy artefakt dostaje tier w dniu pierwszym.
  • Jawne kryteria przejścia — checklista warunków, w których artefakt Tier 0 lub Tier 1 musi zmigrować do prawdziwego codebase zreviewowanego przez Cursor albo Claude Code: pierwszy płacący klient, integracja płatności, przechowywanie PII, przekroczenie trzech miesięcy okresu życia, drugi inżynier musi tego dotknąć, scope compliance (SOC 2, GDPR, HIPAA).
  • Udokumentowana ścieżka migracji — 30-do-60-minutowy drill: wyekstrahuj komponenty, wrzuć do repo produkcyjnego, odpal Claude Code z promptem dopasowania do design systemu / testów / konwencji, zreviewuj diff, wyślij.

Self-test: zapytaj trzech inżynierów “mamy lead magnet, który właśnie dostał pierwszego płacącego klienta — co robimy?”. Trzy zgodne odpowiedzi nazywające kryterium przejścia i drill migracji = 3 punkty. Wzruszenia ramion albo trzy różne odpowiedzi = 1 lub 2.

Lovable / Bolt / v0 / Replit Agent (aktualne możliwości)

Dział zatytułowany „Lovable / Bolt / v0 / Replit Agent (aktualne możliwości)”

Rynek skonsolidował się w 2026 wokół czterech narzędzi, z których każde ma własny pas.

  • Lovable wysyła pełnostackowe aplikacje webowe z auth, bazą i responsywnym designem out-of-the-box — zablokowany na React + Supabase. Najbardziej dopracowany jednoklikowy deploy, najlepszy UX dla nie-deweloperów w kategorii. Najlepiej pasuje do landing page’y z auth, marketingowych dem założycieli, lead magnetów wymagających działającego loginu.
  • Bolt.new ma najszybszy czas prompt-to-preview oraz zerowo-setupowe doświadczenie w przeglądarce na WebContainers od StackBlitza. Wybierasz framework — React, Vue, Svelte, Next.js — stawia pełne środowisko dev w karcie. Najlepiej pasuje do artefaktów proof-of-concept, hackathonowych, porównań frameworków.
  • v0 od Vercel produkuje najczystszy output — komponent z v0 wpada do prawdziwego repo Next.js niemal bez przepisywania. React + Tailwind, zoptymalizowany pod shadcn/ui, ścisła integracja z Vercel. Najlepiej pasuje do generowania komponentów UI, sekcji landing page’y, workflow “vibe-coding jako punkt wyjścia, potem awans”.
  • Replit Agent jest jedynym narzędziem realnie ogarniającym cały stos wewnątrz jednego workspace — frontend, backend, bazę, hosting, deploy. Replit posiada też certyfikację SOC 2 Type II od początku 2026, postawę, której ani Bolt, ani Lovable publicznie nie dorównały. Najlepiej pasuje do end-to-end MVP wymagających persistencji i auth bez objazdu przez Supabase, narzędzi wewnętrznych zarządzających warstwą danych.

Gdzie kończy się ich sufit (auth, płatności, złożone backendy)

Dział zatytułowany „Gdzie kończy się ich sufit (auth, płatności, złożone backendy)”

Wszystkie cztery narzędzia dzielą ten sam sufit. Konkretne tryby awarii udokumentowane w enterprise’owych studiach z 2026:

  • Jakość kodu degraduje się ostro przy złożonych ficzerach — wskaźniki sukcesu w enterprise spadają do około 31% przy wieloetapowych ficzerach poza 3–5-komponentowym MVP.
  • Produkcyjne flowy auth — happy path wygląda OK, edge cases przeciekają: odświeżanie tokenu pod obciążeniem, sesje multi-tab, ścieżki przejęcia konta, CSRF między vibe-coded frontendem a osobnym backendem.
  • Integracja płatności — weryfikacja sygnatury webhooków Stripe, klucze idempotencji, flowy zwrotów i sporów. Generowany kod regularnie pomija część krytyczną dla bezpieczeństwa, a nie zauważysz, dopóki audytor nie zauważy.
  • Własne backendy — narzędzia vibe-coding zakładają własny backend albo Supabase. Wszystko wołające Twoje istniejące API, kolejkę albo workera jest luźno połączone; generowany klient kłamie o tym, co Twój backend akceptuje.
  • Scope compliance — SOC 2, ISO 27001, EU AI Act, HIPAA i GDPR są zakresowane do znanych systemów. Jeśli artefakt vibe-coded dotyka danych klientów, a framework audytowy nie wie, że istnieje, następny audyt zrobi się brzydki szybko.
  • Dryf wzorców wewnątrz jednej sesji — async/await w jednych plikach, promise chains w innych, .then() callbacks w pozostałych — koszmar utrzymania, który się kumuluje.

Fix to nie przestać używać tych narzędzi. Fix to wiedzieć, do którego pasa należą, spisać politykę i bramkować granicę Tier 0–Tier 2 jawnymi kryteriami przejścia.

Kryteria przejścia (kiedy prototyp staje się “musi zmigrować”)

Dział zatytułowany „Kryteria przejścia (kiedy prototyp staje się “musi zmigrować”)”

Artefakt vibe-coded musi przejść w dniu, w którym którykolwiek z tych triggerów odpali:

  • Pierwszy płacący klient. Nie pierwszy signup, nie pierwsze demo — pierwszy dolar. Powierzchnia ryzyka zmienia się w momencie, gdy pieniądze się ruszą.
  • Integracja płatności idzie na żywo. Nawet jeden checkout Stripe na produkcji. Webhooki i flowy sporów to nie terytorium vibe-coding.
  • Przechowywane jest PII klienta. Nazwiska, e-maile, dane płatnicze, cokolwiek regulowanego. Włącza się scope SOC 2 i RODO.
  • Przekroczony trzymiesięczny okres życia. Obietnica “wyrzucę to” pozostała niespełniona. Zaczynają gryźć dryf wzorców i gnicie zależności.
  • Drugi inżynier musi tego dotknąć. Dwuosobowe ownership bez prawdziwego codebase to koszmar onboardingu i silos wiedzy.
  • Włącza się scope compliance. Okno audytu SOC 2, rozszerzenie scope HIPAA, klasyfikacja tieru EU AI Act — cokolwiek w scope audytowym musi być w prawdziwym codebase z prawdziwym łańcuchem review.
  • Trafiony sufit wydajnościowy. Limity WebContainerów i hostowanych runtime’ów na Bolt i Lovable; cold starts i throttling kwoty na Replit. Gdy artefakt zwalnia w skali, migracja jest spóźniona.

Te triggery są celowo konkretne. “Kiedy poczuje się gotowe na produkcję” to nie kryterium — to wymówka, żeby nigdy nie przejść.

Ścieżka migracji (kod vibe-coding → zreviewowany rewrite w Cursor/Claude Code)

Dział zatytułowany „Ścieżka migracji (kod vibe-coding → zreviewowany rewrite w Cursor/Claude Code)”

Drill przejścia to to, co powstrzymuje politykę przed zwinięciem się do “no to vibe-codujemy na produkcji”. Kształt, który działa w 2026:

  1. Wyekstrahuj i zaudytuj. Wciągnij działający output do prawdziwego repo gita w dniu pierwszym. Przeczytaj kod. Zanotuj, co robi robotę, a co jest scaffoldingiem.
  2. Wrzuć do produkcyjnego codebase jako moduł kwarantanny. Nie mergować wprost. Wrzuć do nazwanego katalogu (/quarantine/lead-magnet-X/) i izoluj zależności.
  3. Odpal Claude Code albo Cursor na moduł kwarantanny. Prompt: “dopasuj ten katalog do naszego design systemu, wzorca auth, konwencji testów, strictness TypeScript i konfiguracji ESLint. Wypowierzchnij każdą sprzeczność z wzorcami naszego codebase”. Zreviewuj diff.
  4. Dodaj testy na granicach krytycznych dla bezpieczeństwa. Auth, płatności, walidacja danych, każde wołanie zewnętrznego API. Artefakty vibe-coded prawie zawsze wychodzą bez tych testów; migracja to moment, gdy są dodawane.
  5. Code review z seniorem IC. Bramka. Robota seniora IC: znaleźć to, czego AI nie wyflagowało — niejawne założenia, brakującą walidację inputu, hardcoded secrety, dryf od modelu zagrożeń zespołu.
  6. Promuj, monitoruj dwa tygodnie, ubij oryginalny URL. Jeśli oryginalny URL Lovable / Bolt / Replit nadal odpowiada na requesty trzy miesiące po migracji, masz dwie powierzchnie produkcyjne dla tego samego ficzera. Wybierz jedną.

Pierwsza migracja zajmuje cały dzień. Trzecia 30 minut. Drill sprawia, że przejście jest rutynową aktywnością, a nie heroicznym refaktorem.

Krok po kroku: jak napisać swoją politykę zespołową

Dział zatytułowany „Krok po kroku: jak napisać swoją politykę zespołową”
  1. Zaudytuj ostatnie dwadzieścia artefaktów. Landing page’y, lead magnety, MVP, narzędzia wewnętrzne, ficzery produkcyjne. Dla każdego zapisz (a) odbiorcę (wewnętrzne demo / marketingowy wizytator / płacący klient), (b) okres życia (tydzień / miesiąc / rok+), (c) ryzyko (płatności, auth, dane klienta albo nic z tych). Większość zespołów odkrywa, że 12–15 z 20 to obiektywnie niskie ryzyko, krótki okres życia, marketing — dokładnie tam, gdzie vibe-coding wygrywa.

  2. Zdefiniuj trzy tiery z konkretnymi przykładami z Twojego produktu. “Tier 0 = lead magnety stron porównawczych, strony CTA dev community, piątkowe linki dem. Tier 1 = przebudowa wizarda onboardingowego, pilot customer-portal. Tier 2 = billing, API gateway, cokolwiek w /apps/api”. Przykłady biją definicje; inżynierowie wyroutują poprawnie, bo dopasują wzorce.

  3. Spisz kryteria przejścia jako checklistę triggerów. Użyj siedmiu triggerów wyżej. Dopasuj: dodaj “pierwszy signup z UE”, jeśli masz ekspozycję RODO; “pojawia się na stronie cenowej”, jeśli masz sales motion. Chodzi o to, żeby zespół umiał odpowiedzieć “czy to powinno przejść teraz?” bez eskalacji do Ciebie.

  4. Wybierz jedno narzędzie vibe-coding na pas. Nie sankcjonuj wszystkich czterech. Default na 2026: Lovable na lead magnety z auth, v0 na generowanie UI portowanego do codebase Next.js, Bolt na najszybsze prototypowanie poza React, Replit Agent na full-stack MVP w jednym workspace. Drugie narzędzie na pas może dojść później.

  5. Zbuduj drill migracji raz i udokumentuj go. Pierwsza migracja to ćwiczenie nauki — niech Twój senior IC zrobi ją widocznie, w nagranej sesji, jeśli się da, potem spisz 30-minutową wersję jako runbook. Pojedynczy artefakt o najwyższej dźwigni w całej polityce.

  6. Postaw bramkę przejścia. Nazwij jednego ownera — lead inżynieryjny albo staff IC — review kandydatów do przejścia. SLA: 5 dni roboczych od triggera do “zatwierdzone / odrzucone z powodem / zaplanowane”. Bramka nie musi być wolna; musi być widoczna.

  7. Opublikuj i odpal 30-minutowe Q&A. Wrzuć doc do handbooku i #engineering. Łap pytania “ale ja chcę dalej używać Lovable do naszego narzędzia admina” na żywo — większość z nich wypowierzchnia artefakty Tier 1, których zespół nie rozpoznał.

  8. Kwartalny review: ubij, awansuj albo przedłuż. Co 90 dni przejdź listę artefaktów vibe-coded i zdecyduj dla każdego: ubij (robota zrobiona, zdejmij), awansuj (odpalił trigger, odpal drill) albo przedłuż (odbiorca i okres życia nadal pasują do Tier 0). Bez tego throwaways zamieniają się w długoogonowe zobowiązania.

  • Kod vibe deployowany na produkcję bez review. Najdroższy tryb awarii Q16. Artefakt wychodzi, łapie płacącego klienta, sześć tygodni później jest SQL injection w polityce row-level-security Supabase, której nikt nie potrafi znaleźć. Drill migracji jest tani; po-incydentalne przepisywanie nie.
  • Brak bramki przejścia w ogóle. “Mamy politykę” plus “nikt nie pilnuje decyzji o migracji” równa się brak polityki. Nazwij jednego ownera z SLA 5 dni.
  • Banowanie vibe-coding z powodu jednego złego incydentu. Sześć miesięcy później marketing wysyła jeden lead magnet na kwartał zamiast jeden na tydzień. Nie banuj narzędzia — bramkuj granicę.
  • Sankcjonowanie wszystkich czterech narzędzi, “bo inżynierowie mogą wybrać”. To samo, co siedmio-narzędziowy tryb awarii tooling-policy. Wybierz jedno narzędzie na pas; wszystko inne przez wyjątek (patrz Q2 · Polityka narzędzi).
  • Brak spisanego drillu migracji. Pierwsza migracja może trwać dzień. Druga musi być runbookiem. Trzecia to 30 minut. Bez runbooka zespół przestaje awansować i zaczyna wysyłać vibe-code na produkcję.
  • Traktowanie “MVP” jako jednej kategorii. “MVP” czasem znaczy “wewnętrzne demo”, czasem “pierwsza wersja, której użyje płacący klient”. Używaj trzy-tierowej klasyfikacji, a nie słowa “MVP”.
  • Artefakty vibe-coded poza version control. Lovable i Bolt ułatwiają trzymanie kodu wewnątrz workspace’a i niewypchnięcie do GitHuba. Z płacącym klientem albo 3+ miesięcznym okresem życia “kod nie w gicie” to single-point-of-failure. Wypchnij export do prywatnego repo pierwszego dnia.
  • Zapomnienie o audycie bezpieczeństwa na przejściu. Drill to moment na walidację inputu, testy auth i audyt secretów. Jeśli drill portuje kod as-is, właśnie awansowałeś 45%-procentowo-podatny artefakt z nazwiskiem zespołu na nim.
  • Spisana 1-stronnicowa polityka istnieje w handbooku inżynierskim, z nazwanymi przykładami tierów i jawnymi kryteriami przejścia.
  • Nowy inżynier umie wyartykułować trzy-tierową klasyfikację i co najmniej trzy triggery przejścia w czasie krótszym niż 30 sekund.
  • Jeden nazwany owner siedzi na bramce przejścia z SLA 5 dni roboczych.
  • Runbook drillu migracji istnieje; najnowsza migracja zajęła mniej niż 60 minut.
  • Każdy artefakt vibe-coded na produkcji ma tier, ownera i udokumentowany status przejścia (awansowany / czeka na trigger / jawny Tier 0).
  • Cały kod vibe-coded żyje w prawdziwym repo gita, a nie tylko wewnątrz workspace’a narzędzia.
  • Kwartalny review “ubij, awansuj albo przedłuż” faktycznie się odbywa; umiesz wyprodukować notatki z dwóch ostatnich review na żądanie.
  • Zespół awansował co najmniej jeden artefakt w ostatnim kwartale albo ma broniące się wyjaśnienie, dlaczego żaden trigger nie odpalił.