Drabina autonomii: na którym poziomie pracujesz?

Drabina autonomii to sześciopoziomowa skala Dana Shapiro, od poziomu 0 do 5, opisująca, ile kodu zespołu piszą agenci kodujący i ile z niego ludzie wciąż czytają. Każdy poziom opisuje jedną pętlę. Od poziomu 3 wzwyż pętla awansuje dopiero wtedy, gdy sygnał sprawdzany przez maszynę, na przykład polecenia kończące się kodem 0, zastępuje człowieka czytającego diff.

Twój zespół codziennie używa Claude Code, Codeksa albo Cursora, a mimo to każda zmiana czeka, aż ktoś przeczyta diff. Deweloper, tech lead, CTO i zarząd pytają „gdzie jesteśmy?” i każdy ma na myśli coś innego. Ta strona daje całej czwórce jedną skalę, test z pięciu pytań i poradnik do każdego szczebla.

Jak wygląda każdy poziom drabiny?

Poziom	Nazwa na tej stronie (nazwa Shapiro)	Kto pisze	Kto czyta	Słowami Shapiro
L0	Ręcznie (Spicy autocomplete)	Człowiek	Człowiek, każdy znak	„not a character hits the disk without your approval”
L1	Z asystą (The coding intern)	Głównie człowiek	Człowiek, wszystko	„you offload specific, discrete tasks to your AI intern”
L2	W parze (The junior developer)	Człowiek i agent, w parze	Człowiek, każdą linię	„feels like you are done. But you are not done”
L3	Menedżer review (The developer)	Agent, większość kodu	Człowiek jako recenzent na pełny etat	„Your life is diffs.”
L4	Menedżer specyfikacji (The engineering team)	Agent, na podstawie specyfikacji	Głównie testy	„leave for 12 hours, and check to see if the tests pass”
L5	Ciemna fabryka (The dark software factory)	Agent	Nikt	„It’s a black box that turns specs into software.”

Źródło: Dan Shapiro, „The Five Levels: from Spicy Autocomplete to the Dark Factory”, 23 stycznia 2026; nazwy poziomów w brzmieniu, które cytuje Simon Willison, 28 stycznia 2026. Krótkie nazwy pochodzą z tej strony.

Shapiro umieszcza 90% deweloperów „AI-native” na poziomie 2, pisze, że na poziomie 3 zatrzymuje się prawie każdy, a na poziomie 5 widzi tylko garstkę ludzi. Zobacz dowody stojące za drabiną, ze źródłem i datą.

Na którym szczeblu jest każda twoja pętla?

Pętla to powtarzalna klasa zmian z własnym wyzwalaczem, sprawdzeniem i warunkiem stopu: podbijanie zależności, naprawa niestabilnych testów, praca nad funkcjami w jednym serwisie. Odpowiadaj osobno dla każdej pętli, patrząc na repozytorium, z którego wysyłasz na produkcję. Pierwsze pytanie, na które nie odpowiesz „tak” z dowodem, wyznacza sufit tej pętli.

Z L0 na L1. Czy w tym tygodniu trafił na dysk kod, którego nie napisałeś?
Z L1 na L2. Czy oddajesz agentowi całe zadania z kryteriami akceptacji, a nie podpowiedzi wewnątrz funkcji, którą właśnie piszesz?
Z L2 na L3. Czy agent pracuje na tyle długo i na tyle często, że z jego pracą stykasz się dopiero jako z gotowym diffem?
Z L3 na L4. Czy masz warunek stopu, który ocenia maszyna, na przykład polecenia kończące się kodem 0, żeby odejść od przebiegu i sprawdzić wynik?
Z L4 na L5. Czy scalana jest jakakolwiek zmiana, której nie przeczytał człowiek, i umiesz nazwać wyrocznię, która to zabezpieczyła?

Dowód to artefakt: zadanie w CI, polecenie testowe, scalony pull request. Jedna mapa wymienia dowody, jakich wymaga każdy poziom na każdym etapie cyklu życia, i definiuje poziom zespołu jako rozkład jego scalonych zmian między poziomami pętli.

Read the last 30 days of git history, the CI configuration and the test commands in this repository. Group the merged changes into loops (repeatable classes of change, for example dependency bumps, bug fixes, feature work per service). For each loop, answer five questions with evidence: 1) does agent-written code reach disk, 2) does the agent receive whole tasks with acceptance criteria, 3) is its work first seen as a diff, 4) is there a stop condition a machine evaluates (name the exact command that must exit 0), 5) does anything merge unread and which check made that safe. The first question without evidence is the loop's level. Output a table: loop, level, the evidence (file path or command), and the one missing artifact that blocks the next level. Do not guess: write "no evidence" where you found none. Do not change any files.

