Vibe Coding kontra Agentic Engineering: co głosi nowy dokument Google na temat SDLC

Od hasła przewodniego do dokumentu technicznego

Na początku 2025 roku Andrej Karpathy zaproponował styl programowania, w którym całkowicie poddaje się nastrojom, podąża za krzywą wykładniczą i przestaje przejmować się faktem istnienia kodu. Cykl obejmował generowanie promptu, jego przyjęcie, uruchomienie oraz, w przypadku błędu, powrót komunikatu o błędzie. To określenie szybko się rozprzestrzeniło, chociaż ludzie już w ten sposób pracowali – po prostu brakowało mu nazwy.

Mniej więcej po szesnastu miesiącach Google opublikował 50-stronicowy dokument zatytułowany „The New SDLC With Vibe Coding”, napisany przez Addy Osmani, Shubham Saboo i Sokratis Kartakis. Jest on bogato opracowany i dobrze zorganizowany, a jego przesłanie jest dotkliwe: vibe coding nadawał się do tworzenia prototypów, jednak stopniowo niszczy systemy produkcyjne, a wiele zespołów tego nie dostrzega, ponieważ szkody narastają powoli. Poniższe sekcje omawiają argumenty zawarte w dokumencie, jego wyraźną granicę oraz konsekwencje dla osób tworzących z agentami AI w 2026 roku.

Dlaczego vibe coding działał i gdzie się kończy

Vibe coding zyskał popularność, ponieważ obniżył progi wejścia. Tworzenie prototypów zajmowało zaledwie kilka minut, osoby niebędące inżynierami mogły skompilować działające narzędzia, a czas potrzebny na przekształcenie pomysłu w działający kod skrócił się z dni do godzin. To jest cenne, a odrzucanie tego jest przejawem inżynieryjnego snobizmu. Problemem jednak nigdy nie były te progi – problemem jest sufit.

Gdy umiejętności agentów się poprawiły, zespoły zaczęły przenosić tę samą swobodną praktykę polegającą na prośbie o wykonanie zadania i jego natychmiastowym przyjęciu do pracy w środowisku produkcyjnym, w tym do API obsługujących płatności, logiki autoryzacji, pipeline’ów danych oraz narzędzi medycznych. Wynik jest schludny i zazwyczaj przechodzi podstawowe testy, więc zostaje wdrożony. Kilka tygodni lub miesięcy później coś się psuje w sposób, który jest kosztowny i trudny do zlokalizowania.

Powodem jest struktura. Podejście typu „vibe coding” zostało stworzone po to, by szybko uruchomić coś, a nie aby spełniać wymagania dotyczące poprawności na poziomie produkcyjnym – to różne cele. Mieszanie ich jest źródłem dzisiejszych problemów. Dokument teoretyczny ma na celu dostarczenie zespołom odpowiedniego słownictwa i ram, aby zapobiec temu mieszaniu.

Spektrum z jednym czynnikiem dzielącym

Artykuł przedstawia spektrum, na jednym końcu którego znajduje się kodowanie nastroju, a na drugim inżynieria agentowa. Większość praktyków znajduje się gdzieś pomiędzy nimi i nie potrafi dokładnie określić, gdzie dokładnie, co samo w sobie stanowi część problemu.

Spektrum to obejmuje trzy wymiary: sposób określania intencji, stopień rygorystycznej weryfikacji oraz profil ryzyka. Jeden czynnik oddziela te dwa krańce, a nie jest to model, którego używasz, inteligencja Twoich zapytań ani narzędzie, które wybierasz. Chodzi o to, w jaki sposób weryfikowane są wyniki.

Potrzebne są dwa rodzaje weryfikacji. Testy deterministyczne sprawdzają, czy funkcja zwraca prawidłowy wynik dla danego wejścia. Ocena trajektorii sprawdza, czy agent postępował zgodnie z właściwą sekwencją kroków rozumowania, aby do tego dojść. Bez obu tych elementów mimo jakkolwiek skomplikowanej architektury nadal zajmujemy się kodowaniem „na chybił trafił”. Dopracowany, płynny wynik, który ominął weryfikację, nie jest sukcesem – to błąd jeszcze bardziej niebezpieczny niż ten, który pokazuje błąd, ponieważ pozostaje ukryty aż do fazy produkcji. To jest nieprzekraczalna granica i wyjaśnia, dlaczego wiele zespołów wykorzystujących zaawansowane procesy oparte na agentach nadal technicznie zajmuje się kodowaniem „na chybił trafił”.

