Vibe coding a inżynieria: gdzie stawiam granicę

Andrej Karpathy ukuł termin „vibe coding” w lutym 2025 roku, opisując styl programowania, w którym programista „całkowicie poddaje się wibracjom, akceptuje wykładniczy wzrost i zapomina, że kod w ogóle istnieje”.¹

Przeczytałem to i pomyślałem: to połowa mojego przepływu pracy. Druga połowa jest dokładnym przeciwieństwem.

TL;DR

Codziennie tworzę z Claude Code. Część tej pracy to czysty vibe coding: opisuję, czego chcę, akceptuję wynik i idę dalej. Część przechodzi przez 86 hooków, strażnika bezpieczeństwa Git, zabezpieczenie przed rekurencją i system bramek jakości, który blokuje commity zawierające typowe cechy tekstu AI lub stronę bierną. Granica między tymi dwoma podejściami nie jest przypadkowa. Prototypy dostają wibracje. Produkcja dostaje inżynierię. Najtrudniejsze jest rozpoznanie momentu, w którym prototyp przekracza tę granicę.

Mój rzeczywisty przepływ pracy

Strona wibracji

Kiedy eksploruję pomysł, stosuję vibe coding bez skrupułów. Moja aplikacja na iOS Ace Citizenship zaczęła się jako weekendowy eksperyment: „Zbuduj quiz z powtórkami rozłożonymi w czasie do pytań obywatelskich USCIS”. Claude Code wygenerował początkowe widoki SwiftUI, bazę pytań i algorytm planowania powtórek. Nie czytałem każdej linii. Uruchomiłem, przetestowałem ręcznie i iterowałem, opisując, co wydawało się nieprawidłowe.

Interaktywne komponenty na tym blogu (drzewo decyzyjne RAG, kalkulator procentu składanego) powstały w ten sam sposób. „Zbuduj drzewo decyzyjne, które przeprowadza użytkowników przez wybór między RAG a fine-tuningiem z animowanymi przejściami”. Akceptuję, testuję, dostosowuję. Zasięg rażenia błędu w widżecie blogowym ogranicza się do jednej strony.

Strona inżynierii

Moja architektura hooków Claude Code jest przeciwieństwem vibe codingu. Każdy hook istnieje, ponieważ coś poszło nie tak.

git-safety-guardian.sh istnieje, ponieważ Claude wykonał force push na main podczas jednej z wczesnych sesji. Hook teraz przechwytuje każde polecenie Git, dopasowuje wzorce do tabeli poziomów zagrożeń (CRITICAL: force push na main; HIGH: dodawanie plików .env; MEDIUM: –no-verify) i wstrzykuje ostrzeżenie przed wykonaniem.

recursion-guard.sh istnieje, ponieważ subagent spawnował nieskończoną liczbę procesów potomnych. Hook śledzi rodowód agentów w pliku JSON, wymusza limity głębokości i zarządza modelem budżetu spawnowania, który zapobiega niekontrolowanym łańcuchom agentów, jednocześnie umożliwiając uprawnioną pracę równoległą.

blog-quality-gate.sh istnieje, ponieważ proza generowana przez AI brzmi jak proza generowana przez AI. Hook blokuje commity do content/blog/, jeśli wykryje pauzy, stronę bierną lub słowa takie jak „delve”, „crucial” czy „landscape”.

Żaden z tych hooków nie powstał w trybie vibe coding. Każdy został napisany linia po linii, przetestowany na rzeczywistych scenariuszach awarii i zrecenzowany przed wdrożeniem. 86 hooków łącznie reprezentuje granicę między wibracjami a inżynierią.

Gdzie faktycznie przebiega granica

Wibracje: jednorazowe prototypy

Stosuję vibe coding do wszystkiego, co mogę wyrzucić. Skrypt transformacji danych, który uruchomię raz. Narzędzie CLI do użytku osobistego. Proof-of-concept sprawdzający, czy API działa zgodnie z dokumentacją. Koszt błędu w jednorazowym kodzie to mój własny czas, a zysk z szybkości przeważa nad ryzykiem debugowania.

Wibracje: eksploracja kreatywna

Kiedy eksploruję kierunek projektowy, vibe coding pozwala mi testować wzorce interakcji szybciej niż Figma. „Zbuduj modal wyszukiwania z nawigacją klawiaturową, podświetlaniem wyników i aktywacją Cmd+K” daje działający prototyp w kilka minut. Oceniam wrażenie z użytkowania, nie kod.²

Inżynieria: wszystko, co trafia do użytkowników

W momencie, gdy kod służy komuś innemu niż ja, przekracza granicę. Mój blog przechodzi przez 12-modułowy linter, który sprawdza cytaty, hierarchię nagłówków, poziom czytelności, tekst alternatywny obrazów, gęstość linków wewnętrznych i głębokość treści. Linter ma 77 testów. Blog ma 29 postów. Linter ma więcej testów niż blog ma treści.

Inżynieria: wszystko, co jest trwałe

Schematy baz danych, kontrakty API, konfiguracje hooków i manifesty wdrożeniowe otrzymują pełne traktowanie inżynieryjne. Te decyzje się kumulują. Schemat zaprojektowany w sesji vibe coding staje się koszmarem migracji, gdy na jego szczycie nagromadzą się trzy lata danych.³

