5 anty-wzorców vibecodingu, które niszczą projekt

Vibecoding nie psuje projektu sam z siebie. Psują go nawyki, które przenosisz z czasów, gdy kod pisałeś wolno i ręcznie. Kiedy model generuje sto linii w trzy sekundy, każdy zły nawyk zaczyna kosztować dziesięć razy więcej, bo skaluje się razem z prędkością. Poniżej pięć anty-wzorców, które widać w każdym projekcie ratowanym po dwóch miesiącach „szybkiego dowożenia”. Dla każdego: dlaczego boli, po czym poznasz, że właśnie w to wpadłeś, i co z tym zrobić.

Anty-wzorzec 1: brak specyfikacji i mgliste prompty

Najczęstszy błąd. Wpisujesz „zrób mi panel admina” i naciskasz enter. Model zgaduje. Zgaduje tabele, zgaduje role, zgaduje, czy filtrowanie ma być po stronie serwera czy klienta. Część zgadnie dobrze, część fatalnie — a ty nie masz żadnej bazy, względem której możesz powiedzieć, że zgadł źle.

Dlaczego boli: bez specyfikacji nie istnieje pojęcie „poprawny wynik”. Wszystko, co model zwróci, jest tak samo akceptowalne, więc godzisz się na pierwszą wersję, która się kompiluje. Po tygodniu masz dziesięć ekranów, z których każdy interpretuje „użytkownika” inaczej.

Symptom: dużo rund „nie, nie tak, popraw”. Jeśli prowadzisz z agentem dialog na pięć–sześć obrotek, żeby dojść do tego, co miałeś w głowie od początku, to znaczy, że spec siedział w twojej głowie, a nie w prompcie.

Fix: zanim poprosisz o kod, napisz krótki opis — trzy do pięciu zdań wejścia, wyjścia i ograniczeń. Nie musi to być formalny dokument; wystarczy lista: co dostaje funkcja, co zwraca, co jest poza zakresem, jakie są warunki brzegowe. Dla większych zmian (powyżej kilku plików) zrób prawdziwy SPEC.md i poproś agenta, żeby najpierw streścił, jak zrozumiał zadanie — zanim napisze pierwszą linię.

Anty-wzorzec 2: akceptacja kodu bez czytania

Diff ma 200 linii, wygląda sensownie, testy zielone, więc klikasz „accept all”. To moment, w którym przestajesz być inżynierem, a stajesz się przenośnikiem taśmowym między modelem a repozytorium.

Dlaczego boli: modele generują kod, który wygląda jak działający. Subtelne rzeczy — odwrócony warunek, zgubiony przypadek pustej listy,catch, który połyka błąd — przechodzą wzrokowy test „wygląda OK”. Gorzej: model potrafi dorzucić zależność, której nie potrzebujesz, albo zduplikować logikę, która już istnieje trzy katalogi obok. Jeśli tego nie czytasz, dług narasta po cichu.

Symptom: nie potrafisz wyjaśnić, dlaczego dana funkcja działa. Gdy kolega pyta „czemu tu jest setTimeout na 250 ms?”, odpowiadasz „model tak dał”. To czerwona flaga — kod, którego nie rozumiesz, jest kodem, którego nie utrzymasz.

Fix: czytaj każdą linię, którą zatwierdzasz, tak jakbyś robił review koledze. Jeśli diff jest za duży na uważne czytanie, jest za duży na jeden commit — poproś o mniejsze kroki. Pytaj agenta „dlaczego tak, a nie inaczej” przy każdym fragmencie, który cię dziwi. Traktuj wygenerowany kod jak PR od bardzo szybkiego, ale bardzo pewnego siebie juniora.

Anty-wzorzec 3: pomijanie testów, bo „przecież działa”

Klikasz po aplikacji, wszystko śmiga, więc po co tracić czas na testy. Vibecoding wręcz kusi do tego: skoro kod powstaje tak szybko, testy wydają się hamulcem. To pułapka, która zamyka się dokładnie wtedy, gdy projekt zaczyna mieć wartość.

Dlaczego boli: „działa” to znaczy „zadziałało raz, na mojej maszynie, na ścieżce, którą akurat kliknąłem”. Bez testów każda kolejna zmiana generowana przez model jest hazardem — nie wiesz, czy nie zepsuła czegoś trzy moduły dalej. A przy vibecodingu zmian jest dużo i są szybkie, więc regres dogania cię błyskawicznie.

Symptom: boisz się wprowadzać zmiany. Każdy refactor to ruletka, bo jedyną weryfikacją jest ręczne klikanie. Wracają błędy, które „były już naprawione”. To klasyczny brak siatki bezpieczeństwa.

