Co zostaje człowiekowi w inżynierii agentowej

Poziom 4 Wyjaśnienie Zaktualizowano 2026-10-10

Człowiekowi w inżynierii agentowej zostają decyzje, których żadna wyrocznia weryfikacyjna nie podejmie za agenta: smak, architektura, kierunek produktu, projekt ewaluacji i warunków stopu, uprawnienia, z jakimi działają agenci, oraz decyzja, które pętle nie mogą chodzić bez nadzoru. Za każdą z tych decyzji odpowiada nazwana osoba.

Agenci twojego zespołu otwierają dziś w jeden dzień więcej pull requestów, niż zespół pisał kiedyś w tydzień. Review po cichu zamieniło się w zatwierdzanie, nocna pętla chodziła z uprawnieniami, które zostawiła ostatnia sesja, i nikt nie umie powiedzieć, kto o tym zdecydował. Ta strona jest dla programisty, który chce wiedzieć, na czym teraz polega jego praca, dla tech leada, który musi to spisać dla zespołu, oraz dla CTO i zarządu, którzy muszą za to odpowiadać.

Co daje ci rozpisanie roboty człowieka

Sześć obowiązków, których nie da się przekazać agentowi, każdy z nazwanym źródłem.
Test czterech pytań, który dla każdej pętli rozstrzyga, czy może działać bez nadzoru.
Wiersz rejestru autonomii do wklejenia w podręcznik zespołu, dzięki któremu każda pętla bez nadzoru ma właściciela, powód i datę przeglądu.
Komendy dla każdego narzędzia, które zamieniają decyzję o uprawnieniach w konfigurację.
Cztery sprawdzenia, które dowodzą, że decyzje człowieka nadal obowiązują, bez czytania każdego diffa.
Trzy gotowe prompty oraz sposób naprawy dla każdej drogi, którą robota człowieka po cichu znika.

Dlaczego robota człowieka się przesuwa, a nie kurczy?

Praca zmienia kształt. Opublikowane przez Andreja Karpathy’ego podsumowanie jego wystąpienia na Sequoia Ascent (30 kwietnia 2026) ujmuje to tak: „Jednostka programowania przesunęła się z pisania linii kodu na delegowanie większych »makrodziałań«”. BCG Platinion, piszące jako konsultanci w marcu 2026, mówi to samo zdaniem, które zrozumie zarząd: „Zmiana definiująca nie polega na braku ludzi, tylko na przeniesieniu ludzkiego wysiłku”. Doświadczonych inżynierów, którzy z agentami pracują szybciej i nadal odpowiadają za oprogramowanie, Simon Willison opisał nazwą vibe engineering; później uznał, że górę bierze agentic engineering.

Na poziomie 2 drabiny autonomii wszystkie sześć obowiązków poniżej chowa się w samym pisaniu kodu, więc wydają się automatyczne i nikt ich nie nazywa. Od poziomu 3 w górę każdy trzeba zapisać w pliku, bramce albo polityce. Agent sam ich nie wywnioskuje, a przechodzący zestaw testów nie zgłosi ich braku.

Które sześć obowiązków zostaje przy człowieku?

Obowiązek	Decyzja	Gdzie jest zapisana	Źródło
Smak	Ta działająca implementacja jest tą złą	Brief architektoniczny, kryteria review	Karpathy (transkrypt), kwiecień 2026
Architektura	Granice, warstwy i kierunek zależności	Plik instrukcji, fitness functions	Karpathy (transkrypt), kwiecień 2026; DORA, wrzesień 2025
Kierunek produktu	Co budować, a czego nie powinno być	Specyfikacja, kryteria akceptacji	Karpathy (transkrypt), kwiecień 2026; Shapiro, styczeń 2026
Projekt ewaluacji i warunku stopu	Co znaczy „zrobione”, jako komendy kończące się kodem 0	Testy, zestaw ewaluacji, konfiguracja CI	Shapiro; Stripe, luty 2026; Naresh, lipiec 2025
Uprawnienia	Co agent może uruchomić bez pytania	Pliki ustawień, profil sandboksa	Dokumentacja Claude Code i Codex
Decyzja, czego nie automatyzować	Które pętle chodzą bez nadzoru i kto za nie odpowiada	Rejestr autonomii	Linear, sierpień 2025

