Poziom 1–2: kodowanie z asystą i w parze

Poziom 1 Wyjaśnienie Zaktualizowano 2026-09-26

Poziomy 1 i 2 drabiny autonomii to kodowanie z asystą i w parze: agent dostaje wydzielone zadania albo pisze większość zmiany, a programista czyta każdą linię przed commitem. Dan Shapiro szacuje, że na poziomie 2 jest 90% programistów „AI-native”. Wyjście z niego wymaga pliku kontekstu, bramki planu i jednej sprawdzonej pętli zadań.

Ta strona jest dla programistów, którzy codziennie używają Claude Code, Codeksa albo Cursora i w każdej sesji od nowa wpisują te same konwencje. Tech leadzi mogą użyć pięciopunktowego testu, żeby sprawdzić, gdzie stoi każde repozytorium. Agent jest włączony, diff jest mały, a praca wciąż wydaje się twoja. Nic się nie psuje, więc nic nie zmusza do zmiany, i dlatego tak niewielu z tego szczebla wychodzi.

Co daje ci zestaw na poziom 2

Pięciopunktowy test, który mówi, czy jesteś na poziomie 1, na poziomie 2, czy już wyżej.
Plik kontekstu wygenerowany z repozytorium, w którym każda komenda kończy się kodem 0.
Tryb planowania jako domyślna bramka: skonfigurowany w Claude Code, a w Codeksie i Cursorze stały nawyk przed każdą edycją.
Dwa prompty do skopiowania: jeden pisze plik kontekstu, drugi prowadzi zadanie do sprawdzonego warunku zakończenia.
Cztery powody, dla których wspinaczka grzęźnie, i sposób wyjścia z każdego.

Jak poziomy 1 i 2 wyglądają w dniu pracy?

Artykuł Shapiro „The Five Levels: from Spicy Autocomplete to the Dark Factory” (23 stycznia 2026) nazywa te dwa szczeble stażystą od kodu i juniorem. Różnica polega na tym, kto trzyma ważną robotę.

Na poziomie 1, słowami Shapiro: „ważne rzeczy piszesz sam, ale oddajesz stażyście AI konkretne, wydzielone zadania”. Regex, fixture do testu, skrypt migracyjny, komponent napisany już 20 razy. Kształt zmiany nadal należy do ciebie. Poziom 1, tak jak poziom 0 pod nim, leży na lżejszym końcu kodowania wspomaganego AI, czyli nadrzędnej nazwy dla każdego użycia AI przy pisaniu oprogramowania.

Poziom 2 oddaje pisanie i zatrzymuje czytanie. Agent przechodzi przez zadanie, a ty patrzysz i wyłapujesz zboczenie z kursu jeszcze w trakcie przebiegu, a nie dopiero w review. Na tej drabinie poziom 2 odpowiada programowaniu w parze z AI, wyrażeniu, które w 2021 roku spopularyzował GitHub Copilot. Shapiro opisuje ten szczebel jako miejsce, „gdzie mieszka dziś 90% programistów »AI-native«”, i dodaje ostrzeżenie warte zapamiętania: „poziom 2 i każdy następny dają poczucie, że skończyłeś. Ale nie skończyłeś”.

Pod nimi leży poziom 0, który dziś wybiera niewielu: „żaden znak nie trafia na dysk bez twojej zgody”.

To czytanie zabezpiecza poziom 2, a czyta się już rzadziej, niż zakłada większość zespołów. Ankieta Sonara wśród ponad 1100 zawodowych programistów, opublikowana 8 stycznia 2026, podaje: „96% programistów nie ufa w pełni kodowi wygenerowanemu przez AI, a tylko 48% zawsze go weryfikuje przed commitem”. Mniej więcej połowa ankietowanych nie zawsze wykonuje jedyne sprawdzenie, na którym opiera się poziom 2.

Czy jesteś na poziomie 2? Pięciopunktowy test