Jak przenieść pętlę z poziomu 3 na poziom 4?

Na poziomie 3 wąskim gardłem staje się review; poziom 4 definiuje to, że możesz odejść. Przejście wymaga warunku stopu, który działa bez ciebie: poleceń, które agent musi doprowadzić do zielonego wyniku, zanim skończy.

Użyj /goal w sesji interaktywnej albo uruchom pętlę nieinteraktywnie w CI (tryb headless) przez claude -p "Bump dependencies until npm test exits 0" --output-format json --allowedTools "Edit Bash(npm install *) Bash(npm update *) Bash(npm test)" --disallowedTools "Edit(**/tests/**) Edit(**/*.test.*)", żeby zadanie mogło sparsować wynik. Przebiegi w trybie headless (claude -p) startują w trybie uprawnień Manual i odrzucają każde wywołanie wymagające zgody (edycja plików, polecenia powłoki), którego nie ma na liście dozwolonych; narzędzia tylko do odczytu, takie jak Read i Grep, działają nadal. Dlatego przyznaj dokładnie to, czego potrzebuje pętla: polecenia instalacji, które zmieniają zależności, i polecenie testów, które je sprawdza. Reguły odmowy są sprawdzane przed regułami zezwolenia, więc agent może edytować kod źródłowy, ale nie pliki testów, które są jego warunkiem stopu (Claude Code v2.1.283). Zobacz przebiegi sterowane celem z /goal.

Użyj /goal w interfejsie terminalowym albo codex -a never exec -s workspace-write -c sandbox_workspace_write.network_access=true --output-schema SCHEMA_FILE "Bump dependencies until npm test exits 0" w CI. SCHEMA_FILE to ścieżka do twojego JSON Schema. Flagi zatwierdzania idą przed podpoleceniem. -s workspace-write pozwala przebiegowi edytować kopię roboczą i uruchamiać polecenia warunku stopu, ale domyślnie blokuje sieć, więc bez nadpisania przez -c polecenie npm install nie dotrze do rejestru. --output-schema wymusza, żeby końcowa odpowiedź pasowała do JSON Schema, którą sprawdza twoje zadanie (Codex CLI 0.157.1). workspace-write daje prawo zapisu do całej kopii roboczej, łącznie z testami, więc zmieniony test wyłapuje dopiero opisane niżej sprawdzenie po stronie zadania CI.

Changelog Cursora opisuje /goal jako „Rolling out” od 19 sierpnia 2026 (sprawdzone 2026-08-28). Jeśli /goal nie dotarł jeszcze na twoje konto, uruchom pętlę jako Cloud Agenta i wymagaj, żeby sprawdzenie w CI przeszło, zanim ktokolwiek otworzy pull request.

Take the dependency-bump loop in this repository. Write its stop condition as a list of shell commands that must all exit 0 before the agent may stop: install from the lockfile, type check, lint, the full unit test suite, and a build. Run each command now and report which pass on the current main branch. For any command that fails on main, stop and tell me: the stop condition cannot be stronger than the baseline. Then list what these commands do not check (runtime behaviour, security advisories, breaking API changes) so I can decide what else a human must read.

Warunek stopu, który agent może edytować, na przykład test, który wolno mu przepisać, nie jest warunkiem stopu. Reguły odmowy dla ścieżek nie zamykają każdej drogi: agent nadal edytuje package.json, łącznie ze skryptem, który uruchamia npm test, a npm install wykonuje skrypty instalacyjne każdej nowej zależności. Dlatego po zakończeniu pracy agenta zadanie CI samo ponownie uruchamia polecenia warunku stopu, kończy się błędem, jeśli diff dotyka pliku testów albo skryptu test, i działa na jednorazowym runnerze bez sekretów wdrożeniowych w środowisku. Czytanie dowodów zamiast kodu opisuje, co człowiek czyta zamiast diffa i które zmiany (uwierzytelnianie, pieniądze, migracje schematu) nadal czyta się linia po linii. Awans pętli zatwierdza tech lead, który jest jej właścicielem, i zapisuje w rejestrze pętli polecenia warunku stopu oraz odrzucone w ostatnim miesiącu diffy, które te polecenia by wyłapały.