Smak

W opublikowanym transkrypcie Karpathy mówi o dzisiejszej pozycji agentów wprost: „Na razie agenci są jak stażyści. Nadal odpowiadasz za estetykę, osąd, smak i nadzór”. Smak to osąd, że działająca implementacja jest tą złą: abstrakcja, która będzie kosztować rok, zależność, która rozwiązuje dzisiejszy problem i przejmuje jutrzejszy, API poprawne i nie do użycia. Żaden test na tym nie padnie i właśnie dlatego to zostaje przy człowieku.

Architektura

„Nadal musisz rozumieć podstawy”, mówi Karpathy w swoim wystąpieniu (opublikowany transkrypt), i „nie będziesz dobrym reżyserem, jeśli nie rozumiesz”. Architektura ma najwolniejszą pętlę zwrotną w całej pracy: złe decyzje wychodzą na jaw miesiące po przebiegu, w którym zapadły. Raport DORA 2025 (wrzesień 2025) stwierdza, że „zespoły pracujące w luźno powiązanych architekturach, z szybkimi pętlami zwrotnymi, notują zyski, a te skrępowane ciasno powiązanymi systemami i wolnymi procesami zyskują niewiele albo nic”. Architektura rozstrzyga, ile przyspieszenia zespół zatrzyma.

Kierunek produktu

W opublikowanym transkrypcie Karpathy nazywa wąskie gardło: „Sam staję się wąskim gardłem w tym, żeby w ogóle wiedzieć, co próbujemy zbudować, po co to robić i jak kierować agentami”. Człowiek z poziomu 4 u Dana Shapiro (The Five Levels, styczeń 2026) pisze specyfikację i pracuje bardziej jak menedżer inżynierii albo produktu niż jak programista. Agent zbuduje to, co mówi specyfikacja, z cierpliwością większą niż jakikolwiek zespół. Nie powie ci, że tej funkcji nie powinno być.

Projekt ewaluacji i warunku stopu

Ten obowiązek rośnie, gdy inne maleją. Poziom 4 u Shapiro to „wychodzisz na 12 godzin i sprawdzasz, czy testy przechodzą”, co jest bezpieczne tylko wtedy, gdy ktoś te testy zaprojektował. Naresh (DEV Community, lipiec 2025) ujmuje argument za determinizmem: „Model może argumentować, że jego praca jest skończona. Deterministyczny walidator może udowodnić, że brakuje wymaganego pola”. Minions Stripe’a, opisane przez Alistaira Graya w lutym 2026, pracują wobec „ponad trzech milionów” istniejących testów przez „najwyżej dwie rundy CI”, po których „odsyłamy gałąź do jej ludzkiego operatora do ręcznej kontroli”.

Wyrocznia to jedyna część systemu, której agent nigdy nie może napisać. Jej wybór jest zadaniem człowieka, a trzymanie jej poza zasięgiem agenta to ograniczenie projektowe. Jak to zrobić, pokazuje strona chroń wyrocznię.

Uprawnienia

To, co agent może uruchomić bez nadzoru, jest decyzją, o którą pyta każde narzędzie. Codex dokumentuje politykę zatwierdzeń określającą, „kiedy Codex musi cię zapytać, zanim wykona działanie (na przykład wyjdzie z sandboksa, użyje sieci albo uruchomi komendy spoza zaufanego zbioru)”. Tryb auto w Claude Code przepuszcza „wywołania narzędzi przez klasyfikator, który blokuje wszystko nieodwracalne, destrukcyjne albo wycelowane poza twoje środowisko”. Cursor dokumentuje do tego samego wyboru tryby uruchamiania (run modes).

