“Vibe coding” to termin, który Andrej Karpathy ukuł na początku 2025. Definicja: piszesz aplikacje, gadając z AI po angielsku, nie kodując ręcznie. Mówisz “zrób X”, AI robi. Nie czytasz kodu, nie debugujesz, nie wiesz, co się dzieje pod spodem.

Brzmi jak science fiction. Karpathy i część Twittera mówią, że to przyszłość programowania.

Postanowiłem to sprawdzić. Spędziłem 4 weekendy próbując zbudować realną aplikację (SaaS do zarządzania klientami dla małych agencji) w vibe coding mode. Bez ręcznego kodu. Tylko Claude Code i konwersacja.

Ten post to mój uczciwy raport. Co zadziałało, co nie zadziałało, czego się nauczyłem o stanie AI tooling w 2026.

Setup eksperymentu

Cel: aplikacja SaaS, której bym sam użył w agencji. CRUD klientów, projektów, faktur, dashboardów. Coś, co mogłem zbudować ręcznie w 40-60 godzin.

Reguły:

  • Tylko Claude Code (terminal-based agent)
  • Tylko polecenia po polsku/angielsku
  • Zero ręcznego edytowania kodu
  • Mogę czytać kod (po fakcie), ale nie poprawiać
  • Mogę odrzucać sugestie i prosić o alternatywy
  • Mierzę czas, koszty, jakość wyniku

Stack, który Claude wybrał na początku:

  • Next.js 15 z App Router
  • TypeScript
  • Tailwind CSS plus shadcn/ui
  • Drizzle ORM plus PostgreSQL (Neon)
  • NextAuth dla auth
  • Vercel dla deployment

Ten stack jest podobny do mojego standardowego, opisanego w Next.js 2026 i PostgreSQL vs MongoDB. Plus dorzuca Drizzle (lżejszy niż Prisma) i NextAuth (standard dla auth).

Co zadziałało zaskakująco dobrze

Setup projektu: 15 minut. “Postaw fresh Next.js project z TypeScript, Tailwind, shadcn/ui, Drizzle z PostgreSQL, NextAuth, deploy do Vercel”. Claude zbudował, deploy działał, pierwszy commit po 20 minutach.

Basic CRUD klientów: 45 minut. “Zrób strony do listowania, dodawania, edycji, usuwania klientów”. Forms, walidacja, server actions, optimistic updates. Wszystko działało.

UI: konsystentny design. Claude trzymał się shadcn/ui konsekwentnie. Wszystkie buttons, dialogs, tabs wyglądały spójnie. Lepiej, niż gdybym pisał sam (zwykle mieszałem komponenty).

Database schema z migrations: Claude zaprojektował schemę, wygenerował migracje, ran je. Bez mojej interwencji.

Auth flow: Email plus magic link przez NextAuth. Skonfigurowane w 30 minut. Działa.

Responsive design: Claude pamiętał o mobile breakpointach. Strona wygląda dobrze na laptopie i telefonie.

Pierwsze 4-5 godzin pracy: euforia. Aplikacja rośnie, działa, wygląda profesjonalnie. Myślę: “Karpathy ma rację, to jest przyszłość”.

Gdzie zaczęło boleć

Po 6-8 godzinach rozwoju aplikacja miała 5 głównych modułów (clients, projects, invoices, dashboard, settings). Tu zaczęły się problemy.

Problem 1: AI traci kontekst. Po 30 plikach kodu Claude zaczyna proponować zmiany niezgodne z istniejącą strukturą. “Dorzucisz nową kolumnę do tabeli projects” => generuje migration ignorując 3 inne tabele, które odnoszą się do projects. Łapię błąd, prosi o refactor, ale rozwiązanie nieładne.

Problem 2: edge cases. “Co się dzieje, jak klient ma 200 faktur i scrolluje listę”. Claude proponuje paginację. Zgadzam się. Generuje. Ale pomija “co jak user filtruje plus paginuje plus sortuje”. Bug w pagination, który widzę dopiero, jak coś się pomyli.

