Co agentic engineering oznacza dla zespołu inżynierskiego

Agentic engineering, vibe coding i programowanie wspomagane przez AI

Simon Willison, którego przewodnik po wzorcach agentic engineering należy do najjaśniejszych omówień tematu, używa tego pojęcia na określenie tworzenia oprogramowania z pomocą agentów kodujących, czyli agentów, którzy potrafią zarówno pisać, jak i uruchamiać kod. Agenta opisuje jako oprogramowanie, które w pętli uruchamia narzędzia, aby osiągnąć cel, a wykonywanie kodu wskazuje jako zdolność, która umożliwia tę praktykę, bo agent może iteracyjnie dochodzić do oprogramowania, które da się pokazać jako działające.

Vibe coding, pojęcie, które Andrej Karpathy ukuł w lutym 2025 roku, Willison rezerwuje dla pierwotnego znaczenia: proszenia modelu o kod przy jednoczesnym zapominaniu, że ten kod w ogóle istnieje. Vibe coding oznacza więc niesprawdzone wyniki na poziomie prototypu, a agentic engineering kod, który ktoś doprowadził do poziomu produkcyjnego. Agentic development i agentic software development to nazwy tej samej praktyki. Asystenci w stylu autouzupełniania, którzy podpowiadają linie kodu, niczego nie uruchamiając, do niej nie należą.

Dokąd przesuwa się praca

Pisanie kodu staje się mniejszą częścią pracy. Willison podkreśla, że rzemiosło zawsze polegało na decydowaniu, jaki kod napisać, i ta praca zostaje u ludzi. W praktyce widać ją w czterech miejscach:

• Specyfikowanie: zadania opisane z takim kontekstem i kryteriami akceptacji, by agent mógł pracować bez zgadywania
• Budowanie harnessu: pliki instrukcji, narzędzia, sandboksy i uprawnienia, dzięki którym agent bezpiecznie uruchamia build i testy
• Weryfikowanie: testy, CI i przegląd przez człowieka na tyle mocne, by wyłapać błędy agenta
• Utrwalanie wniosków: modele nie uczą się na błędach, ale zespół może aktualizować instrukcje i harness po każdej porażce agenta

Spec driven development z agentami kodującymiHarness engineering dla agentów kodujących

Co badania mówią o wynikach

Raport DORA z 2025 roku, oparty na ankiecie wśród prawie 5000 specjalistów technologicznych, opisuje główną rolę AI w tworzeniu oprogramowania jako wzmacniacza istniejących mocnych i słabych stron organizacji. 90% respondentów używało AI w pracy, a ponad 80% uważało, że zwiększyła ich produktywność, przy czym 30% deklarowało małe zaufanie albo jego brak do kodu generowanego przez AI. Według raportu wdrożenie AI poprawia teraz przepustowość dostarczania, ale nadal zwiększa jego niestabilność.

Zmierzone wyniki mogą różnić się od odczuć. W randomizowanym badaniu METR z udziałem 16 doświadczonych programistów open source i narzędzi z początku 2025 roku zadania z dozwoloną AI trwały o 19% dłużej, choć programiści spodziewali się przyspieszenia o 24%, a po fakcie uważali, że byli o 20% szybsi. W lutym 2026 roku METR napisał, że z obecnymi narzędziami programiści są prawdopodobnie szybsi, ale efekty selekcji w badaniu uzupełniającym sprawiają, że nowe dane są bardzo słabym dowodem na to, o ile. Praktyczny wniosek: mierz na własnej pracy, zamiast polegać na wrażeniach albo liczbach od dostawców.

Fundamenty, od których zależy, czy to się opłaca

Model AI Capabilities od DORA wymienia siedem praktyk, które w danych wzmacniały korzyści z AI: jasne i zakomunikowane stanowisko wobec AI, zdrowe ekosystemy danych, dostępne dla AI dane wewnętrzne, solidne praktyki kontroli wersji, pracę w małych partiach, koncentrację na użytkowniku i dobre platformy wewnętrzne. Żadna z nich nie jest funkcją agenta kodującego. W praktyce przekładają się na pytania, które zespół może sprawdzić przed skalowaniem agentów:

• Czy inżynierowie wiedzą, z jakich narzędzi, danych i repozytoriów agenci mogą korzystać?
• Czy agent zbuduje i przetestuje kod w świeżym środowisku bez pomocy człowieka?
• Czy zmiany są na tyle małe, że recenzent zrozumie każdą z nich?
• Czy agenci działają z własnymi, wąskimi uprawnieniami w środowisku, w którym błąd nie dosięgnie produkcji?

Ostatnie pytanie nawiązuje do wskazówek inżynierskich Anthropic dotyczących agentów, które zalecają obszerne testy w środowiskach sandboksowych z odpowiednimi zabezpieczeniami, bo autonomia oznacza wyższe koszty i kumulujące się błędy.

Bezpieczeństwo agentów AI do programowania

Pierwszy krok dla jednego zespołu

Hipotetyczny przykład: zespół bierze dwadzieścia niedawno zamkniętych zgłoszeń z własnego backlogu, z ich zmergowanymi zmianami jako punktem odniesienia. Konfiguruje jednego agenta z poleceniami build i test repozytorium, krótkim plikiem instrukcji i uprawnieniami ograniczonymi do jednego brancha. Każde zgłoszenie zostaje wykonane ponownie z agentem, a zespół zapisuje czas przeglądu, poprawki, nieudane przebiegi CI i koszt modelu na zaakceptowaną zmianę, obok tych samych wartości dla pierwotnych zmian ludzi. Dwadzieścia zgłoszeń nie rozstrzygnie sprawy, ale pokaże, gdzie brakuje harnessu albo specyfikacji, i to właśnie zespół naprawia przed rozszerzeniem próby.

Gdzie zwykle jeszcze się to nie opłaca: kod bez testów, które agent może uruchomić, praca, której wymagania istnieją tylko w głowach ludzi, i środowiska wymagające ręcznych kroków przy budowaniu. Te luki spowalniają też ludzi, a ich usunięcie bywa pierwszym kawałkiem pracy w duchu agentic engineering.

Pilotaż agentów kodujących, który porównuje narzędzia na tej samej pracyWdrażanie agentów kodujących