Ustawienia domyślne nie są polityką. Od Claude Code v2.1.283 na kanale latest sesje interaktywne na obsługiwanych modelach startują w trybie auto, a claude -p startuje w trybie Manual; domyślna polityka zatwierdzeń Codeksa to on-request. Przebieg bez nadzoru o trzeciej w nocy dziedziczy to, co akurat obowiązuje, a to decyzja, którą ktoś podjął właśnie przez to, że jej nie podjął.

Decyzja, czego nie automatyzować

Tekst Lineara o Agent Interaction SDK (Leela Senthil Nathan, sierpień 2025) stawia zasadę wprost: „agenta nie da się pociągnąć do odpowiedzialności”. Produkt to wymusza: „zgłoszenia można przypisywać tylko ludziom, a agentom tylko delegować”, więc „zgłoszenie nadal ma przypisanego człowieka, kogoś odpowiedzialnego za wynik, ale ma też delegowanego agenta odpowiedzialnego za działanie”.

Odpowiedzialności się nie deleguje. Ktoś decyduje, co chodzi bez nadzoru, i za to odpowiada, a ta decyzja ma kształt: nazwana osoba na pętlę, spisany powód i data przeglądu. Pętle, które ranią zespoły, rzadko są tymi, które ktoś świadomie zautomatyzował. To te, które zostały bez nadzoru, bo nikt nie powiedział inaczej.

Zdecyduj, które pętle mogą działać bez nadzoru

Rozstrzygają to cztery pytania testu autonomii (autonomy ledger), opisane na stronie o fabrykach oprogramowania, zadawane dla każdej pętli osobno. Pętla to nazwany przepływ pracy, na przykład „aktualizacje zależności w serwisie płatności”, a nie całe repozytorium.

Nazwij wyrocznię, która rozstrzyga, że „zrobione”. „npm test i testy kontraktowe kończą się kodem 0” to wyrocznia. „Wygląda dobrze” nie.
Sprawdź, czy agent może edytować tę wyrocznię. Jeśli agent może zmienić testy, które oceniają jego pracę, wyrocznia jest sugestią. Obejmij testy review właścicieli kodu albo spraw, żeby rozstrzygające sprawdzenie było starsze niż zmiana.
Zmierz, ile trwa, zanim zła odpowiedź wypłynie. Sekundy w CI to zielone światło. Zgłoszenie klienta po trzech tygodniach to czerwone.
Określ zasięg rażenia. Odwracalny i ograniczony, jak zmiana tekstu za flagą, albo nieodwracalny, jak migracja schematu.
Zapisz odpowiedzi w rejestrze autonomii razem z właścicielem, powodem i datą przeglądu (szablon niżej). Pętla, która czysto przechodzi wszystkie cztery pytania, może działać bez nadzoru. Pętla, która oblewa pytanie 2 albo 3, zostaje pod nadzorem, niezależnie od tego, jak dobry jest harness.

Pięć klas pracy oblewa te pytania na tyle często, że warto nazwać je z góry:

Schemat, autoryzacja, cennik i migracje. Wyrocznią jest zachowanie na produkcji, informacja zwrotna przychodzi po dniach, a zasięg rażenia to klienci. Człowiek czyta diff za każdym razem.
Praca bez wyroczni działającej w CI. Typowy przypadek to refaktor architektoniczny: nic, co da się uruchomić, nie powie, że nowy kształt jest lepszy. Włóż wysiłek w plan, nie w automatyzację.
Praca, w której agent trzyma obie strony. Funkcja w dobrze pokrytym module wygląda bezpiecznie, dopóki nie zauważysz, że agent napisał i ją, i testy, które ją przepuszczają. Albo plan czyta człowiek, albo rozstrzygające sprawdzenie jest starsze niż zmiana.
Pętle z wolną informacją zwrotną. Jeśli zła odpowiedź wypływa dopiero wtedy, gdy zauważy ją człowiek, a nie gdy komenda kończy się kodem różnym od zera, pętla po cichu zbiera błędy.
Wszystko, co czyta tekst pisany przez kogoś z zewnątrz. Treści zgłoszeń, komentarze do pull requestów, ładunki webhooków, zescrapowane strony i poczta przychodząca to wejście kontrolowane przez atakującego. Agent bez nadzoru, z narzędziami i powierzchnią na prompt injection, jest ścieżką zdalnego wykonania kodu. Jeśli taka pętla musi działać, traktuj wejście jako dane i daj pętli najwęższy zbiór uprawnień w systemie; resztę omawia model zagrożeń dla agentów.

