Czym naprawdę jest vibe coding?

Termin "vibe coding" rozprzestrzenił się szybko w 2024-2025, ponieważ określa coś, co wiele osób programujących już robiło potajemnie: opisywanie tego, czego chce, zwykłym angielskim modelowi takiemu jak GPT-4, Claude, lub narzędziom takim jak Cursor czy GitHub Copilot, i pozwalanie mu na wygenerowanie większości rzeczywistego kodu. Programista pozostaje w pętli, ale pętla wygląda inaczej niż przy tradycyjnym kodowaniu.

Faktyczna definicja

Andrej Karpathy ukuł to sformułowanie, opisując przepływ pracy, w którym "w pełni poddajesz się vibom" — promptujesz, akceptujesz sugestie, uruchamiasz kod, widzisz co się psuje, i promptujesz ponownie. Nie czytasz każdej linii diffa. Sterujesz wynikami: czy aplikacja robi to, czego trzeba, czy test przechodzi, czy strona renderuje się poprawnie. Umiejętność przesunęła się od pisania składni do jasnego opisania intencji i rozpoznawania, gdy wynik jest błędny.

To różni się od zwykłego używania autouzupełniania. Wbudowane sugestie w stylu Copilota nadal zakładają, że sam piszesz funkcję z pewną pomocą w uzupełnieniu linii. Vibe coding zakłada, że model pisze funkcję, plik, czasami całą funkcjonalność, a ty dokonujesz przeglądu i przekierowywania zamiast pisania od zera.

Jak wygląda rzeczywista sesja

Typowa pętla vibe codingu z narzędziem takim jak Cursor lub tryb Agent w Repli wyglądałaby mniej więcej tak:

1. Prompt: "Add a rate limiter to this Express API, 100 requests per 15 minutes per IP, return 429 with a JSON error body."
2. Model edytuje middleware/rateLimit.js, łączy go w app.js, być może pobiera express-rate-limit.
3. Uruchamiasz npm test lub trafisz na endpoint za pomocą curl w pętli, aby sprawdzić, czy 429 naprawdę się pojawia.
4. Coś nie gra — limiter resetuje się przy każdym wdrożeniu, ponieważ jest w pamięci. Mówisz o tym.
5. Model zamienia na magazyn wspierany przez Redis, dodaje zależność ioredis, aktualizuje plik docker-compose.
6. Ponownie testujesz, działa, commitujesz.

Żadna linia tego middleware'u nie została wpisana ręcznie. Ale sześć lub siedem decyzji osądu dokonanych zostało przez człowieka: jaki powinien być limit, że przechowywanie w pamięci było złe dla produkcji, że plik docker-compose również wymagał aktualizacji.

Gdzie działa dobrze

Vibe coding sprawdza się dobrze przy pracy obciążonej boilerplate'em: endpointy CRUD, walidacja formularzy, budowanie testów, pliki konfiguracyjne, kod łączący dwa API, które już rozumiesz. Jest też dobry do prototypowania — stworzenie działającego demo pomysłu w ciągu godziny zamiast dnia, a następnie zdecydowanie, czy warte jest poważniejsze zbudowanie.

Jest naprawdę szybki dla solo deweloperów i małych zespołów wypuszczających wewnętrzne narzędzia lub MVP'y, gdzie koszt błędu jest niski, a szybkość iteracji liczy się bardziej niż czystość architektoniczna.

Gdzie zawodzi

Tryb awarii, o którym ludzie nie rozmawiają wystarczająco dużo: modele produkują kod, który działa, ale jest subtelnie błędny w sposób, który nie pojawia się aż później. Wygenerowana kwerenda SQL może działać dla happy path'a, ale być podatna na injection, ponieważ konkatenacja ciągów wyglądała dobrze dla modelu. Wygenerowana kontrola autoryzacji może przejść testy, ale pominąć sprawdzenie roli na jednej trasie. Jeśli nie czytasz kodu, tego nie zauważysz — zobaczysz po prostu, że testy przechodzą i wypuścisz to.

To ma większe znaczenie w kodzie wrażliwym na bezpieczeństwo niż prawie gdziekolwiek indziej. Simon Willison i inni zwrócili uwagę, że projekty vibe-coded z rzeczywistymi danymi użytkownika wymagają takiego samego rygor przeglądu jak każdy inny kod, argumentując, że bardziej, ponieważ osoba, która go "napisała", może nie być w stanie wyjaśnić, co robi linia po linii.

Skomplikowane systemy z dużą ilością niejawnego stanu — współbieżność, rozproszone transakcje, cokolwiek z subtelnym timing bugsami — też są złym dopasowaniem. Modele zwykle generują kod wyglądający wiarygodnie w takich przypadkach, który zawodzi w sposób trudny do debugowania dokładnie dlatego, że nikt, człowiek czy model, w pełni nie modelował przypadków brzegowych od początku.

Umiejętność, która naprawdę się teraz liczy

Jeśli vibe codujesz, cenna umiejętność to nie szybkość pisania, to specyfikacja. Niejasne prompty dają niejasny, błędy kod. Specyficzne prompty — z dokładnymi nazwami bibliotek, oczekiwaniami obsługi błędów i wyróżnionymi przypadkami brzegowymi — dają znacznie lepsze wyniki. Drugą co do ważności umiejętnością jest szybkie czytanie kodu, aby złapać co się psuje, co oznacza, że musisz nadal rozumieć język i domenę, nawet jeśli nie piszesz każdego znaku.

Traktuj kod generowany przez AI tak, jak traktowałbyś pull request od juniora, który jest szybki, ale czasami zbyt pewny siebie: przydatny, często poprawny, ale warte rzeczywistego przeglądu zanim dotknie produkcji.

Chcesz głębiej poznać pisanie kodu za pomocą narzędzi AI bez utraty kontroli nad jakością? Sprawdź segmenty AI i Python w Korra Studio, aby uzyskać praktyczne przewodniki.