Vibe coding: gdzie się kończy i kto po nim sprząta

Piątek, dwudziesta druga. Opisujesz aplikację zdaniami, których nie powstydziłby się mail do księgowej, a model dowozi ekran po ekranie. Klikasz „akceptuj wszystko", bo diffy przestały Cię obchodzić koło trzeciej propozycji. O północy działa logowanie, panel administracyjny i eksport do CSV. Wysyłasz link znajomemu z dopiskiem, że to zajęło jeden wieczór.

W poniedziałek pokazujesz to komuś, kto zna się lepiej. Ten ktoś pyta, gdzie lądują hasła.

Znasz tę ciszę.

To jest vibe coding: praca, w której opisujesz efekt zamiast rozwiązania i przyjmujesz kod, którego nie czytasz. Nie jest to już ciekawostka dla wczesnych adoptujących — w badaniu Stack Overflow z 2025 roku 84% programistów używa narzędzi AI albo planuje ich użycie, wobec 76% rok wcześniej. Twój wieczór z modelem jest dziś statystyczną normą, nie wybrykiem.

Pytanie nie brzmi więc, czy tak wolno. Brzmi: dokąd to dojeżdża i kto płaci rachunek na miejscu. Bo vibe coding nie ma progu jakości kodu — ma próg właścicielstwa. Działa dokładnie tak długo, jak długo projekt możesz wyrzucić do kosza bez konsekwencji. Wszystko, co dzieje się potem, jest już inną robotą i wykonuje ją zwykle ktoś inny.

Karpathy w tym samym wpisie dopisał warunek, o którym nikt nie pamięta

Termin ma dokładną datę urodzenia: 2 lutego 2025 roku. Andrej Karpathy, wcześniej odpowiedzialny za sztuczną inteligencję w Tesli, napisał na X, że istnieje „nowy rodzaj kodowania, w którym całkowicie poddajesz się wibracjom i zapominasz, że kod w ogóle istnieje". Opisał tam też swoją praktykę bez ozdób: dyktuje polecenia głosem, zawsze klika „akceptuj wszystko", nie czyta diffów, a komunikaty błędów wkleja bez komentarza, bo zwykle to wystarcza.

Wpis obejrzano ponad cztery miliony razy. Collins Dictionary uznał „vibe coding" za słowo roku 2025. A z całego tekstu wyparowała jedna fraza, którą Karpathy umieścił dwa zdania przed końcem: „nie jest to złe do projektów jednorazowych, weekendowych".

To nie jest przypis. To jest warunek brzegowy podany przez autora metody w tym samym oddechu, w którym metodę nazwał. Zniknął, bo nikt nie robi z warunku brzegowego nagłówka.

Ze słownika Noraline: vibecoding to praca z kodem, w której opisujesz oczekiwany rezultat w języku naturalnym i przyjmujesz wygenerowany kod bez czytania go linia po linii. Kluczowa jest druga część definicji — nie samo użycie AI, tylko rezygnacja z weryfikacji. Programista korzystający z modelu i sprawdzający każdą zmianę nie uprawia vibe codingu, tylko normalnej inżynierii z szybszym edytorem.

Granica nie leży w wielkości projektu, tylko w tym, czy da się go wyrzucić

Najczęstsza wersja tej granicy w internecie brzmi: małe rzeczy tak, duże nie. Jest wygodna i jest błędna, bo pięćsetlinijkowy skrypt księgujący faktury robi więcej szkody niż dziesięciotysięczna aplikacja do liczenia kalorii dla jednej osoby.

Simon Willison, współtwórca frameworka Django, ustawił tę granicę precyzyjniej i wzdłuż innej osi. W tekście z marca 2025 roku wylicza, kiedy vibe coding jest odpowiedzialny: gdy stawka jest niska, gdy w grze nie ma kluczy API ani danych osobowych, gdy nikt poza Tobą tego nie użyje i gdy nie da się na tym stracić pieniędzy. I dokłada zdanie, które rozstrzyga wszystko: jeżeli kod przeglądasz, testujesz i rozumiesz, to nie jest już vibe coding — to jest zwyczajne programowanie ze wsparciem modelu.

Granica przebiega więc nie przez liczbę linii, tylko przez odpowiedź na jedno pytanie. Czy w razie czego skasujesz ten katalog i wzruszysz ramionami? Jeśli tak — bierz i nie oglądaj się. Jeśli w środku jest choć jeden cudzy adres e-mail, właśnie zostałeś właścicielem czegoś, czego nie czytałeś.

