Kod pisze agent — kto sprawdza jego pracę?

Można powierzyć agentowi zadanie, poczekać na zmiany w repozytorium i otrzymać szkic pull requesta do sprawdzenia. Wraz z kodem pojawia się jednak pytanie: czy wynik odpowiada zadaniu i czy testy nie przeoczyły istotnego problemu?

4 lutego 2026 roku GitHub ogłosił publiczną wersję testową Claude i Codex jako agentów kodujących. Firma poinformowała, że agentom można przypisywać zadania z issues i pull requestów, a następnie sprawdzać przygotowany przez nich szkic PR. Potwierdza to, że taki scenariusz pojawił się w środowisku programistycznym, ale nie dowodzi ani oszczędności czasu, ani poprawy jakości kodu.

Pytanie nie dotyczy więc wyłącznie tego, czy agent potrafi napisać kod. Ważne jest również, jaką pracę człowiek musi wykonać wokół powierzonego zadania: określić ograniczenia, nadzorować przebieg pracy i ocenić wynik.

Nadzór to nie tylko końcowy przegląd

W preprincie opublikowanym na arXiv 21 września 2026 roku badacze proponują, by traktować nadzór nad agentem kodującym jako proces przebiegający etapami. Praca The Work Behind Delegation opiera się na obserwacjach i schematach pracy 19 doświadczonych programistów. Autorzy opisują siedem etapów nadzoru i stosują te ramy do publicznych dyskusji programistów na Reddicie.

Wśród opisanych przez autorów podejść są: poświęcanie większej uwagi planowaniu, przekazywanie części zadań nadzorczych innym agentom oraz przekształcanie powtarzających się instrukcji w materiały do ponownego wykorzystania. To ramy analityczne, a nie pomiar nakładu czasu: praca nie ustala, ile czasu programiści poświęcają na nadzór ani czy taki proces jest szybszy od pracy ręcznej. Na stronie arXiv preprint jest oznaczony jako będący w trakcie recenzji, dlatego jego wnioski należy uznać za wstępne.

W praktyce warto rozróżnić trzy działania. Określenie zadania wyznacza cel i ograniczenia. Nadzór pomaga zauważyć, czy agent nie odszedł od zamierzonego kierunku. Weryfikacja pozwala ocenić, czy wynik można zaakceptować z uwzględnieniem wymagań, kodu i testów. Sukces na jednym etapie nie gwarantuje sukcesu na kolejnym: poprawka może wyglądać wiarygodnie, a mimo to rozwiązywać niewłaściwy problem lub wymagać znacznych przeróbek.

Doświadczenia społeczności to nie statystyka

W dyskusji na r/LocalLLaMA jeden z uczestników napisał, że jego doświadczenia z lokalnymi modelami i agentami były rozczarowujące: jak twierdził, musiał poprawiać wyniki i przypominać agentom o instrukcjach. Inni uczestnicy tego samego wątku opisali proces, który sprawdzał się u nich lepiej: ograniczanie zakresu zadań, praca etapami i uważne sprawdzanie kodu. Są to pojedyncze relacje użytkowników, a nie porównywalny test modeli ani pomiar wydajności zespołów.

Tak różne opinie pokazują, że doświadczenia mogą zależeć od zadania, modelu, środowiska i sposobu pracy. Na podstawie jednej dyskusji nie można jednak ustalić, które praktyki są średnio skuteczniejsze ani jak często pojawiają się problemy. Wątek dotyczy modeli lokalnych, dlatego jego obserwacji nie należy automatycznie odnosić do wszystkich narzędzi agentowych.

Sam udział człowieka nie oznacza, że delegowanie jest bezużyteczne. Programista może dzielić zadanie na części, sprawdzać zmiany i doprecyzowywać wymagania, pozostając odpowiedzialnym za wynik. Bez uwzględnienia czasu potrzebnego na określenie zadania, poprawki i przegląd nie da się jednak stwierdzić, czy całkowity nakład pracy się zmniejszył.

Szkic PR to jeszcze nie zaakceptowany PR

W opisanym scenariuszu GitHuba agentowi można przypisać issue i otrzymać szkic pull requesta. Między jego utworzeniem a akceptacją pozostają osobne kwestie: czy zmiana spełnia wymagania, czy uwzględniono przypadki brzegowe, czy testów jest wystarczająco dużo i czy rozwiązanie pasuje do architektury projektu.

Kryteriów tych nie da się sprowadzić do jednego wskaźnika. Liczba utworzonych zmian nie jest równa liczbie zmian nadających się do użycia, a pomyślne przejście testów nie musi potwierdzać wszystkich istotnych właściwości poprawki. Nawet wynik, który wygląda na wysokiej jakości, sam w sobie nie pokazuje, ile pracy wymagało jego przygotowanie i sprawdzenie.

Aby ocenić całościowy efekt, trzeba uwzględnić cały cykl: określenie zadania, oczekiwanie na wynik, przegląd, poprawki i późniejsze utrzymanie kodu. Omawiane źródła nie przedstawiają takiego całościowego porównania.

Co można wywnioskować

Preprint proponuje ramy do rozmowy o nadzorze, a GitHub poinformował o scenariuszu, w którym agentowi przypisuje się zadanie, a następnie sprawdza przygotowany PR. Dyskusja na Reddicie pokazuje, że poszczególni użytkownicy opisują zarówno trudności, jak i przydatne sposoby pracy z modelami lokalnymi. Materiały te pozwalają postawić pytanie o organizację weryfikacji delegowanego kodu, ale nie dają odpowiedzi na temat produktywności netto.

Nie można na ich podstawie wywnioskować, że programiści jako całość przeszli już od pisania kodu do nadzoru, że agenci niezmiennie generują dodatkową pracę ani że zwiększają produktywność całej branży. Do takich wniosków potrzebne są porównywalne pomiary czasu i jakości w różnych zadaniach i zespołach.

Praktyczne pytanie dla zespołu jest bardziej konkretne: jakie zmiany agent może przygotować samodzielnie, co należy sprawdzić przed scaleniem i kto odpowiada za to, by wynik rozwiązywał pierwotny problem? Delegowanie nie eliminuje tej pracy inżynierskiej — zmienia jedynie to, gdzie się zaczyna i na czym się koncentruje.