Agent dostaje całe zadania, nie podpowiedzi. Opisujesz wynik, na przykład dodanie stronicowania do endpointu zamówień, zamiast przyjmować końcówkę linii, którą właśnie pisałeś.
Jesteś przy całym przebiegu. Sesja jest rozmową, której pilnujesz, i zatrzymujesz ją, gdy zjeżdża z kursu.
Czytasz każdą linię przed commitem. Czytasz diff, nie podsumowanie, i zauważyłbyś przemianowaną zmienną.
Pamięcią agenta o projekcie jesteś ty. Konwencje, komendy i zakazane ścieżki wpisujesz od nowa w każdej sesji.
Nic nie działa, kiedy cię nie ma. Żadnego przebiegu z harmonogramu, żadnego drugiego agenta w drugim checkoucie i żadnego zadania, które samo otwiera pull request.

Pięć razy „tak” to poziom 2. Jeśli w punkcie 1 odpowiadasz „nie”, jesteś na poziomie 1. Punkty 4 i 5 trzymają cię na tym szczeblu, a punkt 4 da się naprawić od ręki: to krok 1 poniżej.

Jak przygotować repozytorium do wyjścia z poziomu 2?

Trzy zmiany, w tej kolejności. Żadna nie jest nowym narzędziem i każda daje coś, co da się sprawdzić.

Krok 1: daj agentowi plik kontekstu, który wczytuje w każdej sesji

Plik kontekstu zamyka punkt 4 testu: przestajesz być pamięcią agenta. Wygeneruj go z repozytorium, a nie z pamięci, i trzymaj w nim tylko to, co jest prawdą dziś: komendy, które muszą przejść, układ katalogów, konwencje egzekwowane w review i ścieżki, których agent nie może ruszać. Zasady warstw i to, co trafia do którego pliku, opisuje strona o warstwowym kontekście w CLAUDE.md i AGENTS.md.

Uruchom /init w repozytorium, żeby wygenerować startowy CLAUDE.md, a potem /memory, żeby go edytować i włączyć lub wyłączyć auto memory. Claude Code czyta też AGENTS.md, gdy projekt nie ma CLAUDE.md: od v2.1.277 w sesjach first-party i od v2.1.281 na Bedrocku, Google Cloud i Microsoft Foundry, na dzień 26 września 2026 w obu przypadkach tylko w kanale wydań latest. Zespół, który dzieli plik z Codeksem, może więc trzymać jeden AGENTS.md.

Uruchom /init w prompcie Codeksa, żeby utworzyć plik AGENTS.md. Codex „czyta pliki AGENTS.md, zanim weźmie się do jakiejkolwiek pracy” (dokumentacja Codeksa od OpenAI, sprawdzone 28 sierpnia 2026). Od codex-cli 0.150.0 niezaufany projekt nie dostarcza instrukcji AGENTS.md na poziomie projektu, więc dopóki nie zaufasz repozytorium, plik jest po cichu pomijany. Zaakceptuj pytanie o zaufanie, które Codex wyświetla przy pierwszym otwarciu repozytorium; ustawienie zaufania opisuje szybki start Codeksa.

Read this repository and write the context file you load every session
(CLAUDE.md for Claude Code, AGENTS.md for Codex, a project rule for Cursor).
Use only what is in the repo. Include:
- the package scripts that actually run, and roughly how long each one takes;
- the test, typecheck and lint commands;
- the directory layout, one line per top-level folder;
- the three conventions a new contributor gets wrong, found by reading the
  last 50 commits and their review comments;
- the paths an agent must never edit (generated files, migrations already
  applied, vendored code, secrets).
No aspirational rules, no generic advice, nothing you cannot point at a file
for. Finish with a "Verify before you finish" block listing the exact commands
that must exit 0. Then run each of those commands now and report the exit
code of each one. If any command fails, fix the file, not the repository.

Jak poznać, że zadziałało: każda komenda z bloku „Verify before you finish” kończy się kodem 0 na czystym checkoucie, a nowa sesja poprawnie odpowiada na pytanie „jak tu uruchomić testy?”, choć niczego jej nie podpowiadasz.

Krok 2: ustaw tryb planowania jako domyślną bramkę