Inżynieria: wszystko związane z bezpieczeństwem

Kod generowany przez AI odzwierciedla stan bezpieczeństwa danych treningowych, które obejmują tutoriale i odpowiedzi ze Stack Overflow rutynowo pomijające uwierzytelnianie, walidację danych wejściowych i obsługę błędów dla zwięzłości.⁴ Moje hooki wychwytują część z tego (strażnik bezpieczeństwa Git flaguje dodawanie plików .env, plików z poświadczeniami i force push), ale kod krytyczny pod względem bezpieczeństwa przechodzi ręczny przegląd niezależnie od wszystkiego.

Problem luki w zrozumieniu

Najniebezpieczniejszym wzorcem w vibe codingu nie jest zły kod. To kod, który działa, dopóki nie przestanie.

Wygenerowałem warstwę buforowania dla mojego systemu tłumaczeń i18n. Działała perfekcyjnie dla treści w języku angielskim. Kiedy dodałem koreański i tradycyjny chiński, generowanie kluczy cache cicho produkowało kolizje dla określonych punktów kodowych Unicode. Debugowanie zajęło cztery godziny, ponieważ nigdy nie przeczytałem funkcji generowania klucza cache. Kod był poprawny dla ASCII — i to właśnie podkreślały dane treningowe.⁵

Wniosek: systemy stworzone w trybie vibe coding zawodzą na krawędziach, które dane treningowe niedostatecznie reprezentują. Jeśli użytkownicy operują na tych krawędziach (pisma nie-łacińskie, wysoka współbieżność, nietypowe warunki sieciowe), implementacje vibe coding niosą ukryte ryzyko.

Bramka przeglądu

Każdy fragment kodu przeznaczonego na produkcję w moim systemie przechodzi przez bramkę przeglądu — niezależnie od tego, czy napisałem go ja, czy Claude Code:

1. Przeczytaj każdą linię. Wygenerowany kod to pull request od niezaufanego kontrybutora. Recenzuj odpowiednio.
2. Zweryfikuj obsługę błędów. Sprawdź, czy ścieżki błędów odzwierciedlają wymagania domenowe, a nie generyczne wzorce try-catch.
3. Audytuj zależności. AI rozwiązuje każdy prompt w izolacji, importując dowolną bibliotekę, która rozwiązuje bieżące zadanie. Po 50 promptach możesz mieć trzy biblioteki dat i dwóch klientów HTTP.
4. Dodaj testy. Wygenerowany kod rzadko pokrywa przypadki brzegowe specyficzne dla danej domeny.
5. Sprawdź bezpieczeństwo. Uruchom analizę statyczną. Zweryfikuj uwierzytelnianie, autoryzację i walidację danych wejściowych.⁶

Bramka przeglądu nie jest opcjonalna. To różnica między używaniem AI jako mnożnika siły a używaniem AI jako kuli.

Podział w branży

Inżynieria oprogramowania dzieli się na dwa poziomy. Pierwszy wykorzystuje AI jako mnożnik siły: generowanie szablonowego kodu, eksplorację przestrzeni rozwiązań i przyspieszanie implementacji dobrze zrozumianych wzorców przy zachowaniu zrozumienia i standardów jakości. Drugi generuje całe aplikacje bez rozumienia wyników, wymieniając krótkoterminową prędkość na długoterminową kruchość.⁷

Ten podział odzwierciedla wczesny rozwój stron internetowych. Kreatory szablonów jak Squarespace zdemokratyzowały publikowanie w sieci i stworzyły miliony funkcjonalnych stron. Profesjonalny rozwój webowy przetrwał, ponieważ systemy produkcyjne wymagają jakości, bezpieczeństwa i możliwości utrzymania, których szablony nie są w stanie zapewnić.

Świadomie operuję na obu poziomach. Mój system hooków i bramki jakości istnieją po to, by wychwycić moment, w którym praca drugiego poziomu musi awansować do standardów pierwszego poziomu. 86 hooków to nie biurokracja. To system immunologiczny, który pozwala mi swobodnie stosować vibe coding, jednocześnie uniemożliwiając kodowi z sesji vibe coding dotarcie na produkcję bez przeglądu.

Kluczowe wnioski

Dla inżynierów korzystających z AI na co dzień: - Wyznacz wyraźną granicę między eksploracją a produkcją; swobodnie stosuj vibe coding do jednorazowej pracy, ale egzekwuj bramki przeglądu, zanim cokolwiek trafi do użytkowników lub zostanie utrwalone - Buduj automatyczne zabezpieczenia (hooki, lintery, bramki jakości) zamiast polegać wyłącznie na dyscyplinie; dyscyplina zawodzi o 2 w nocy, hooki nie

Dla menedżerów inżynierii: - Ustal jasne granice między kodem o jakości prototypowej a kodem o jakości produkcyjnej; prototypy vibe coding, które prześlizgną się na produkcję, tworzą nową kategorię długu technicznego - Oceniaj produktywność na podstawie wyników (dostarczone funkcje, błędy na funkcję, satysfakcja użytkowników), a nie wskaźników prędkości; vibe coding zawyża liczbę linii kodu bez proporcjonalnej poprawy wyników

Bibliografia