W skrócie: vibe coding - budowanie oprogramowania z AI bez czytania i rozumienia kodu, który powstaje - świetnie nadaje się do prototypu i testu pomysłu. Na produkcji zamienia się w koszt: niestabilny kod, dziury bezpieczeństwa i poprawki, które psują kolejne rzeczy. Spec-driven development odwraca kolejność. Najpierw ustalasz potrzeby, funkcje, dokumentację i architekturę - czyli specyfikację. Dopiero potem AI buduje kod według tego planu. To ten sam sprawdzony proces inżynierski co zawsze, tylko AI skraca jego najwolniejsze etapy. Efekt: mniej poprawek, niższy koszt utrzymania i oprogramowanie, które da się rozwijać, a nie tylko pokazać na demie.
Czym jest “vibe coding” i czemu nagle wszyscy o nim mówią?
To budowanie oprogramowania przez opisywanie AI, czego chcesz, i przyjmowanie kodu, który zwróci - bez wchodzenia w to, jak działa. Termin ukuł w lutym 2025 Andrej Karpathy, współtwórca technologii stojącej za ChatGPT: to “nowy rodzaj kodowania […], w którym całkowicie poddajesz się wrażeniom […] i zapominasz, że kod w ogóle istnieje”. Pomysł chwycił tak mocno, że “vibe coding” zostało Słowem Roku 2025 słownika Collinsa.
Urok jest oczywisty: w godzinę masz działające demo, nie pisząc samodzielnie linijki. Ale ten sam Karpathy od razu dodał przypis - to podejście jest dobre “do jednorazowych weekendowych projektów”. Termin urodził się więc z zastrzeżeniem o zakresie. Problem zaczyna się, gdy to zastrzeżenie znika, a “wibe” trafia do oprogramowania, na którym ma stać firma.
Gdzie vibe coding się sprawdza, a gdzie zaczyna kosztować?
Sprawdza się wszędzie tam, gdzie kod jest z założenia jednorazowy albo łatwy do wyrzucenia:
- Prototyp - chcesz zobaczyć pomysł na ekranie, zanim zdecydujesz, czy go budować.
- Wersja do walidacji - pokazujesz koncept klientom, żeby sprawdzić zainteresowanie.
- Wewnętrzne narzędzie na chwilę - skrypt, który policzy coś raz i tyle.
- Nauka - najszybszy sposób, żeby zobaczyć, co jest dziś możliwe.
Szybki prototyp to dobre narzędzie we właściwym miejscu - sięgasz po nie, gdy trzeba zweryfikować pomysł, zanim zainwestujesz w budowę. Granicę najtrafniej ujął inżynier Simon Willison: “jeśli model napisał kod, a Ty go przejrzałeś, gruntownie przetestowałeś i umiesz wyjaśnić komuś, jak działa - to nie jest vibe coding, to wytwarzanie oprogramowania”. Różnica nie polega na tym, że używasz AI. Polega na tym, czy ktoś rozumie i kontroluje to, co powstało. Przy prototypie nie musi. Przy oprogramowaniu, które obsługuje Twoich klientów i Twoje dane - musi.
Co się psuje, gdy “wibe” trafia na produkcję?
Psuje się ostatnie 30%. Inżynier Addy Osmani opisał to jako “problem 70%”: narzędzia AI dowożą 70% rezultatu zaskakująco szybko, ale “ostatnie 30% staje się ćwiczeniem w malejących zwrotach”. To właśnie te 30% decyduje, czy oprogramowanie nadaje się na produkcję: edge case’y, błędy, bezpieczeństwo, integracja z resztą firmy. Efekt Osmani nazywa kodem z domku z kart - “wygląda kompletnie, ale rozpada się pod realnym obciążeniem”.
Najtwardszy dowód dotyczy bezpieczeństwa. W badaniu Veracode na ponad 100 modelach 45% wygenerowanego kodu nie przeszło testów bezpieczeństwa i wprowadzało podatności z listy OWASP Top 10 - a wynik nie poprawiał się wraz z mocą modelu. Na realnych aplikacjach widać skutki: analiza ponad 5600 aplikacji zbudowanych na platformach do vibe codingu znalazła ponad 2000 podatności, ponad 400 ujawnionych haseł i dostępów oraz 175 przypadków wycieku danych osobowych.
Nie ufają temu nawet sami programiści. W ankiecie Stack Overflow 2025 z AI korzysta 84% z nich, ale tylko 3,1% “wysoko ufa” trafności wyników, a 66% jest sfrustrowanych odpowiedziami “prawie dobrymi, ale nie do końca”. “Prawie dobre” to właśnie ten kod, który ktoś w końcu musi zrozumieć i naprawić - zwykle drożej, niż gdyby powstał dobrze za pierwszym razem.
| Vibe coding | Spec-driven development | |
|---|---|---|
| Kiedy | prototyp, test pomysłu | oprogramowanie, na którym stoi firma |
| Punkt startu | ”zobaczmy, co wyjdzie” | potrzeby, funkcje, architektura |
| Co dostajesz | szybkie demo | produkt, który da się rozwijać |
| Koszt utrzymania | rośnie z każdą zmianą | przewidywalny |
| Kto rozumie kod | często nikt | Twój zespół i AI mają wspólny plan |
Dlaczego architektura jest tym, czego vibe coding nie widzi?
Bo vibe coding patrzy na jeden ekran naraz, a architektura to plan całości. Architektura oprogramowania to opis, jak poszczególne części łączą się ze sobą i jak całość urośnie - odpowiednik projektu konstrukcyjnego budynku. Dom postawiony bez takiego projektu stoi, dopóki nie dobudujesz piętra. Oprogramowanie bez architektury działa, dopóki nie przyjdzie pierwszy realny wzrost: więcej użytkowników, nowy proces, połączenie z Twoim systemem magazynowym czy księgowym.
I tu pojawia się rachunek. Model AI poproszony o kolejną funkcję dokłada ją tam, gdzie akurat pasuje - nie tam, gdzie powinna być według planu, bo planu nie ma. Po kilkunastu takich krokach każda zmiana dotyka wszystkiego naraz, a poprawka w jednym miejscu psuje trzy inne. Architektura zaprojektowana na początku jest tania - to kilka decyzji i diagram. Architektura “odkryta” po fakcie, gdy produkt już działa u klientów, oznacza przebudowę, która często kosztuje więcej niż zbudowanie od nowa. Vibe coding nie pomija architektury złośliwie. Po prostu jej nie widzi.
Czym jest spec-driven development?
To podejście, w którym najpierw powstaje specyfikacja, a kod jest jej wynikiem - nie odwrotnie. Kolejność jest dokładnie taka, jakiej dobry inżynier używał zawsze:
- Potrzeby - jaki problem biznesowy oprogramowanie ma rozwiązać.
- Funkcje - co konkretnie ma robić i po czym poznasz, że robi to dobrze.
- Dokumentacja - spisane założenia, ograniczenia i zasady.
- Architektura - jak elementy łączą się ze sobą i jak będą rosły wraz z firmą.
- Dopiero teraz kod - tworzony z pomocą AI, według tego planu.
Nowość polega na roli specyfikacji. Jak ujmuje to GitHub, twórca jednego z narzędzi do tej pracy, specyfikacja to “kontrakt tego, jak ma zachowywać się kod, i staje się źródłem prawdy, którego Twoje narzędzia i agenci AI używają, żeby generować, testować i walidować kod”. Podobnie działa Kiro od AWS, gdzie projekt zaczyna się od trzech dokumentów - wymagań, projektu technicznego i listy zadań - zanim powstanie pierwsza linia kodu. AI nie zastępuje myślenia o tym, co budujesz. Przyspiesza jego spisanie i wykonanie.
Dlaczego zaczynanie od specyfikacji wychodzi taniej?
Bo najdroższy błąd to ten złapany późno. Klasyczne badania kosztów oprogramowania (Barry Boehm, odtworzone w analizie inżynierów NASA) pokazują, że błąd wykryty po wdrożeniu potrafi kosztować nawet 100 razy więcej niż ten sam błąd złapany na etapie wymagań. Nowsze analizy studzą skalę - na 171 projektach nie potwierdzono, by ten efekt był regułą uniwersalną - ale kierunek powtarza się od dekad: im później wychodzi problem, tym drożej kosztuje naprawa. Specyfikacja przesuwa wykrywanie problemów na początek, gdzie zmiana to jedno zdanie w dokumencie, a nie przebudowa gotowego produktu.
To samo widać w statystykach porażek projektów. Raporty Standish Group od lat - mimo dyskusji o metodzie - wskazują niekompletne i zmieniające się wymagania jako jedną z głównych przyczyn nieudanych wdrożeń. Projekty nie wykładają się najczęściej na kodzie, tylko na tym, że nikt na początku nie ustalił dość dokładnie, co ma powstać.
AI tej reguły nie unieważnia - raczej ją zaostrza. W raporcie Google DORA 2024 wzrost użycia AI o 25% wiązał się z szacowanym spadkiem stabilności dostaw o 7,2%, bo szybciej wygenerowany kod trzeba potem więcej poprawiać. Gdy AI pisze błyskawicznie, wąskim gardłem przestaje być pisanie. Staje się nim jasne określenie, co właściwie ma powstać. Czyli specyfikacja.
Skoro AI ma przyspieszać, to po co dokładać specyfikację?
Bo specyfikacja nie jest hamulcem - jest miejscem, w którym najtaniej się steruje. AI pomaga ją napisać: zamienić rozmowę o potrzebach w spisane wymagania i listę funkcji. Potem przyspiesza najwolniejszy etap, czyli sam build, bo buduje według gotowego planu, a nie zgaduje.
Bądźmy uczciwi co do liczb: nie istnieje jeszcze twarde, niezależne badanie mówiące “spec-driven jest o tyle a tyle procent szybszy”. Podejście jest młode i samo środowisko przyznaje, że dopiero wypracowuje standardy. To, co da się obronić, jest prostsze i ważniejsze dla Twojego budżetu: mniej poprawek, mniej debugowania i oprogramowanie, które da się rozwijać. Specyfikacja kosztuje kilka dni na początku. Jej brak kosztuje miesiące na końcu.
Co dzieje się po starcie - utrzymanie, debugowanie, poprawki?
Tu jest większość rachunku. Z badań nad cyklem życia oprogramowania wynika, że utrzymanie pochłania większość całkowitego kosztu - w szacunkach sięga 60-90% - czyli to, co dzieje się po starcie, kosztuje więcej niż samo zbudowanie. Oprogramowanie zbudowane “na wibe” startuje w tej fazie z długiem: nikt nie rozumie kodu, więc każda poprawka jest ryzykiem.
Spec-driven daje tu trwałą przewagę. Specyfikacja zostaje żywym punktem odniesienia - dla Twojego zespołu i dla AI. Na tym fundamencie monitoring działa ciągle: AI obserwuje produkcję, wyłapuje błędy, wskazuje ich źródło i proponuje poprawkę, którą człowiek zatwierdza. To nie jest obietnica z przyszłości. Sentry podaje, że jego asystent do debugowania wskazał źródło błędu z 94,5% trafnością na ponad 38 tys. zgłoszeń (to dane producenta, nie niezależny audyt - ale pokazują kierunek). Tak wygląda kontrola po starcie: testy przed wdrożeniem łapią znane scenariusze, ciągły monitoring łapie te, których testy nie przewidziały. Jedno bez drugiego to połowiczna kontrola.
Co to znaczy, gdy zlecasz albo budujesz oprogramowanie?
Że masz prawo wymagać planu, zanim ktokolwiek napisze kod. To rozróżnia produkt od prototypu sprzedanego w cenie produktu. Zanim zapadnie decyzja o budowie, na stole powinny leżeć cztery rzeczy:
- Potrzeba spisana jako problem biznesowy, nie lista funkcji.
- Funkcje z jasnym kryterium “po czym poznamy, że działa”.
- Architektura opisana na tyle, by było wiadomo, jak to urośnie.
- Plan utrzymania - kto i jak będzie to monitorował po starcie.
Dla Twojej firmy ten model zmienia rachunek na korzyść oprogramowania dopasowanego do Twoich procesów. Gdy specyfikacja jest jasna, a AI skraca budowę, dopasowana aplikacja przestaje być luksusem. Nie płacisz wtedy za licencje od głowy ani za 80% funkcji gotowego narzędzia, których nie używasz - próg wejścia w oprogramowanie szyte na miarę jest dziś niższy niż kiedykolwiek. A że punktem wyjścia jest spisana specyfikacja, kompetencja i dokumentacja zostają u Ciebie. Twój zespół rozumie, co ma, i utrzyma to po zakończeniu projektu - bo wiedza i dokumentacja zostają u Ciebie, nie w czarnej skrzynce wykonawcy.
Zastanawiasz się, czy konkretny proces u Ciebie lepiej obsłuży gotowe narzędzie, czy aplikacja na miarę? Pokażemy to na Twoim przykładzie podczas bezpłatnej konsultacji.
Najczęstsze pytania
Lepiej zlecić oprogramowanie na zamówienie, czy kupić gotowe? Gotowe wygrywa, gdy proces jest standardowy i nie jest Twoją przewagą - księgowość, poczta, podstawowy CRM. Na zamówienie opłaca się tam, gdzie proces jest Twoją przewagą konkurencyjną i żadne pudełko nie pasuje bez kompromisów. Dziś, gdy AI skraca budowę, ta druga ścieżka jest tańsza, niż była jeszcze rok temu. Jak liczyć koszt, pokazujemy we wpisie ile kosztuje wdrożenie AI.
Czy mój zespół utrzyma takie oprogramowanie po zakończeniu projektu? Tak - bo specyfikacja, dokumentacja i architektura zostają u Ciebie, a zespół uczy się ich w trakcie. To jest cała różnica między partnerem a uzależnieniem od jednego wykonawcy.
Od czego zacząć? Od jednego procesu z mierzalnym efektem, nie od wielkiego systemu naraz. Tę samą zasadę opisujemy przy wdrażaniu AI we wpisie od czego zacząć.
Najważniejsze wnioski
- Vibe coding to brak kontroli nad kodem, nie samo używanie AI. Świetny do prototypu, ryzykowny na produkcji.
- Ostatnie 30% jest najtrudniejsze - bezpieczeństwo, błędy i utrzymanie kosztują więcej niż pierwsze demo.
- Architektura to plan całości, którego vibe coding nie widzi - dobudowana po fakcie kosztuje jak przebudowa domu.
- Spec-driven to sprawdzony proces inżynierski - potrzeby, funkcje, dokumentacja, architektura, dopiero kod z AI.
- Najdroższy błąd to ten złapany późno - specyfikacja przesuwa decyzje tam, gdzie zmiana kosztuje najmniej.
- Większość kosztu jest po starcie - utrzymanie to większość rachunku, a tu specyfikacja i ciągły monitoring z AI dają największą przewagę.
- Zanim zlecisz software, zażądaj specyfikacji. Jej brak to nie oszczędność, tylko odroczony koszt.