Przeczytanie planu kosztuje znacznie mniej niż przeczytanie złego diffa. Tryb planowania każe agentowi zbadać kod i zaproponować zmianę, zanim cokolwiek edytuje, więc zły pomysł wyłapujesz, zanim powstanie kod.

Naciśnij Shift+Tab, żeby przejść do trybu planowania, albo poprzedź prompt komendą /plan. Żeby każda sesja terminalowa w tym projekcie startowała w trybie planowania, dodaj do .claude/settings.json:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Gdy plan jest gotowy, wybierz Yes, manually approve edits, jeśli chcesz zatwierdzać każdą edycję na bieżąco.

Od v2.1.283 (kanał latest) wbudowanym trybem startowym interaktywnych sesji w terminalu i VS Code na każdym planie i u każdego dostawcy jest auto mode (na planach Pro, Max i Team od 14 sierpnia 2026). claude -p, sesje, których ustawienia zawierają disableAutoMode, oraz modele nieobsługiwane przez auto mode startują w trybie Manual. defaultMode w ustawieniach, jak plan powyżej, zastępuje wbudowany start. W auto mode każdą akcję ocenia klasyfikator, nie ty. Na poziomie 2 to nie przeszkadza, dopóki czytasz diff przed commitem. Jeśli wolisz zatwierdzać każdą akcję, uruchom claude --permission-mode manual.

Wpisz /plan w prompcie Codeksa przed każdą zmianą dłuższą niż kilka linii. Żeby edycje zostały w repozytorium, a model pytał, zanim wyjdzie dalej, uruchom sesję tak:

codex --sandbox workspace-write --ask-for-approval on-request

Codex zapisuje zmiany w drzewie roboczym, więc twoje czytanie z poziomu 2 odbywa się przy git diff, przed commitem. Profile uprawnień i wybór sandboksa opisuje strona o uprawnieniach i sandboksach dla agentów.

Jak plan staje się kontraktem dla budowy, opisuje strona o etapie budowy w cyklu życia.

Krok 3: przeprowadź jedną klasę zadań od początku do końca z warunkiem zakończenia

Wybierz klasę zadań, którą powtarzasz: endpoint CRUD, migrację albo błąd z reprodukcją. Przeprowadź ją raz z plikiem kontekstu i trybem planowania, a kryteria akceptacji zapisz, zanim agent zacznie. Praca agenta kończy się na warunku zakończenia, który sam potrafi sprawdzić, a nie wtedy, gdy ogłosi, że skończył. Tę sprawdzoną ścieżkę oddasz później agentowi, którego nie pilnujesz.

Task: add cursor-based pagination to GET /orders (query params: limit, cursor;
default limit 50, max 200).

Before you edit anything, write a plan that lists:
1. every file you will change and why;
2. the acceptance criteria as testable statements, including limit=0,
   limit=201, an invalid cursor, and the last page;
3. the tests you will add for each criterion.
Stop and wait for my approval of the plan.

After approval, implement it. You are done only when:
- each acceptance criterion has a test that fails without your change and
  passes with it (show me both runs);
- the test, typecheck and lint commands in the context file all exit 0;
- you have not edited any existing test, fixture or CI file.
Finish with a short evidence summary: criterion -> test name -> result, plus
anything you were unsure about. Do not summarise the diff.

Jak sprawdzić pracę agenta bez czytania każdej linii?

Na poziomie 2 nadal czytasz każdą linię, bo tak ten szczebel jest zdefiniowany. Tę samą troskę o kod zachowuje kodowanie rozszerzone Kenta Becka, gdy pisze agent. Sens zestawu polega na tym, żeby obok czytania zbudować sprawdzenia, które zastąpią je na następnym poziomie. Traktuj każdy przebieg jako próbę tych sprawdzeń:

Sprawdzenie	Skąd się bierze	Czego dowodzi
Bramka z komend	Blok „Verify before you finish” w pliku kontekstu	Zmiana się buduje, przechodzi typy i istniejące testy
Testy akceptacyjne	Kryteria zapisane w planie, przed kodem	Nowe zachowanie istnieje, a test mógł nie przejść
Chroniona wyrocznia	„Nie edytuj istniejących testów” w prompcie	Agent nie ułatwił sobie przejścia sprawdzenia
Podsumowanie dowodów	Ostatnie linie przebiegu agenta	Które kryterium odpowiada któremu zielonemu testowi