Model nie jest główną zmienną

To prawdopodobnie najważniejsza koncepcja techniczna przedstawiona w tym artykule, a wielu programistów ją błędnie interpretuje. Gdy agent zachowuje się niewłaściwie, typową reakcją jest obwinianie modelu za to, że jest zbyt słaby, zbyt wolny lub zbyt podatny na halucynacje, oraz założenie, że lepszy model rozwiąże problem. Taki tok rozumowania jest niemal zawsze błędny.

Model stanowi tylko jedną część. Pozostałe elementy, mianowicie prompty, narzędzia, zasady kontekstowe, środowiska wykonywania, podagenty oraz możliwości obserwacji, tworzą infrastrukturę wspierającą, a zachowanie agenta w dużej mierze zależy od niej, a nie od samego modelu. Dwa przykłady z artykułu to potwierdzają. W projekcie Terminal Bench 2.0 jedna z drużyn poprawiła wyniki agenta kodującego z poziomu poniżej top 30 na poziom top 5, zmieniając wyłącznie tę infrastrukturę wspierającą. W innym badaniu LangChain modyfikacje promptu systemowego, narzędzi oraz oprogramowania pośredniego przy niezmienionym modelu przyniosły wzrost wyniku agenta kodującego o 13,7 punktu.

Pliki z regułami, narzędzia, środowiska testowe, logika orkiestracji, zasady bezpieczeństwa oraz możliwości obserwacji – wszystko to należy do elementów składowych tego systemu, a jego budowa jest wyłączną odpowiedzialnością zespołu. Dostawca dostarcza silnik, a zespół tworzy wokół niego całą infrastrukturę. Szczerze mówiąc, większość awarii agentów wynika z problemów konfiguracyjnych: brakuującego narzędzia, niejasnej reguły, braku zasady bezpieczeństwa lub okna kontekstowego przepełnionego niepotrzebnymi danymi. Wina spada na model, ponieważ jest to widzialna warstwa, podczas gdy rzeczywisty błąd znajduje się w elementach składowych systemu. Dążenie do aktualizacji modeli przy jednoczesnym zaniedbywaniu tych elementów przypomina montaż szybszego silnika do samochodu bez hamulców.

Inżynieria kontekstu zastępuje inżynierię promptów

Inżynieria promptów jako odrębna dziedzina w dużej mierze zanikła, a jej miejsce zajęła inżynieria kontekstu. Oznacza to dostarczanie agentom bogatych, uporządkowanych informacji na temat bazy kodu, architektury, konwencji oraz celów, nad którymi pracują. W artykule wymieniono sześć typów kontekstu, których potrzebuje każdy agent: instrukcje, wiedza, pamięć, przykłady, narzędzia oraz zasady ograniczające. Każdy z nich może być statyczny, obecny przy każdej interakcji, lub dynamiczny, dostarczany na żądanie.

Kontekst statyczny jest bardzo kosztowny, ponieważ każdy token jest przesyłany przy każdym wywołaniu modelu, niezależnie od tego, czy jest istotny, czy nie. Nadmiar tokenów marnuje zasoby, osłabia sygnał i może pogorszyć wydajność poprzez ukrywanie kluczowych zasad w szumie. Kontekst dynamiczny jest tańszy – pochodzi z pipeline’ów RAG, mechanizmów dopasowywania zadań lub wyników narzędzi w momencie potrzeby. Wybór tego, co trafi gdzie, to kluczowy kompromis inżynieryjny, a nie drobna kwestia konfiguracji, dlatego wymaga wersjonowania, przeglądu oraz takiej samej uwagi jak inne decyzje projektowe.

Najlepszym rozwiązaniem w tym przypadku są umiejętności agenta: ustrukturyzowane, przenośne zestawy wiedzy proceduralnej, które ładowane są tylko wtedy, gdy zadanie ich wymaga. Zamiast wpychać specjalistyczną wiedzę do promptu systemu, umiejętności pozwalają agentowi pozostać lekkim generalistą, który staje się specjalistą w momencie potrzeby. AGENTS.md, który dobrze radzi sobie z tym rozróżnieniem, mógłby wyglądać w ten sposób:

# Project: PaymentService API

## Architecture
- REST API, Node.js, PostgreSQL
- Never modify /src/core/billing without explicit approval