Problem 3: brak code review. Czytam kod po fakcie. Jest “OK”, ale nie jest “świetny”. Patterny inconsistent, niektóre rzeczy over-engineered, niektóre under-engineered. Bez ręcznej interwencji nie da się tego naprawić.

Problem 4: błędy w business logic. Claude napisał logic do liczenia VAT na fakturze. Wzór wyglądał prawidłowo. Po wdrożeniu okazało się, że dla faktur w EUR brakuje konwersji walutowej. Bug, który programista by zauważył. Vibe coder nie.

Problem 5: debug w trybie czarnej skrzynki. Coś nie działa. Pytam Claude’a. Proponuje fix. Nie naprawia. Pytam dalej. Po 30 minutach “debugging” przez konwersację, jak nie znam kodu, nie mogę pomóc. Frustracja rośnie.

Problem 6: koszty. Po 4 weekendach (~25 godzin) zużyłem ~80 USD w API calls (Claude Max plan plus dodatkowe API). Tyle samo, ile zapłaciłbym za 8 godzin pracy juniora, który zrobił by mniej, ale lepiej zrozumiałe.

Wynik końcowy

Aplikacja działa. Wygląda dobrze. Pokrywa 80% zamierzonej funkcjonalności.

Ale:

  • Nie używam jej w produkcji. Bo nie ufam jakości kodu. Bo nie wiem, gdzie są nieujawnione bugi.
  • Refactor byłby trudny. Kod nie jest spójny, debugging wymaga zrozumienia 3000 linii.
  • Bezpieczeństwo wątpliwe. Czy SQL injections są pokryte? Czy IDOR ataki? Nie wiem.
  • Performance nieoptymalny. N+1 queries widoczne w niektórych endpointach.
  • Tests pomijane. Claude napisał kilka testów, ale ich kontrola jakości pomijana.

Wniosek: zbudowałem MVP w 25h, ale nie produkcyjną apkę.

Co to znaczy

Vibe coding działa dla:

Prototypów i MVP. Coś do pokazania klientowi, demo, hackathon. 1-3 dni pracy, akceptowalne, że nie jest production-ready.

Eksploracji pomysłów. Sprawdzam, czy idea ma sens, zanim zbuduję porządnie. Throwaway code.

Skryptów ad-hoc. Jednorazowy import danych, automatyzacja, scraper. Działa raz, koniec.

Wewnętrznych narzędzi dla siebie. Aplikacja, którą tylko Ty używasz. Małe ryzyko, akceptowalna jakość.

Vibe coding NIE działa dla:

Produkcyjnych aplikacji z realnymi użytkownikami. Tu ktoś musi rozumieć kod, naprawiać bugi, dodawać funkcjonalność.

Aplikacji obsługujących dane wrażliwe. Bezpieczeństwo wymaga programisty, który rozumie, co robi.

Skomplikowanych business logic. Gdy logika ma 5 warunków zazębionych, AI często myli się, programista zauważy.

Long-term ownership. Aplikacja, którą będziesz utrzymywać 3 lata. Bez zrozumienia kodu, debug po roku będzie piekielny.

Wymóg dla vibe coderów: znać programowanie

To paradoks, ale logiczny.

Programista z 5-letnim doświadczeniem może vibe code’ować skuteczniej niż samouk. Bo:

  • Wie, kiedy Claude robi błąd architektoniczny
  • Czyta kod szybciej, łapie problemy
  • Wie, jakie pytania zadać do debug
  • Wie, kiedy AI proponuje something off-base

Junior bez doświadczenia, próbujący vibe code, dostaje aplikację, która “wygląda” jak działa. Ale nie wie, czy:

  • Auth jest bezpieczne
  • Database queries są efektywne
  • Kod jest skalowalny
  • Bugi się czają

W mojej praktyce vibe coding to akcelerator dla seniora, nie sposób dla juniora, żeby pominął naukę.

Pisałem o tym w poście o AI a programiści. Junior plus AI to nadal junior, bo AI nie zastępuje fundamentów.

Hybrid approach: co realnie robię w pracy

Po eksperymencie wróciłem do mojego hybrid approach.