Jakie błędy popełnia się, oceniając pętlę na drabinie?

Jeden poziom dla całego zespołu. Uśrednianie ukrywa pętle gotowe do awansu. Jak to naprawić: prowadź rejestr z jednym wierszem na pętlę, jak w jednej mapie.
Poziom deklarowany z pewności siebie. Pętla „na poziomie 4”, której warunkiem stopu jest „wygląda dobrze”, jest na poziomie 3. Jak to naprawić: nazwij polecenie; jeśli nie potrafisz, zdegraduj pętlę.
Przeskoczenie poziomu 3. Scalanie bez czytania, zanim poznasz typowe błędy agenta, kończy się incydentami. Jak to naprawić: zostań przy review, dopóki twoje sprawdzenia nie wyłapałyby diffów odrzuconych w zeszłym miesiącu.
Mieszanie innych modeli dojrzałości. Poziomy L1–L5 w AIDEs od JetBrains i pięć etapów Every definiują poziomy inaczej. Jak to naprawić: nie nakładaj ich na drabinę.

Dokąd dalej na drabinie autonomii

Idź swoją ścieżką (dewelopera, tech leada, CTO, zarządu) albo przejdź do szczebla swojej pętli.

Jedna mapa: drabina, cykl życia i stanowiska Dowody, jakich wymaga każdy poziom na każdym etapie, i jak raportować poziom zespołu.

Poziom 1–2: kodowanie z asystą i w parze Konfiguracja w każdym narzędziu, która prowadzi repozytorium od podpowiedzi do zlecanych zadań.

Poziom 3: przeglądasz diffy Równolegli agenci, automatyzacja review i sufit review.

Poziom 4: piszesz specyfikacje Tryb planowania, przebiegi sterowane celem, hooki i warunki stopu, dzięki którym można odejść.

Poziom 5: prowadzisz fabrykę oprogramowania Sześć stanowisk fabryki zestawionych z tym, co dokumentują Claude Code, Codex i Cursor.

Czytanie dowodów zamiast kodu Co człowiek czyta zamiast diffa i kiedy ktoś nadal czyta kod.

Co zostaje człowiekowi w inżynierii agentowej Smak, architektura, kierunek, warunki stopu, uprawnienia i to, czego nie automatyzować.

Twój warsztat i kariera, gdy kod piszą agenci Które umiejętności procentują, które zanikają, i plan na każdy szczebel.

Najczęstsze pytania

Czym jest drabina autonomii?

Drabina autonomii to sześciopoziomowa skala Dana Shapiro, od poziomu 0 do poziomu 5, opisująca, ile kodu zespołu piszą agenci kodujący i ile z niego ludzie wciąż czytają. Biegnie od autouzupełniania, które wymaga zgody na każdy znak, przez wydzielone zadania, pracę w parze i czytanie każdego diffa, po pisanie specyfikacji ze sprawdzaniem testów i ciemną fabrykę, w której nikt nie czyta kodu.

Na którym poziomie jest większość deweloperów?

Na poziomie 2 i 3. Według Shapiro na poziomie 2 pracuje dziś 90% deweloperów „AI-native”, a na poziomie 3 zatrzymuje się prawie każdy. Ostrzega, że poziom 2 i każdy następny dają poczucie, że skończyłeś, choć wcale nie skończyłeś.

Czy zespół ma jeden poziom?

Nie. Poziom należy do pętli, czyli powtarzalnej klasy zmian z własnym wyzwalaczem, sprawdzeniem i warunkiem stopu. Pętla podbijania zależności może działać na poziomie 4, a praca nad funkcjami w tym samym repozytorium na poziomie 2.

Co zmienia się na poziomie 4?

To, co czyta człowiek. Poniżej poziomu 4 człowiek czyta każdy diff. Na poziomie 4 deweloper pisze specyfikację i warunek stopu, który ocenia maszyna, agent pracuje bez nadzoru, a człowiek czyta dowody: czy testy przeszły i co sprawdzały.

Czy poziom 5 istnieje naprawdę?

Shapiro umieszcza na poziomie 5 tylko garstkę ludzi w zespołach liczących mniej niż pięć osób, a notatka Simona Willisona wskazuje jeden z nich: dział AI w StrongDM. To rzadkość. Na poziomie 5 według Shapiro nikt nie czyta kodu; to, że da się tak pracować bezpiecznie, zależy od siły weryfikacji wokół niego (zobacz Poziom 5: prowadzisz fabrykę oprogramowania).