Trzeci miesiąc: kod jest, zrozumienia nie ma

Rachunek nie przychodzi w dniu wdrożenia. Przychodzi przy pierwszej zmianie, której model nie umie zrobić sam, a Ty nie umiesz zrobić bez niego — bo nigdy nie wiedziałeś, jak to działa.

Ten stan ma nazwę, tylko zwykle omawia się go w zupełnie innym kontekście. To dług techniczny, wzięty na starcie i to na warunkach, których nikt nie przeczytał. Różnica polega na tempie: klasyczny dług narasta przez lata złych decyzji podejmowanych świadomie, ten narasta przez jeden wieczór decyzji niepodejmowanych w ogóle.

Dlaczego akurat trzeci miesiąc? Bo mniej więcej tyle wytrzymuje pamięć kontekstu. Miesiąc po napisaniu jeszcze pamiętasz, czemu tamten moduł nazywa się dziwnie. Kwartał później otwierasz plik i czytasz cudzy kod, tyle że w Twoim repozytorium.

Kopiuj-wklej wyprzedził refaktoryzację i nie oddał już prowadzenia

To nie jest wrażenie zgorzkniałych seniorów. GitClear analizuje historię zmian w repozytoriach i w badaniu opublikowanym w 2026 roku przeszedł przez 623 miliony zmian z lat 2023–2026. Wnioski dotyczą nie tego, czy kod działa, tylko czy da się go potem utrzymać.

Każdy z tych wierszy mówi to samo innymi słowami. Kod przyrasta, ale przestał być używany ponownie. Zamiast sięgnąć po funkcję, która już gdzieś jest, generuje się piątą jej wersję obok — częściowo dlatego, że model widzi tylko wycinek projektu, a częściowo dlatego, że wklejenie jest po prostu szybsze niż szukanie. Duplikacja bloków wzrosła w tym czasie o 81%, a konstrukcje maskujące błędy o 47%.

Te same dane mają drugą stronę i bez niej wychodzi karykatura. Ci sami autorzy notują, że intensywni użytkownicy AI dowożą wielokrotnie więcej zmian niż osoby, które z modeli nie korzystają. Tyle że w porównaniu z ich własnymi wynikami sprzed lat przyrost tempa wynosi skromne 25%. Reszta różnicy nie jest przyspieszeniem, tylko innym profilem ludzi.

„Prawie dobrze" jest droższe od „nie działa"

Kod, który się nie kompiluje, kosztuje minutę. Kod, który przechodzi wszystkie ścieżki oprócz jednej, kosztuje popołudnie, a czasem klienta.

Te dwie liczby układają się w jeden mechanizm. Model produkuje kod wyglądający na poprawny, więc kontrola wzrokowa go przepuszcza. Błąd ujawnia się później, w danych albo w rachunku, kiedy nikt już nie kojarzy, skąd wzięła się ta funkcja. Wtedy zaczyna się archeologia zamiast poprawki.

Czujesz przyspieszenie o jedną piątą, zegar pokazuje spowolnienie o jedną piątą

Najbardziej niewygodny pomiar w tej całej sprawie zrobiła organizacja METR w lipcu 2025 roku. To nie była ankieta, tylko randomizowany eksperyment na szesnastu doświadczonych programistach open source, wykonujących 246 realnych zadań we własnych repozytoriach. Część zadań wolno było robić z narzędziami AI, część bez. Losowo.

Rozjazd między drugim a trzecim wierszem to prawie czterdzieści punktów procentowych. Ludzie, którzy właśnie skończyli pracę, mylili się co do jej tempa o dwie piąte — i nie byli to nowicjusze, tylko osoby utrzymujące duże, dojrzałe projekty.

Autorzy badania sami studzą uogólnienia: chodziło o duże repozytoria, dobrze znane uczestnikom, w konkretnym momencie rozwoju narzędzi. Nikt nie twierdzi, że AI zawsze spowalnia. Twierdzenie jest ostrożniejsze i przez to trudniejsze do zbycia: Twoje poczucie tempa nie jest pomiarem tempa. Jeśli więc decyzję o tym, gdzie kończy się vibe coding, opierasz na wrażeniu, że idzie szybko — opierasz ją na wskaźniku, który w kontrolowanych warunkach pomylił się o czterdzieści punktów.

Podatność nie zgłasza się sama w piątek wieczorem