## Agent Skills (load on demand)
- skill:stripe-integration → load when task involves payments
- skill:database-migrations → load when task involves schema changes

## Hard Constraints
- No hardcoded credentials
- All new endpoints require integration tests before merge

Dokładna składnia ma mniejsze znaczenie niż koncepcja intencji zakodowanej jako ograniczenie. Agent uczy się, czym jest, czego może dotknąć, co wyzwala specjalistyczne zachowanie i co jest zabronione bez zatwierdzenia, a nic z tego nie musi znajdować się w każdym oknie kontekstowym. To właśnie różnica pomiędzy agentem, który pozostaje niezawodny przy setkach zadań, a tym, który traci skuteczność już po pierwszych kilkunastu.

Pułapka 80%

Agenci mogą szybko napisać około 80% kodu danej funkcji. Ta część zazwyczaj wygląda schludnie, przetrwa powierzchowną weryfikację i zostanie wdrożona bez problemów, co prowadzi do zamknięcia się pułapki. To ostatnie 20% jest źródłem awarii systemów: przypadki krawędziowe, zasady biznesowe przechowywane w umysłach ludzi, a nie w dokumentach, punkty integracji między usługami stworzonymi lata temu przez oddzielne zespoły oraz drobne wymagania dotyczące poprawności, które ujawniają się dopiero pod rzeczywistym obciążeniem lub w rzeczywistym zachowaniu użytkowników.

Charakter błędów w sztucznej inteligencji również się zmienił. Wcześniejsze narzędzia do programowania ujawniały oczywiste błędy składniowe, które łatwo można było wykryć podczas przeglądania. Obecne systemy powodują błędy koncepcyjne: błędne założenia dotyczące zasad biznesowych, wiarygodne, lecz pomijane przypadki krawędziowe oraz decyzje architektoniczne, które powodują ukryte długoterminowe koszty konserwacji. Kod wygląda poprawnie i może przejść testy, jednak awaria ma charakter strukturalny, jest opóźniona i zazwyczaj jej naprawa jest znacznie droższa niż jej zapobieganie.

Dlatego też ocena trajektorii, czyli analiza ścieżki rozumowania agenta wraz z jego wynikiem, nie może być pomijana w systemach agentowych produkcyjnych. Ocena wyniku sprawdza, czy funkcja zwróciła właściwy rezultat. Ocena trajektorii sprawdza, czy agent zrozumiał problem przed napisaniem czegokolwiek. Każde z tych pytań ma znaczenie, a skupianie się wyłącznie na wyniku pozwala przejść do fazy końcowej nawet w 20% przypadków. Ci deweloperzy, którzy radzą sobie najlepiej, nie przyspieszają pracy poprzez akceptację wszystkiego. Zyskują szybkość, umieszczając własną ocenę tam, gdzie ocena AI jest strukturalnie najsłabsza: przy niejasnych wymaganiach, kompromisach architektonicznych oraz poprawności na granicach systemu.

Tryby dyrygenta i orkiestratora

Artykuł opisuje dwa tryby pracy, a przechodzenie między nimi może być najważniejszą praktyczną zmianą w karierze inżynierów oprogramowania obecnie. W trybie kierownika programista pracuje bezpośrednio w IDE, obserwując powstawanie kodu, wprowadzając korekty i zachowując szczegółową kontrolę nad każdą zmianą. Dzięki temu zachowuje się intuicja i zrozumienie, na których szkolą się inżynierowie. Kosztem jest szybkość przetwarzania, ponieważ osobiste kierowanie każdą interakcją ogranicza korzyści płynące z AI.

Tryb orkiestratora znajduje się na wyższym poziomie. Programiści ustalają cele, przekazują je agentom i sprawdzają uzyskane wyniki, bez konieczności obserwowania powstawania kodu linijka po linijce. Agenci pracują równolegle w tle, czasem przez godziny, i zwracają prośby o integrację. Programista sprawdza to okresowo, ocenia wyniki i kieruje pracę według potrzeb.

Tryb konduktora jest realizowany w czasie rzeczywistym, wymaga bezpośredniego udziału i wykorzystuje pojedynczego agenta. Tryb orkiestratora jest asynchroniczny, wykorzystuje agenty działające równolegle, a wynikiem jest żądanie pull request. Większość programistów jest szkoleni jako konduktorzy, więc przejście na rolę orkiestratora oznacza dużą zmianę w ich funkcjach.