Potem porównaj dowody z własną lekturą diffa. Za każdym razem, gdy czytanie znajdzie problem, który sprawdzenia przepuściły, dodaj na niego sprawdzenie. Gdy klasa zadań przechodzi kilka przebiegów, a twoje czytanie nic nie dokłada, jest gotowa na poziom 3, na którym praca agenta dociera do ciebie jako diff, którego powstawania nie oglądałeś. Na poziomie 2 nadal ty zatwierdzasz każdy commit; sprawdzenia dopiero zapracowują na to, żeby później przejąć tę rolę. Co czyta człowiek, gdy diff przestaje być jednostką review, opisuje strona o czytaniu dowodów zamiast kodu.

Dlaczego wspinaczka z poziomu 2 grzęźnie i jak z tego wyjść

Co tech lead sprawdza w zespole na poziomie 2?

Zespół nie jest na jednym poziomie; na poziomie jest każda powtarzalna pętla. W każdym repozytorium sprawdź trzy rzeczy: czy plik kontekstu jest zacommitowany, a jego komendy przechodzą w CI; czy tryb planowania jest skonfigurowany jako domyślny; czy co najmniej jedna klasa zadań ma spisane kryteria akceptacji i warunek zakończenia. Repozytorium, które spełnia wszystkie trzy, jest gotowe na pierwszą pętlę bez nadzoru. Zespoły i pętle na jednej siatce pokazuje strona z jedną mapą drabiny, cyklu życia i stacji fabryki.

Dokąd dalej z poziomu 2

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

Czytanie dowodów zamiast kodu Co czyta człowiek, gdy diff przestaje być jednostką review.

Ścieżka dewelopera Kolejność lektury od tego szczebla do agentów bez nadzoru.

Drabina autonomii Wszystkie sześć poziomów i test, który umieszcza każdą twoją pętlę.

Claude Code: szybki start Konfiguracja, MCP i praca w terminalu.

Codex: szybki start Konfiguracja w aplikacji, CLI, IDE i chmurze.

Cursor: szybki start Rules, MCP i wybór modelu w jednym podejściu.

Znajdź swój poziom Dwadzieścia pięć pytań, które umieszczą twoją pracę na drabinie.

Najczęstsze pytania

Czym jest poziom 2 na drabinie autonomii?

Poziom 2 to kodowanie w parze. Agent wykonuje całe zadania w jednej sesji, a programista obserwuje przebieg i czyta każdą linię przed commitem. Dan Shapiro nazywa go poziomem juniora i umieszcza na nim „90% programistów AI-native”.

Czym różni się poziom 1 od poziomu 2?

Tym, kto pisze ważny kod. Na poziomie 1 pisze go programista, a agentowi oddaje wydzielone zadania, takie jak regex, fixture czy skrypt migracyjny. Na poziomie 2 agent pisze większość zmiany, a programista zostawia sobie czytanie.

Jak przenieść repozytorium z poziomu 2 na poziom 3?

Trzy zmiany, w tej kolejności: plik kontekstu, który agent wczytuje w każdej sesji, wygenerowany z repozytorium i sprawdzony przez uruchomienie jego komend; tryb planowania jako domyślna bramka przed każdą edycją; jedna powtarzalna klasa zadań przeprowadzona od początku do końca z warunkiem zakończenia, który agent sprawdza sam.

Czy na poziomie 2 można przestać czytać każdą linię?

Tylko wtedy, gdy sprawdzanie przejmuje coś innego. Ankieta Sonara ze stycznia 2026 pokazała, że tylko 48% programistów zawsze weryfikuje kod wygenerowany przez AI przed commitem. Rezygnacja z czytania bez bramek z komend i spisanego podsumowania dowodów to poziom 2 bez kontroli, a nie poziom 3.