Prototyp, który software house wycenia na trzy miesiące pracy, founder bez umiejętności programowania skleja dziś w Lovable w tydzień. Takie historie są prawdziwe i rozumiem osoby prowadzące firmy, które z tej drogi korzystają. Prawdziwy jest też drugi obrazek: produkt wypada świetnie na pokazie dla inwestora, a po wejściu pierwszych płacących klientów zaczyna gubić zamówienia i founder nie ma w zespole nikogo, kto umiałby wskazać przyczynę. Oba scenariusze zaczynają się od tych samych narzędzi i rozchodzą na procesie. Na pytanie, czy vibe coding się opłaca, odpowiadam więc: to zależy, czy razem z tempem generowania kodu rośnie tempo jego sprawdzania.
Co to jest vibe coding i co realnie daje?
Vibe coding to sposób pracy, w którym człowiek opisuje funkcję zwykłym zdaniem („klient wpisuje kod rabatowy, sklep nalicza zniżkę”), a narzędzie AI (Cursor, Lovable czy GitHub Copilot) zamienia ten opis na działający kod. Autor ogląda wynik na ekranie i prosi o poprawki, ale do samego kodu zagląda rzadko albo wcale. Stąd nazwa: praca idzie „na wyczucie”, bez czytania tego, co powstało pod spodem.
Zysk jest policzalny. Prototyp do pokazania inwestorom albo pierwszym klientom powstaje w kilka dni zamiast kilku tygodni, a pierwsza wersja produktu kosztuje ułamek wyceny agencji. Founder sprawdza, czy rynek zapłaci za pomysł, zanim zatrudni programistów, i porzuca nietrafiony kierunek za cenę weekendu, a nie kwartału. W testowaniu pomysłów vibe coding wygrywa z klasycznym developmentem czasem i ceną.
Gdzie powstaje dług jakości?
Dług jakości powstaje w chwili, gdy do produktu trafia kod, którego nikt w firmie nie rozumie. Skalę pokazała analiza 470 propozycji zmian w kodzie (pull requestów) opublikowana w grudniu 2025: kod współtworzony z AI zawierał około 1,7 raza więcej poważnych problemów niż kod pisany przez człowieka, a błędów konfiguracji, o 75% więcej. Te dane rozbieram szerzej w tekście czy kod z AI jest bezpieczny; tutaj skupiam się na tym, co oznaczają dla firmy.
Pierwszy koszt to debugowanie. Aplikacja pada w piątek wieczorem, a osoba, która ją „napisała”, nie wie, gdzie szukać przyczyny, bo nigdy nie czytała własnego kodu; naprawa czeka, aż ktoś z zewnątrz rozbierze projekt na części. Drugi koszt siedzi w konfiguracji i uprawnieniach, czyli w miejscach niewidocznych na ekranie. Baza danych dostępna z internetu bez hasła to najczęściej opisywana wpadka aplikacji zbudowanych w narzędziach AI.
Trzeci koszt to zależności. Narzędzie dopisuje do projektu dziesiątki cudzych bibliotek, wśród nich porzucone albo podszywające się pod popularne, a właściciel produktu zwykle nie wie, że je ma. Czwarty koszt wychodzi na danych klientów. Demo działa na dziesięciu rekordach wpisanych ręcznie; produkcja dostaje tysiące zamówień, polskie znaki, przecinki w kwotach i klientów klikających w tej samej sekundzie. Te przypadki trafiają na żywych użytkowników, bo zabrakło testów, które wyłapałyby je wcześniej.
Jaki proces ratuje tempo bez wpadek?
Cztery elementy: właściciel każdego fragmentu kodu, przegląd zmian przez drugą osobę, automatyczne testy krytycznych ścieżek i bramka jakościowa przed wdrożeniem. Ustawienie całości w małej firmie zajmuje około tygodnia. Firma płaci ten koszt raz, a ochrona działa potem przy każdej zmianie w produkcie.
- Właściciel kodu. Każdy fragment produktu ma przypisaną osobę, która umie wyjaśnić, co ten fragment robi. Jeżeli takiej osoby nie ma, fragment nie idzie do klientów, dopóki ktoś go nie zrozumie albo nie przepisze.
- Przegląd przez człowieka. Zmianę czyta ktoś inny niż autor, zanim trafi na produkcję. Kod z AI dostaje takie samo traktowanie jak kod od pracownika w pierwszym tygodniu pracy, czyli bez kredytu zaufania.
- Testy krytycznych ścieżek. Rejestracja, zamówienie, płatność: automat sprawdza te przepływy po każdej zmianie, bo tam błąd kosztuje najwięcej. Funkcje oparte na modelach językowych wymagają osobnego podejścia, które opisałem w tekście jak testować funkcje AI i LLM.
- Bramka jakościowa. Nowa wersja nie wychodzi do klientów, dopóki testy nie przejdą. Decyzję podejmuje automat, więc zasada obowiązuje też w tygodniu przed ważnym demo, kiedy pokusa, żeby „tym razem puścić”, jest największa.
Kiedy NIE vibe-codować?
Przy płatnościach, danych osobowych, integracjach z systemami klientów i wszystkim, co niesie skutki prawne. Błąd w płatnościach oznacza zwroty, reklamacje i wyjaśnienia z operatorem płatności. Wyciek danych osobowych uruchamia postępowanie przed UODO i obowiązek zawiadomienia osób, których dane wyciekły. Błąd w integracji z systemem klienta psuje relację, na której stoi kontrakt. W tych obszarach oszczędność z vibe codingu bywa mniejsza niż koszt jednego incydentu.
Granica przebiega po koszcie błędu. Prototyp na pokaz, wewnętrzny panel z raportami, strona z formularzem kontaktowym: tu vibe coding daje czyste tempo, bo wpadka kończy się poprawką. Moduł płatności, dane zdrowotne, wymiana danych z magazynem klienta: te fragmenty pisze albo przynajmniej przegląda doświadczony programista, a testy pokrywają je w pierwszej kolejności.
Jak pomagam w QA Sensei
Od 20 lat pracuję w IT, od siedmiu jako inżynier jakości i oglądam projekty budowane z AI z obu stron: te, które utrzymały tempo, i te, które stanęły po pierwszej awarii na produkcji. W QA Sensei robię Bilans Jakości: przegląd projektu, który pokazuje, gdzie produkt powstał bez siatki i które zabezpieczenia ustawić najpierw, z planem naprawy, nie samą diagnozą. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta.