Vibe coding vs Agentic Engineering, dwa paradygmaty pracy z AI

Marcin Różański

Vibe coding i agentic engineering to dwa sposoby tworzenia oprogramowania z pomocą modeli językowych. Oba nazwał Andrej Karpathy. Vibe coding polega na generowaniu kodu z promptów i akceptowaniu go bez czytania. Agentic engineering to model pracy, w którym agenci AI piszą i testują kod, a inżynier projektuje zadanie, nadzoruje wykonanie i odpowiada za wynik. Różnica nie dotyczy narzędzi, tylko poziomu kontroli. To ona decyduje, czy kod nadaje się na produkcję.

Czym jest Vibe Coding?

Vibe coding to styl tworzenia oprogramowania, w którym użytkownik opisuje w języku naturalnym, co ma powstać, a model AI generuje kod, którego nikt nie czyta ani nie weryfikuje. Termin wprowadził Andrej Karpathy, współzałożyciel OpenAI, we wpisie na X z 2 lutego 2025 roku. Opisał w nim pracę, w której zapomina się, że kod w ogóle istnieje. Jedyną miarą sukcesu jest to, czy program działa po uruchomieniu.

W praktyce vibe coding przypomina pętlę: prompt, uruchomienie, obserwacja efektu, kolejny prompt. Błędy zgłasza się modelowi do poprawy, zamiast szukać ich przyczyny w kodzie. Vibe coding ma niski próg wejścia. Może z niego korzystać zarówno programista, jak i citizen developer z wiedzą domenową, ale bez doświadczenia w programowaniu. Dlatego vibe coding dobrze sprawdza się w prototypach, demonstracjach i jednorazowych narzędziach.

W pracy zawodowej programistów vibe coding pozostaje praktyką niszową. W Stack Overflow Developer Survey 2025 wzięło udział ponad 49 tys. osób ze 177 krajów. 84% z nich używa narzędzi AI lub planuje to robić. Jednocześnie 72% ankietowanych stwierdziło, że vibe coding nie jest częścią ich pracy zawodowej, a kolejne 5% zdecydowanie go odrzuciło (Stack Overflow, 2025). Powszechne użycie AI nie oznacza więc rezygnacji z kontroli nad kodem.

vibe coding

Czym jest agentic engineering?

Agentic engineering to sposób wytwarzania oprogramowania, w którym agenci AI planują, piszą i testują kod, a inżynier definiuje zadanie, nadzoruje pracę agentów i odpowiada za jakość wyniku. Nazwę zaproponował Andrej Karpathy 8 lutego 2026 roku, w pierwszą rocznicę wpisu o vibe codingu (The New Stack, 2026). „Agentic”, bo domyślnie nie pisze się już kodu samodzielnie, tylko orkiestruje agentów. „Engineering”, bo wymaga to wiedzy i warsztatu.

Agentic engineering zmienia przede wszystkim rolę człowieka, a nie ilość kodu generowanego przez AI. Agent działa w cyklu: otrzymuje zadanie, przygotowuje plan, wprowadza zmiany w wielu plikach, uruchamia testy, analizuje wyniki i poprawia błędy. Inżynier zatwierdza plan, przegląda zmiany i decyduje o wdrożeniu. Agentic engineering zakłada więc to, z czego vibe coding świadomie rezygnuje: specyfikację, testy automatyczne, code review i jasno przypisaną odpowiedzialność za kod.

Czym różnią się vibe coding i agentic engineering?

Vibe coding i agentic engineering różnią się przede wszystkim tym, kto i jak weryfikuje kod. W vibe codingu weryfikacją jest uruchomienie programu: jeśli działa, praca jest skończona. W agentic engineering kod przechodzi przez testy, przegląd i bramki akceptacji, zanim trafi na produkcję. Z tej jednej różnicy wynikają kolejne: inny cel, inny profil użytkownika, inne ryzyka i inne miejsce w cyklu życia oprogramowania.

KryteriumVibe codingAgentic engineering
CelSzybko uzyskać działający efektDostarczyć utrzymywalne oprogramowanie produkcyjne
Kto pisze kodModel AI na podstawie promptówAgenci AI według zatwierdzonego planu
Czy ktoś czyta kodNie, z założeniaTak, analiza kodu pozwala na optymalizacje procesu
Rola człowiekaOpisuje efekt i ocenia działanieProjektuje zadanie, nadzoruje, zatwierdza
SpecyfikacjaOgólny opis w prompcieUser story, standardy, kontekst projektu
Testy i code reviewZwykle brakTesty automatyczne i przegląd zmian
Wymagane kompetencjeWiedza domenowaArchitektura, bezpieczeństwo, procesy
Główne ryzykoPodatności i dług technologicznyBłędy agenta przepuszczone przez słabą kontrolę
Typowe zastosowaniePrototyp, PoC, narzędzie jednorazoweRozwój i utrzymanie systemów CRM, HCM, ERP
Horyzont życia koduDni lub tygodnieLata

Kiedy vibe coding wystarczy, a kiedy staje się ryzykiem?

Vibe coding wystarczy wtedy, gdy kod ma żyć krótko i nie dotyka danych produkcyjnych. Dobre przykłady to prototyp integracji CRM z nowym kanałem komunikacji, makieta ekranu dla interesariuszy czy skrypt jednorazowo porządkujący eksport danych. W takich zastosowaniach liczy się tempo weryfikacji pomysłu, a ewentualne błędy kosztują niewiele. Prototyp powstały metodą vibe codingu warto traktować jako materiał do rozmowy o wymaganiach, nie jako gotowy komponent.

Vibe coding staje się ryzykiem, gdy niesprawdzony kod trafia do systemu produkcyjnego. Veracode w raporcie 2025 GenAI Code Security Report przeanalizował 80 zadań programistycznych wykonanych przez ponad 100 modeli językowych. W 45% przypadków wygenerowany kod zawierał podatności, a dla Javy odsetek błędów bezpieczeństwa przekroczył 70% (Veracode, 2025). W centralnym CRM obsługującym sprzedaż, serwis i marketing oznacza to realne ryzyko dla danych klientów.

Drugim problemem vibe codingu w środowisku produkcyjnym jest utrzymanie. Kod generowany doraźnie bywa niespójny, pozbawiony architektury i trudny do rozwijania przez kolejne osoby. Programiści dostrzegają to coraz wyraźniej: według Stack Overflow Developer Survey 2025 aż 46% z nich nie ufa trafności wyników generowanych przez AI, wobec 31% rok wcześniej (Stack Overflow, 2025). Im dłużej kod ma działać, tym droższy staje się brak przeglądu.

vibe coding

Jak wygląda agentic engineering w praktyce zespołu wdrożeniowego?

Agentic engineering zaczyna się od opisania procesu, a nie od wyboru narzędzia. W eVolpe testujemy to podejście przy pracach nad projektami wdrożeniowymi. Pracę dewelopera podzieliliśmy na etapy: planowanie, implementację, self-testy, code review, testy i iterację poprawek. Dopiero tak opisany proces pozwala sprawdzić, które etapy są powtarzalne, dają się sparametryzować i, co najważniejsze, zweryfikować.

Agent pracujący w Claude Code od Anthropic dostaje User Story, planuje kroki, implementuje zmiany, uruchamia testy i poprawia błędy, zanim zgłosi gotowość do przeglądu. Wiedzę o projekcie czerpie ze skilli, czyli ustrukturyzowanych instrukcji. Skille techniczne opisują architekturę i standardy, a skille procesowe opisują planowanie, code review czy self-testy. Bez takiego kontekstu agent działa generycznie i tworzy kod niespójny z resztą systemu.

Odpowiedzialność za efekt końcowy pozostaje po stronie programisty, który sprawdza, czy kod jest poprawny, bezpieczny i zgodny z intencją biznesową. Gdy agent popełni błąd, programista nie tylko go poprawia, ale też ustala, czy źródłem był nieprecyzyjny skill, i aktualizuje go. Weryfikacja jest więc jednocześnie doskonaleniem systemu. Szczegóły opisujemy w artykułach o agentic engineering we wdrożeniu systemu i o bramkach akceptacji decyzji agenta.

Czy agentic engineering to to samo co agenci AI w CRM?

Nie. Agentic engineering dotyczy sposobu tworzenia oprogramowania, a agenci AI w CRM są funkcją samego systemu biznesowego. W agentic engineering agent pisze i testuje kod. Agent w CRM, na przykład w Creatio, kwalifikuje leady, przygotowuje wstępne oferty, aktualizuje rekordy czy uruchamia kampanie w systemie marketing automation. Oba zjawiska korzystają z podobnej architektury: modelu językowego, narzędzi, pamięci i pętli planowania.

Rozróżnienie ma znaczenie przy planowaniu projektu. Klasyczna AI w CRM ograniczała się do predykcji i rekomendacji, np. scoringu leadów, a decyzję podejmował użytkownik. Agent CRM sam inicjuje działania w dozwolonym zakresie, więc wymaga zarządzania uprawnieniami, audytu działań i deterministycznych reguł, których model nie może obejść. Zespół budujący takiego agenta może stosować agentic engineering, ale oba pojęcia nie są tożsame.

Jak PM i decydent IT powinni ocenić projekt oparty na AI?

Project manager i decydent IT powinni najpierw ustalić, czy mają do czynienia z eksperymentem, czy z rozwiązaniem produkcyjnym. Eksperyment, np. prototyp nowej integracji, może powstać metodą vibe codingu i zostać porzucony po weryfikacji pomysłu. Rozwiązanie produkcyjne wymaga pełnego cyklu: specyfikacji, testów, przeglądu kodu, kontroli uprawnień i właściciela odpowiedzialnego za utrzymanie. Samo pytanie „czy projekt wykorzystuje AI” przestaje wystarczać.

Przy wyborze partnera wdrożeniowego warto zadać trzy pytania. Czy partner ma opisany i powtarzalny proces wytwarzania, który agenci mogą przyspieszyć? Czy standardy kodowania i architektura systemu są udokumentowane na tyle, by przekazać je agentowi? Czy w projekcie działają testy automatyczne i code review, które wychwycą błędy agenta? Odpowiedź „nie” na którekolwiek z nich oznacza, że pierwszym krokiem jest uporządkowanie procesu, a nie zakup narzędzia.

Vibe coding i agentic engineering nie wykluczają się, tylko tworzą ścieżkę dojrzewania. Vibe coding przyspiesza weryfikację pomysłów, a agentic engineering pozwala bezpiecznie przenieść je na produkcję. Organizacja, która zaczyna od pilotażu, a potem buduje procesy, standardy i mechanizmy kontroli, ogranicza ryzyko. Jednocześnie stopniowo zdobywa kompetencje potrzebne do pracy z agentami AI w systemach CRM, HCM i marketing automation.

Najczęściej zadawane pytania

Kto wymyślił termin vibe coding?

Andrej Karpathy, współzałożyciel OpenAI, we wpisie na X z 2 lutego 2025 roku. Opisał w nim styl pracy, w którym kod generowany przez AI przyjmuje się bez czytania, a jedynym sprawdzianem jest to, czy program działa.

Kiedy pojawił się termin agentic engineering?

Andrej Karpathy zaproponował go 8 lutego 2026 roku jako nazwę profesjonalnej pracy z agentami AI, która zastępuje vibe coding. Nazwa podkreśla, że agenci piszą kod, a inżynier nimi kieruje i sprawuje nadzór.

Czy vibe coding nadaje się do zastosowań produkcyjnych?

Co do zasady nie. Kod generowany bez przeglądu i testów często zawiera podatności. Veracode wykazał je w 45% badanych zadań (2025). Vibe coding dobrze sprawdza się w prototypach, proof of concept i jednorazowych narzędziach.

Czy agentic engineering wymaga umiejętności programowania?

Tak. Inżynier musi ocenić plan agenta, przejrzeć zmiany, rozumieć architekturę systemu i projektować testy. Agentic engineering zmienia rolę programisty z autora kodu na architekta i recenzenta, ale nie eliminuje potrzeby wiedzy technicznej.

Czym agentic engineering różni się od AI-assisted coding?

W AI-assisted coding model podpowiada kod, a programista akceptuje kolejne fragmenty. W agentic engineering agent realizuje całe zadanie: planuje, zmienia wiele plików i uruchamia testy. Człowiek przegląda gotową propozycję.

Czy agentic engineering to to samo co agentic AI w CRM?

Nie. Agentic engineering opisuje sposób tworzenia oprogramowania. Agentic AI w CRM to agenci działający wewnątrz systemu, np. kwalifikujący leady lub przygotowujący oferty. Obie dziedziny korzystają z podobnej architektury, ale rozwiązują inne problemy.

Od czego zacząć wdrażanie agentic engineering w zespole?

Od opisania rzeczywistego procesu wytwarzania i udokumentowania standardów kodowania. Następnie warto wybrać jeden powtarzalny etap, np. self-testy lub code review, i przekazać go agentowi z obowiązkowym przeglądem człowieka.

Jesteś gotowy na prowadzenie dużego projektu wdrożeniowego w Twojej firmie?

Darmowy kurs mailowy

Źródła

Marcin Różański
Przewijanie do góry