Zmęczenie Vibecodingiem

1. Przegląd koncepcji i problem systemowy

Termin „vibecoding” narodził się jako symbol absolutnej wolności: programista w pół rozluźniony rzuca pomysły do czatu, model generuje pełnoprawne usługi webowe, a człowiek jedynie delektuje się „wajbem” tworzenia.

Jednak za każdą godzinę beztroskiego upojenia kodogeneracją przychodzi zapłacić ciężki kac. Vibecoding Fatigue (Zmęczenie vibecodingiem) to forma wyczerpania poznawczego, gdy inżynier zostaje zamknięty w pokoju z potworem, którego sam stworzył:

• W repozytorium znajduje się tysiące linii kodu, który działa, ale nikt nie wie, dlaczego dokładnie działa.
• Każda zmiana interfejsu lub schematy bazy danych łamie 5 niezwiązanych ze sobą modułów.
• Inżynier czuje się nie twórcą ani architektem, lecz bezradnym operatorem, który panikująco klika „Regenerate”, licząc na cud.

Zamiast kreatywnej swobody, developer otrzymuje chroniczny lęk przed każdym deployem oraz głębokie poczucie alienacji od własnego zawodu.

Pułapka dopaminowa w vibe codingu:
Godzina 0-2: [Euforia! „Stworzyłem SaaS-a w 120 minut!”]
                     |
                     v
Godzina 3-5: [Pierwszy błąd ulotny (flaky bug): tokeny sesji wypadają w Safari]
                     |
                     v
Godzina 6-8: [Piekielne prompty: 40 prób zmuszenia modelu do naprawy sesji]
                     |
                     v
Godzina 9+:  [Paraliż debugowania: system jest zepsuty, kod nieczytelny, całkowite wypalenie]

2. Taksonomia architektoniczna i model mentalny

Psychologiczne i inżynieryjne fazy syndromu vibecodingu:

1. Faza dopaminowego hajpu (The High):
   • Ekstremalnie wysoka szybkość wizualnych zmian. Developer czuje się „wszechmocnym inżynierem 100x”, ignorując brak testów, migracji i typów.
2. Faza rozpadu modelu mentalnego (The Mental Model Decoupling):
   • Baza kodu przerasta pojemność pamięci krótkotrwałej. Pojawiają się halucynowane biblioteki i duplikowane helpery.
3. Faza impasu architektonicznego (The Wall):
   • Asystent zaczyna nadpisywać stare funkcje podczas próby dodania nowych. Kontekst jest przepełniony, developer odczuwa złość i bezsilność.
4. Faza toksycznej alienacji (Alienation):
   • Utrata chęci do otwierania projektu, poczucie syndromu oszusta: „Nie jestem prawdziwym programistą, jestem tylko kopiuj-wklejaczem promptów”.

3. Techniczny pipeline i wewnętrzna mechanika

Porównanie: Zdrowy agentic engineering vs Vibecoding

Protokół detoksykacji z vibecodingu: „Stop, Freeze, Re-architect”

[Objaw: Agent 3 razy z rzędu nie potrafi naprawić kodu]
   |
   v
1. STOP: Wymuś zamknięcie okna czatu modelu.
   |
   v
2. FREEZE: git diff > pending_changes.patch. Przywróć drzewo robocze do ostatniego stabilnego commita.
   |
   v
3. ISOLATE: Wyizoluj problem w minimalnym teście (Minimal Reproducible Example) składającym się z 10 linii kodu.
   |
   v
4. RE-ARCHITECT: Napisz rozwiązanie ręcznie lub przekaż wąską, atomową instrukcję zawierającą kontekst tylko jednego pliku.

4. Praktyczne scenariusze inżynieryjne w produkcji

01. Ratowanie startupu po „vibecodingowym hackathonie”

Zespół deweloperski wygenerował MVP serwisu fintechowego w ciągu weekendu. Przed releasem okazało się, że przy jednoczesnych zapytaniach salda użytkowników były obciążane dwukrotnie z powodu braku blokad transakcyjnych. Próby „promptowania” rozwiązania tylko zagmatwały kod. Team Lead zatrzymał prace na 3 dni, usunął 60% nadmiarowego kodu, ręcznie napisał moduł sald na ścisłych transakcjach PostgreSQL i dopiero wtedy przywrócił projekt do stabilnego stanu.

02. Wyjście z zaklętego koła nieskończonych regeneracji stylów CSS

Developer przez 2 godziny próbował promptami wyrównać okno modalne w Tailwind, ale model psuł animację zamknięcia. Poczawszy ostre zmęczenie, inżynier otworzył Chrome DevTools, w 40 sekund znalazł konfliktującą klasę overflow-hidden na kontenerze rodzica i rozwiązał problem jednym precyzyjnym kliknięciem, odzyskując spokój ducha.

03. Wprowadzenie barier zespołowych przeciw rozrostowi „czarnych skrzynek”

Engineering Director wprowadził zasadę: każdy PR utworzony z pomocą AI musi być obroniony przez autora podczas 5-minutowej sesji pytań od kolegów: „Dlaczego wybrano tę konkretną strukturę danych? Jak obsługiwany jest timeout sieciowy?”. To natychmiast zmusiło inżynierów do uważnego czytania każdej linii wygenerowanego kodu przed wysłaniem go na review.

5. Pułapki, typowe błędy i bezpieczeństwo

1. Syndrom „One More Prompt”: Iluzja, że kolejna próba lub przełączenie na inny model (Claude 3.7 -> GPT-4o -> DeepSeek-R1) magicznie rozwiąże fundamentalny błąd architektoniczny w projekcie bazy danych. Jeśli architektura jest błędna od początku, żaden model na świecie nie sprawi, że będzie działać niezawodnie.
2. Całkowita utrata kontaktu z własną tożsamością inżynierską: Długotrwałe pozostawanie w vibecodingu bez ręcznego kodowania prowadzi do tego, że inżynier zaczyna bać się pustego ekranu i traci pewność siebie co do swoich umiejętności. Regularnie pisz kod ręcznie, aby utrzymać formę.
3. Ignorowanie invariantów bezpieczeństwa dla „wajbu”: W pędzie szybkiej generacji feature’ów deweloperzy często machają ręką na walidację CORS, ochronę przed CSRF, sanitizację danych wejściowych i bezpieczeństwo ciasteczek sesyjnych. „Przecież działa lokalnie!” w produkcji zamienia się w wyciek danych osobowych użytkowników już w pierwszym tygodniu.