Najciekawsze pytanie w agentic software engineering nie brzmi już, czy model potrafi pisać kod. Potrafi.
Trudniejsze pytanie brzmi, czy taki wynik może przejść przez produkcyjny system delivery bez zastępowania osądu inżynierskiego pewnością modelu.
Przydatny workflow agentowy potrzebuje więc czegoś więcej niż dobrego promptu. Potrzebuje tego samego, czego dojrzałe systemy delivery nauczyły się już cenić: granic, dowodów, powtarzalności i ownershipu.
Kontekst jest częścią systemu
Model rozumuje wyłącznie na podstawie kontekstu, który otrzymuje. W prawdziwym repozytorium ten kontekst to nie jeden README i ticket. Obejmuje architekturę, aktualny kod, konwencje, testy, ograniczenia, wcześniejsze decyzje i stan prac sąsiednich.
To sprawia, że context engineering staje się problemem inżynieryjnym, a nie ozdobą promptu.
Praktyczny ruch polega na jawnym wskazaniu źródeł prawdy i celowym ich ładowaniu. Repo-aware agent powinien wiedzieć, co może traktować jako autorytatywne, co jest jedynie historyczne i co musi zweryfikować względem obecnej implementacji.
Narzędzia potrzebują kontraktów
MCP i podobne interfejsy narzędziowe są wartościowe, bo dają agentom ustrukturyzowany dostęp do repozytoriów, usług i kroków walidacyjnych. Jednocześnie zwiększają promień rażenia błędnej decyzji.
Dlatego dostęp do narzędzi powinien być na tyle wąski, by dało się go wyjaśnić.
Przydatnym modelem mentalnym jest kontrakt API:
- agent otrzymuje ograniczoną capability;
- wejścia i wyjścia są obserwowalne;
- operacje destrukcyjne są oddzielone od inspekcji read-only;
- walidacja jest innym krokiem niż implementacja;
- uprawnienie do release’u pozostaje jawne.
Celem nie jest maksymalna autonomia. Celem jest użyteczna autonomia wewnątrz systemu, który nadal potrafi wyjaśnić, co się wydarzyło.
Walidacja musi być niezależna od generacji
Jeżeli ten sam kontekst i ta sama ścieżka rozumowania generują zmianę i stwierdzają, że jest poprawna, workflow ma jeden punkt awarii noszący dwa kapelusze.
Testy pomagają, ale zasada jest szersza. Review powinien używać innej perspektywy: kryteriów akceptacji, ryzyka regresji, granic architektonicznych, ograniczeń bezpieczeństwa i dowodów z narzędzi zamiast narracji wygenerowanej przez agenta implementacyjnego.
Dlatego preferuję etapową pętlę:
- zrozumieć i zdekomponować;
- zaimplementować w ograniczonym zakresie zadania;
- zwalidować za pomocą jawnych dowodów;
- wykonać niezależny review;
- oddać merge i release z powrotem właścicielowi po stronie człowieka.
Zasada produkcyjna
Agent powinien zasługiwać na większą autonomię przez dostarczanie lepszych dowodów, a nie przez brzmienie bardziej pewnie.
Najmocniejsze workflow agentowe będą wyglądały mniej jak magiczne okno czatu, a bardziej jak dobre release engineering z nową klasą wykonawcy wewnątrz pętli.