Zapisz decyzję w rejestrze autonomii

Rejestr autonomii (autonomy register) ma jeden wiersz na pętlę; kto nim zarządza, definiuje model operacyjny, a klasy ryzyka opisuje zarządzanie i autonomia. Wklej ten format wiersza do podręcznika zespołu i wypełnij jeden wiersz dla każdej pętli bez nadzoru:

AUTONOMY REGISTER ROW — one per loop

Loop:            dependency upgrades, services/payments
Ladder level:    4 (agent opens PR; human reads the evidence, not the diff)
Risk class:      medium
Oracle:          unit + contract suites in CI; lockfile audit
Oracle owner:    @payments-leads (CODEOWNERS on tests/ and contracts/)
Agent can edit
the oracle:      no — tests/ and contracts/ are denied to the agent identity
Feedback time:   under 15 minutes (CI)
Blast radius:    one service; revert is a single PR
Permission set:  workspace-write sandbox, registry network only, no prod secrets
Outside input:   none (reads the lockfile and advisories only)
Accountable:     @payments-tech-lead (one named person, not a team)
Reason:          120 upgrade PRs a quarter; CI catches the failures we have seen
Review by:       2026-12-31

Najważniejsza jest data przeglądu. Wiersz, którego data minęła, oznacza pętlę działającą na wygasłej decyzji, więc traktuj go jak wygasły certyfikat.

Zamień decyzję o uprawnieniach w konfigurację

Rejestr mówi, co pętla może robić; konfiguracja narzędzia to miejsce, w którym ta decyzja staje się prawdą. To nienadzorowane konfiguracje CI ze strony uprawnienia i sandboksy, sprawdzone na Claude Code 2.1.286 i Codex CLI 0.157.1 26 września 2026.