Co robię z AI (vibe-style):

  • Boilerplate i CRUD: 80% przez konwersację z AI
  • Tests: dopisuje AI, ja przeglądam
  • Migrations: AI generuje, ja oceniam
  • Dokumentacja: AI pisze pierwszą wersję
  • Refactor mechaniczny (rename, extract): AI

Co robię sam (full ownership):

  • Architektura
  • Business logic
  • Security-sensitive code (auth, payments)
  • Performance optymalizacje
  • Code review wszystkiego (mojego i AI)

Ten balans daje mi ~40% szybsze tempo niż 100% manual coding. Bez kompromisu na jakości.

Praktyczne wskazówki, jak nie zostać Vibe Coder porażką

Jeśli chcesz eksperymentować z vibe codingiem:

1. Zacznij od czegoś, co możesz wyrzucić. Twój pierwszy SaaS to nie miejsce na eksperymenty.

2. Czytaj kod, choć go nie piszesz. Minimum: rozumiesz, co Claude napisał. Maksimum: zauważasz problemy.

3. Walidacja przez testy. Pisz testy E2E (Playwright), które sprawdzają realny flow. Bez testów nie wiesz, czy aplikacja działa.

4. Limit projektu. Jeśli vibe coding przekroczył 1000 linii kodu, czas zatrzymać się i ocenić.

5. Code review przez programistę. Po sesji vibe codingu pokaż kod komuś z doświadczeniem. Zwykle złapie 5-10 problemów.

6. Nie skaluj vibe code na produkcję bez refactoringu. Vibe code to MVP. Production code wymaga refactoringu, dodania testów, security audit.

Co przyniesie 2027

Spekulacja, oparta na trendach:

AI będzie pisać lepszy kod. Modele będą lepiej rozumieć kontekst projektu, edge cases, security best practices.

Tooling będzie bardziej dojrzały. Cursor i Claude Code już są dobre, będą lepsze.

Vibe coding stanie się mainstream dla MVP. Małe firmy będą zaczynać produkty w vibe coding mode.

Production code nadal będzie wymagać programistów. Bo długoterminowe utrzymanie, security, performance to nadal ludzkie domeny.

Junior pozycje będą wymierać szybciej. Bo senior plus AI plus vibe coding dla prototypów = mała potrzeba juniorów.

Pisałem o tym w przyszłości zawodu. To jest część tej samej trajektorii.

Co czytać dalej

  • Andrej Karpathy na Twitterze / X i YouTube. On był pierwszym, który nazwał “vibe coding”.
  • Simon Willison’s blog (simonwillison.net). Najlepszy w branży obserwator AI tooling.
  • Anthropic blog. Regularne posty o Claude i jego capabilities.

Nie czytaj clickbaitów “AI zastąpi wszystkich”. Też nie czytaj “AI nigdy nie zastąpi człowieka”. Prawda jest pomiędzy, niuansowana.

Od czego zacząć, jeśli chcesz spróbować

  1. Zainstaluj Claude Code (CLI). Free tier wystarczy do eksperymentu.
  2. Wybierz mały projekt, który możesz wyrzucić. Nie nowy SaaS, raczej “scraper artykułów” albo “personal todo app”.
  3. Spędź 4-8 godzin w pełnym vibe coding mode. Daj sobie szansę poczuć.
  4. Czytaj wynikowy kod. Notuj, co Claude zrobił dobrze, co źle.
  5. Wyciągnij własne wnioski. Twoje doświadczenie z konkretnym projektem powie Ci więcej niż mój czy Karpathy’ego.

Vibe coding nie jest przyszłością wszystkiego. Jest narzędziem, które wzmacnia programistów, którzy je rozumieją. Junior z vibe coding tools jest nadal juniorem. Senior z vibe coding tools jest 1.5-2x bardziej produktywny.

To ma znaczenie dla rynku pracy, dla edukacji, dla strategii kariery. Programiści, którzy ignorują vibe coding, będą wolniejsi. Programiści, którzy wierzą w 100% vibe coding bez własnych umiejętności, będą oddawać złe produkty.

Środek, jak zwykle, wygrywa.