Fix: pisz testy na to, co naprawdę boli przy zepsuciu — logikę biznesową, walidację, obliczenia, ścieżki błędów. Nie goń za pokryciem 100%; goń za pokryciem ryzyka. Modele świetnie generują testy, więc wykorzystaj to: poproś o testyprzed implementacją albo razem z nią i sam sprawdź, czy testują zachowanie, a nie implementację. Jeden dobry test na krytyczną ścieżkę jest wart dziesięciu na getter.

Anty-wzorzec 4: context rot — wrzucanie całego repo do promptu

„Żeby model miał pełen kontekst”, wrzucasz mu pięćdziesiąt plików albo całe repozytorium. Intuicja mówi: im więcej kontekstu, tym lepiej. Intuicja jest tu błędna.

Dlaczego boli: uwaga modelu jest skończonym zasobem. Im więcej nieistotnych plików wrzucisz, tym bardziej rozmywa się sygnał. Model zaczyna mieszać konwencje z różnych modułów, sięga po wzorce z kodu, który akurat był w oknie, a nie z tego, który jest istotny. To zjawisko nazywa się context rot: jakość odpowiedzi spada wraz z ilością szumu, nawet jeśli okno formalnie się mieści.

Symptom: im dłuższa sesja, tym gorsze odpowiedzi. Model zaczyna „zapominać” ustalenia sprzed dziesięciu wiadomości, miesza nazwy, proponuje rozwiązania niespójne z resztą projektu. Wklejasz coraz więcej, a wyniki są coraz słabsze.

Fix: dawaj modelowi tylko to, co istotne dla zadania — dwa, trzy pliki plus krótki opis architektury, a nie cały graf zależności. Korzystaj z plików typu CLAUDE.md, w których spisujesz konwencje raz, zamiast wklejać je w każdym prompcie. Zaczynaj nową sesję dla nowego zadania — świeży, czysty kontekst bije długą, zaśmieconą konwersację. Mniej, ale celniej.

Anty-wzorzec 5: mega-prompty, które proszą o wszystko naraz

„Zbuduj mi auth z OAuth, panel użytkownika, system płatności, powiadomienia mailowe i dashboard analityczny” — w jednym prompcie. Model coś wyprodukuje, bo zawsze coś produkuje. Pytanie tylko, ile z tego nadaje się do użycia.

Dlaczego boli: im większy zakres jednej odpowiedzi, tym więcej decyzji model podejmuje bez ciebie i tym mniej każdej z nich poświęca uwagi. Dostajesz pięć pół-działających funkcji zamiast jednej dobrej. Debugowanie staje się koszmarem, bo gdy coś nie gra, nie wiesz, czy problem jest w płatnościach, w aucie, czy w sposobie, w jaki model połączył jedno z drugim. Wszystko jest naraz na pół gotowe.

Symptom: dostajesz wielką ścianę kodu, której nie umiesz ani zweryfikować, ani bezpiecznie scalić. Pierwsza reakcja to „OK, ale od czego ja to w ogóle zacznę sprawdzać”. Jeśli odpowiedź na jeden prompt nie mieści się w jednym sensownym review, prompt był za duży.

Fix: rozbij zadanie na najmniejsze sensowne kroki i dowoź je po kolei. Najpierw auth — przeczytaj, przetestuj, scal. Potem panel. Potem płatności. Każdy krok kończy się działającym, zweryfikowanym kawałkiem, na którym stoi następny. To wolniej wygląda, a jest szybciej, bo nie wracasz co chwilę do rozplątywania klębka. Małe prompty, małe diffy, małe ryzyko.

Dlaczego te pięć błędów chodzi w parze

Te anty-wzorce się wzmacniają. Brak speca (1) sprawia, że nie wiesz, czego szukać, czytając diff (2). Skoro i tak nie czytasz, to po co testy (3). Żeby model „sam się domyślił”, wrzucasz mu wszystko (4) i prosisz o wszystko naraz (5). Każdy z nich z osobna jest do przeżycia; razem tworzą projekt, który działa w demie i rozpada się na pierwszym prawdziwym użytkowniku.

Wspólny mianownik jest jeden: oddajesz modelowi decyzje, które powinny zostać u ciebie. Vibecoding to nie „model robi za mnie”, tylko „model pisze, ja decyduję”. Gdy ta granica się zaciera, prędkość zamienia się w dług.

TL;DR

Pięć anty-wzorców niszczących projekt: (1) brak speca i mgliste prompty — napisz krótki opis wejścia, wyjścia i ograniczeń, zanim poprosisz o kod; (2) akceptacja kodu bez czytania — czytaj każdą linię jak na review; (3) pomijanie testów, bo „działa” — testuj ryzyko, nie procenty; (4) context rot — dawaj tylko istotne pliki i zaczynaj świeże sesje; (5) mega-prompty — rozbijaj na małe, weryfikowalne kroki. Wspólny lek: zatrzymaj decyzje przy sobie, oddaj modelowi tylko pisanie.