dontAsk odrzuca wszystko, co wymagałoby pytania, więc lista dozwolonych narzędzi jest całą polityką, a reguła Edit(/tests/**) trzyma wyrocznię poza zasięgiem agenta:

claude -p "Run the test suite and fix failing tests in src/. Do not edit tests." \
  --permission-mode dontAsk \
  --permission-prompts none \
  --settings '{"sandbox":{"enabled":true,"allowUnsandboxedCommands":false}}' \
  --allowedTools "Read" "Edit" "Bash(npm test)" "Bash(npm run lint)" \
  --disallowedTools "Edit(/tests/**)"

Dla sesji interaktywnych w trybie auto claude auto-mode config wypisuje efektywną konfigurację trybu auto jako JSON, więc możesz porównać zatwierdzoną politykę z tym, co faktycznie działa.

codex exec w wersji 0.157.1 nie ma własnego -a, więc flaga zatwierdzeń idzie przed podkomendą. Profil uprawnień :workspace (beta) pozwala pisać w katalogu roboczym i nie daje dostępu do sieci:

codex -a never exec -c 'default_permissions=":workspace"' \
  "Run the unit tests and fix failing tests in src/. Do not edit tests."

Nie łącz profilu uprawnień z --sandbox: OpenAI pisze, że te dwa systemy „ze sobą nie współdziałają”.

Cursor dokumentuje do tej samej decyzji tryby uruchamiania (run modes); ustaw je w edytorze zgodnie z wierszem rejestru. W przebiegach skryptowych opcje local.autoReview i local.sandboxOptions z @cursor/sdk zapisują tę postawę jawnie w kodzie. Pełny przykład jest na stronie uprawnienia i sandboksy.

Jak udowodnić, że decyzje człowieka nadal obowiązują?

W zespole na poziomie 4 nikt nie czyta każdego diffa, więc decyzje opisane wyżej potrzebują własnych dowodów. Uruchom te cztery sprawdzenia, a właściciel rejestru niech co kwartał je zatwierdza:

Sprawdzenie	Co zapala się na czerwono	Gdzie działa
Ochrona wyroczni	Pull request napisany przez agenta zmienia pliki w `tests/`, `evals/` albo konfigurację CI bez zatwierdzenia właściciela kodu	Ochrona gałęzi z opcją Require review from Code Owners
Dryf uprawnień	Plik ustawień, profil sandboksa albo allowlista zmienia się bez odpowiadającej zmiany w rejestrze	Review właścicieli kodu na `.claude/`, `.codex/` i `.cursor/`
Scalenia bez review	Rośnie udział pull requestów scalonych bez review w klasie ryzyka, która review wymaga	Cotygodniowe zapytanie do platformy Git, osobno dla każdej klasy ryzyka
Wygasłe decyzje	Minęła data przeglądu wiersza w rejestrze	Zaplanowane zadanie, które czyta rejestr

Scalenia bez review to sygnał wyprzedzający. Raport Faros AI „AI Engineering Report 2026” (kwiecień 2026, telemetria z 22 000 programistów) pokazał o 31,3% więcej pull requestów scalanych całkiem bez review. Nikt tego nie postanowił; stało się to samo, popołudnie po popołudniu, w pośpiechu. Co czytać zamiast diffa, opisuje strona dowody zamiast kodu.

Gotowe prompty, które utrzymują robotę przy człowieku

Read this repository and draft the architecture brief my agents must not
violate. Output four sections and nothing else.
Invariants: the boundaries, layering rules and dependency directions this
codebase actually enforces today. Cite a file for each one.
Earned exceptions: the places where the code breaks its own rule on purpose,
and the reason, from git history or comments.
Off limits: the modules where a change requires a human decision, with globs.
Open questions: the three architectural decisions that are currently implicit
and would be expensive to get wrong, phrased as questions for me to answer.
Do not propose refactors. Do not edit files.

Take the open issues in this backlog and sort them into three buckets using the
autonomy ledger: runs unattended, human reads the plan, human reads the diff.
For each issue, answer the four questions in one line each: what oracle decides
done; can the agent edit that oracle; how long until a wrong answer surfaces;
what the blast radius is. Then give the bucket and the single check that would
move it one bucket safer.
Flag separately any issue whose input includes text an outsider can write
(issue bodies from external reporters, webhook payloads, scraped content).
Output a table sorted by bucket. Do not start work on any of them.

Design the permission policy for unattended runs in this repository, for each of
the three tools I use (Claude Code, Codex, Cursor). For each tool state: the
mode an unattended run must use; the commands allowed without asking; the
commands that must always prompt or be blocked outright; the network domains
reachable; the paths writable and the paths read-only; and the secrets that must
not be present in the environment at all.
Derive every entry from what the repository actually needs. Read the package
scripts, CI config and any existing settings files first, and list, at the end,
every permission you granted that you could not justify from a file.
Do not edit any settings file; output the policy as a table.

Gdzie robota człowieka po cichu znika i jak ją odzyskać?

Recenzent zmienia się w zatwierdzającego. Zatwierdzenie przestaje być decyzją i staje się kliknięciem. Żeby to naprawić, spisz, które klasy ryzyka mogą być scalane na podstawie samych dowodów, dla pozostałych wymuś review w ochronie gałęzi i śledź udział scaleń bez review w każdej klasie.

Wyrocznia staje się specyfikacją. Kiedy testy są jedynym zapisem tego, co znaczy „poprawnie”, decyzje produktowe przenoszą się do fixture’ów, których nikt nie przegląda. Żeby to naprawić, trzymaj kryteria akceptacji w specyfikacji, przypisz każdemu sprawdzenie, które go dowodzi, i przeglądaj zmiany tego przypisania jak kod; zobacz pisanie specyfikacji na poziomie 4.

Odpowiedzialność dryfuje do narzędzia. „Agent to zrobił” nie jest odpowiedzią na przeglądzie incydentu. Żeby to naprawić, dopisz nazwaną osobę odpowiedzialną do każdego wiersza rejestru, zanim pętla znowu ruszy, tak jak Linear zostawia przypisanego człowieka.

Uprawnienia rozjeżdżają się dla wygody. Ktoś poszerza allowlistę, żeby odblokować jeden przebieg, i dziedziczy ją każdy następny. Żeby to naprawić, obejmij pliki ustawień review właścicieli kodu i traktuj każdą ich zmianę jak zmianę w rejestrze, z powodem.

Zrozumienie odchodzi ostatnie. Zdanie, które Karpathy cytuje z aprobatą w opublikowanym transkrypcie, jest ostrzeżeniem: „Myślenie możesz zlecić na zewnątrz, ale zrozumienia nie”. Zespół, który przestaje umieć wytłumaczyć własny system, stracił coś, czego nie pokaże żadna liczba o przepustowości. Żeby to naprawić, niech człowiek wyjaśnia każdą zmianę architektoniczną w opisie pull requesta, a osoby się przy tym zmieniają; które umiejętności ćwiczyć, opisuje warsztat i kariera.

Poziom 5 bywa mylony z celem. Ciemna fabryka Shapiro, w której „ludzie nie są ani potrzebni, ani mile widziani”, opisuje „garstkę ludzi” w zespołach mniejszych niż pięć osób. Sześć obowiązków powyżej opisuje poziom 4, na którym leżą opublikowane dowody.

Dokąd dalej z robotą człowieka

Przed tą stroną przeczytaj jedną mapę drabiny, żeby wiedzieć, gdzie stoi każda pętla. Potem przeczytaj dowody zamiast kodu, żeby wiedzieć, co zastępuje diff.

Dowody zamiast kodu Co czyta człowiek, kiedy nikt nie czyta każdego diffa.

Osąd człowieka na bramkach Cztery bramki, na których decyduje człowiek, przećwiczone na jednym zadaniu.

Zarządzanie i autonomia Klasy ryzyka, zabezpieczenia i bramki oraz szablon polityki autonomii.

Uprawnienia i sandboksy Konfiguracja w każdym narzędziu, która stoi za decyzją o uprawnieniach.

Poziom 5: prowadzisz fabrykę oprogramowania Sześć stanowisk i to, które z nich mogą działać bez nadzoru.

Stan inżynierii agentowej Udokumentowane dowody stojące za liczbami na tej stronie.

Najczęstsze pytania

Co zostaje przy człowieku, gdy kod piszą agenci?

Sześć obowiązków: smak, architektura, kierunek produktu, projekt ewaluacji i warunków stopu, wobec których pracują agenci, uprawnienia, z jakimi działają, oraz decyzja, które pętle nie mogą chodzić bez nadzoru. Każdy ma źródło zewnętrzne i brak żadnego z nich nie powoduje, że test nie przejdzie.

Jak zdecydować, czy pętla agenta może działać bez nadzoru?

Odpowiedz na piśmie, dla każdej pętli, na cztery pytania: jaka wyrocznia rozstrzyga, że zrobione, czy agent może ją edytować, ile trwa, zanim zła odpowiedź wypłynie, i jaki jest zasięg rażenia. Zapisz odpowiedzi, właściciela, powód i datę przeglądu w rejestrze autonomii.

Jaka praca nie powinna chodzić bez nadzoru?

Schemat, autoryzacja, cennik i migracje; praca bez wyroczni działającej w CI; praca, w której agent pisze i zmianę, i jej testy; pętle z wolną informacją zwrotną; oraz każda pętla czytająca tekst, który może napisać ktoś z zewnątrz.

Czy agent może odpowiadać za swój wynik?

Nie. Tekst Lineara z sierpnia 2025 stwierdza, że agenta nie da się pociągnąć do odpowiedzialności, a produkt zostawia przypisanego człowieka na każdym zgłoszeniu delegowanym agentowi. Odpowiedzialność zostaje przy nazwanej osobie, jednej na pętlę.