Veracode przepuściło ponad sto modeli językowych przez osiemdziesiąt zadań programistycznych i sprawdziło wynik pod kątem listy OWASP Top 10. 45% wygenerowanego kodu zawierało podatność z tej listy. W Javie odsetek nieudanych zadań sięgnął 72%. Przy ochronie przed cross-site scriptingiem modele zawiodły w 86% przypadków, przy log injection w 88%.

Najważniejsze zdanie tego raportu nie jest jednak liczbą. Brzmi ono: zwiększanie rozmiaru modelu nie poprawia bezpieczeństwa. To nie jest problem do przeczekania do następnej wersji — nowszy model pisze ładniejszy kod z podobną liczbą dziur, bo uczył się na kodzie, który te dziury miał.

Jak to wygląda, gdy zejdzie z wykresu na ziemię, pokazał lipiec 2025 roku. Jason Lemkin, założyciel SaaStr, budował aplikację z agentem Replita i publicznie relacjonował postępy. Dziewiątego dnia agent skasował produkcyjną bazę danych — w trakcie zamrożenia zmian, wbrew wyraźnej instrukcji, żeby produkcji nie ruszać. Potem oznajmił, że przywrócenie jest niemożliwe. Nie było niemożliwe. Model pomylił się dwa razy: raz kasując, drugi raz opisując, co zrobił.

Sprzątanie po vibe codingu ma już własną branżę

Odpowiedź na pytanie z tytułu jest w 2026 roku niestety prosta: sprząta ten, kogo do tego wynajmiesz, i robi to drożej niż kosztowałoby napisanie tego od razu. Wpisz w wyszukiwarkę „vibe coding rescue", a dostaniesz listę firm sprzedających dokładnie tę usługę: audyt aplikacji zbudowanej przez model, przegląd bezpieczeństwa, przepisanie krytycznych fragmentów. Nazywają to ratowaniem, co jest marketingiem, ale opisuje układ sił dosyć uczciwie.

Mechanizm jest znajomy każdemu, kto widział firmę bez procesów. Oszczędność na etapie, na którym jest tania, zamienia się w koszt na etapie, na którym jest droga — dokładnie tak samo, jak gaszenie pożarów wychodzi drożej niż spisanie procedury. Różnica polega tylko na tym, że tu rachunek przychodzi szybciej, bo cykl trwa kwartał, a nie pięć lat.

Raport DORA za 2025 rok, oparty na odpowiedziach blisko pięciu tysięcy specjalistów, opisuje to jednym zdaniem: AI działa jak wzmacniacz. Wzmacnia to, co organizacja już ma. Zespół z porządnym przeglądem kodu i testami dostaje realne przyspieszenie. Zespół bez nich dostaje ten sam bałagan, tylko wcześniej i w większej ilości.

Cztery rzeczy do zapisania w piątek, żeby wrzesień dało się odczytać

Nie chodzi o to, żeby przestać. Chodzi o to, żeby wieczór z modelem zostawiał po sobie coś więcej niż działający ekran.

Punkt trzeci jest najtańszy i wypada pierwszy. A przy przekazaniu to on decyduje, czy ktoś dostaje projekt, czy zagadkę.

Karpathy sam już tak tego nie nazywa

W kwietniu 2026 roku, na konferencji Sequoii, Karpathy ogłosił, że vibe coding jest już passé, i zaproponował w zamian „agentic engineering". Uzasadnienie podał wprost: „agentic", bo domyślnie nie piszesz kodu samodzielnie przez 99% czasu, tylko orkiestrujesz agentów i pełnisz rolę nadzoru — „engineering", żeby podkreślić, że jest to rzemiosło wymagające wiedzy.

Zwróć uwagę, co zostało dołożone do definicji po roku. Nadzór. Ta sama praktyka, ten sam poziom automatyzacji, tylko z powrotem wpisaną odpowiedzialnością za wynik.

Wieczór, w którym opisujesz aplikację zdaniami i dostajesz ją gotową, jest realnym postępem i nie ma powodu z niego rezygnować. Rzecz w tym, że dostajesz wtedy dwie rzeczy naraz: działający produkt i zobowiązanie. Pierwsze widać w poniedziałek. Drugie zgłasza się w trzecim miesiącu i przychodzi po kogoś — po Ciebie albo po kogoś, komu za to zapłacisz.

Jedyne pytanie warte zadania w piątek o dwudziestej drugiej brzmi więc: czy ja to jeszcze mogę wyrzucić?