Wymagane umiejętności również się różnią. Kierownicy projektów polegają na głębokiej wiedzy językowej i składniowej, szybkim debugowaniu, zrozumieniu struktury kodu oraz interpretacji błędów w czasie rzeczywistym. Orkiestratorzy potrzebują dokładnych specyfikacji, rozbicia zadań na mniejsze części, szybkiej oceny wyników oraz projektowania systemu, co oznacza określanie ograniczeń, testów i pętli zwrotnej, które zapewniają niezawodność agentów bez ścisłej kontroli. Wielu doświadczonych programistów jest utalentowanymi kierownikami projektów, natomiast orkiestracja wydaje im się niewygodna, ponieważ kojarzy się z rezygnacją z kontroli. Czasami rzeczywiście tak jest, dlatego należy wykorzystać infrastrukturę, zapewnić ocenę zakresu testowania oraz opracować odpowiednie mechanizmy kontekstowe, zanim rozszerzy się orkiestracja. Delegowanie z brakiem odpowiednich mechanizmów weryfikacji to nie inżynieria – to po prostu programowanie na dużą skalę bez odpowiednich zasad.

Pytanie z dziedziny ekonomii

Artykuł traktuje debatę na temat kodowania nastroju kontra inżynierię agentów jako kwestię kosztów, a nie metodologii. Kodowanie nastroju nie wymaga prawie żadnych nakładów na początku: brak dyscypliny w specyfikacji, brak infrastruktury do oceny, brak projektu narzędzi pomocniczych, brak konieczności aktualizacji pliku AGENTS.md. Mimo to szybko gromadzi ukryte koszty operacyjne ze względu na marnotrawstwo tokenów w nieustrukturyzowanym kontekście, rosnącą liczbę błędów w niekontrolowanych wynikach oraz czasu poświęconego przez programistów na naprawianie błędów, które powinny być wykrywane przez automatyczne narzędzia oceny.

Inżynieria agentów wymaga rzeczywistej, wczesnej inwestycji w rygorystyczną specyfikację, infrastrukturę do oceny, projekt narzędzi pomocniczych oraz architekturę kontekstu. Po tym etapie koszt dodatkowy za każdą nową funkcję gwałtownie spada, ponieważ każda nowa umiejętność agenta wykorzystuje te same narzędzia, zestawy do oceny i architekturę kontekstu.

Dla jednego programisty, czy to prototypu, czy projektu pobocznego, kodowanie w stylu vibe wyraźnie przewyższa kosztami inne metody. Nie ma potrzeby ochrony żadnego systemu produkcyjnego, a zadłużenie nie osiąga niebezpiecznego poziomu. Zespoły osiągają ten punkt przełomowy szybciej, niż się spodziewano. Pięciu inżynierów pracujących w trybie vibe przez trzy miesiące może łatwo znaleźć się w sytuacji, gdy jedna trzecia ich czasu jest pochłaniana przez debugowanie i poprawki, których uniknęłaby systematyczna weryfikacja. Infrastruktura typu agentic zwraca swoje koszty, pod warunkiem, że zostanie wdrożona przed tym, jak zadłużenie przekroczy krytyczny poziom.

Co ustala ten artykuł, a czego nie

Ten dokument nie jest propozycją produktu. Jest to dokument ramowy, i to bardziej praktyczny niż większość, ponieważ jego główne twierdzenia można sprawdzić. Efekt „harness” jest rzeczywisty i mierzalny, jak pokazują przytoczone benchmarki. Problem 80% jest rzeczywisty i staje się coraz bardziej aktywny, gdy agenci podejmują się trudniejszych zadań. A przemiana z kierownika na orkiestratora już ma miejsce we wszystkich poważnych organizacjach inżynieryjnych na dużą skalę.

Intencjonalnie pozostawiono otwarte pytanie o to, gdzie dana grupa powinna znaleźć się na tym spektrum. Zależy to od zaangażowania, wielkości zespołu, presji czasowej oraz dojrzałości technicznej – w sposób, którego żaden dokument ramowy nie może określić. Dokument dostarcza słownictwa i modelu myślowego, a decyzja pozostaje w rękach ludzi, co jest prawdopodobnie najszczerszą możliwą postawą.

Struktura się skaluje, ale atmosfera nie. Rozwijający, którzy to już pojmują, budują na zupełnie innych podstawach niż ci, którzy będą musieli się tego nauczyć kosztownie w warunkach produkcyjnych.