Vibe coding

Nazwa funkcjonuje w dwóch znaczeniach naraz i polskie teksty zwykle ich nie rozdzielają. Andrej Karpathy, który ją wymyślił, opisał pracę bez czytania kodu przy projektach weekendowych, które można wyrzucić. Słownik Collins, który w listopadzie 2025 r. wybrał vibe coding słowem roku, definiuje go szeroko: każde pisanie kodu przez AI na podstawie poleceń w języku naturalnym.

Gdy ktoś mówi, że aplikacja powstała przez vibe coding, warto dopytać, czy ktokolwiek przejrzał i przetestował jej kod.

Nazwę wprowadził Andrej Karpathy, współzałożyciel OpenAI i były szef AI w Tesli, we wpisie z 2 lutego 2025 r. Opisał w nim, jak mówi do edytora, przyjmuje wszystkie zmiany bez czytania, a komunikaty o błędach wkleja z powrotem do modelu. Zaznaczył, że to sposób na projekty weekendowe. Dalej zmiany szły szybko:

• Marzec 2025. Simon Willison zawęża pojęcie: vibe coding to budowanie z modelem bez przeglądania kodu, który model napisał. Kod przejrzany, przetestowany i taki, który umiesz wyjaśnić, to według niego zwykłe wytwarzanie oprogramowania.
• Październik 2025. Willison proponuje osobną nazwę dla pracy doświadczonych inżynierów z AI, z pełną odpowiedzialnością za kod: vibe engineering.
• Listopad 2025. Collins ogłasza vibe coding słowem roku.
• Listopad 2025. Marty Cagan oddziela narzędzia do prototypowania od narzędzi do budowy produktów komercyjnych.
• Wrzesień 2026. Steve Blank pisze, że skoro produkt da się zbudować w ten sposób, działający produkt przestał być dowodem pracy z klientami.

Różnica leży w tym, kto odpowiada za kod. W vibe codingu w wąskim znaczeniu nikt go nie czyta. W programowaniu z pomocą AI człowiek przegląda każdą zmianę. Doświadczeni inżynierowie pracują dziś z agentami AI, ale planują, testują i odpowiadają za całość.

Popularne narzędzia to między innymi Lovable, Bolt, Replit, v0, Claude Code i Cursor. Marty Cagan dzieli je na dwie grupy: narzędzia do szybkiego prototypowania, jak Lovable, Bolt czy Figma Make, i narzędzia, w których zespoły budują produkty komercyjne, jak Claude Code i Cursor. Ten podział opisuje typowe użycie, a nie granicę: tym samym narzędziem da się pracować na oba sposoby.

Narzędzia z pierwszej grupy prowadzą od opisu do działającej strony w przeglądarce, razem z bazą danych i logowaniem. Narzędzia z drugiej działają w edytorze kodu albo w terminalu i zakładają, że ktoś rozumie, co się w projekcie dzieje.

Bywa różnie i trzeba to sprawdzić, zanim aplikacja trafi do prawdziwych użytkowników. Marty Cagan ujmuje to krótko: budowanie, żeby się czegoś dowiedzieć, to co innego niż budowanie, żeby zarabiać. Prototyp z prawdziwymi danymi wygląda jak gotowy produkt, a produkt komercyjny potrzebuje jeszcze niezawodności, bezpieczeństwa danych, integracji, zgodności z przepisami i planu na awarię.

Przed zaproszeniem pierwszych użytkowników warto przejść przez pięć obszarów:

1. Bezpieczeństwo i dane: logowanie, dostępy, RODO.
2. Koszty działania przy rosnącej liczbie użytkowników.
3. Utrzymanie i rozwój kodu, gdy trzeba coś zmienić za pół roku.
4. Użyteczność i to, czy produkt naprawdę daje użytkownikom wartość.
5. Odróżnialność: prototypy z tych samych narzędzi mają podobne układy, kolory i komponenty.

Simon Willison radzi, żeby przed udostępnieniem aplikacji innym ludziom pokazać ją komuś bardziej doświadczonemu. Producent Lovable pisze w dokumentacji, że wbudowane skany bezpieczeństwa nie zastępują pełnego przeglądu, a za spełnienie wymagań odpowiada użytkownik.

Badania z lat 2025–2026 pokazują, że większość sprawdzonych aplikacji zbudowanych z AI ma co najmniej jedną lukę bezpieczeństwa. Jeden z najpoważniejszych problemów to baza danych, którą da się odczytać bez logowania. Liczby pochodzą z preprintów i od firm, które sprzedają narzędzia do skanowania, więc obok każdej stoi jej ograniczenie.

Działający prototyp da się zbudować z AI i pokazać klientom zamiast szkicu na kartce. To skraca drogę od pomysłu do pierwszej reakcji rynku. Steve Blank zwraca uwagę na drugą stronę: skoro produkt może powstać bez rozmów z klientami, sam produkt nie dowodzi już, że ktoś zrozumiał problem. Nazywa takie produkty początkowymi, nieprzetestowanymi.

W praktyce prototyp z vibe codingu dobrze sprawdza się jako proof of concept: narzędzie do sprawdzenia rozwiązania, gdy problem jest już zbadany. Gdy problem jest jeszcze nieznany, szybsze budowanie go nie zastąpi, a pomaga product discovery.