Jedna mapa: drabina autonomii, cykl życia i stacje fabryki

Jedna mapa łączy trzy osie w jednej siatce. Dojrzałość to drabina autonomii, od poziomu 0 do poziomu 5, mierzona dla każdej pętli osobno. Proces to sześć etapów cyklu życia, od planu (plan) do utrzymania (maintain). Możliwości to sześć stacji fabryki, od intencji do wydania. Każda komórka wskazuje dowody, które pętla musi wytworzyć, zanim wolno jej działać na danym poziomie.

Twoja mapa wdrożenia mówi „fala 3”, scorecard CTO mówi „poziom 2”, prezentacja dostawcy mówi „w okolicach L3”, a przewodnik compound engineering mówi „etap 2”. A potem zarząd pyta: na jakim poziomie jesteśmy? Cztery liczby, cztery definicje i żadna nie mówi, która praca może się zmergować bez czytania jej przez człowieka. Ta strona je uzgadnia: jeden słownik dla dojrzałości, procesu i możliwości oraz mapa z każdego starszego schematu w tym serwisie z powrotem do niego.

Co jedna mapa rozstrzyga dla każdego czytelnika

• Programista: jakie dowody twoja pętla musi wytworzyć na każdym etapie, zanim przestaniesz czytać jej diffy.
• Tech lead: rejestr pętli do skopiowania i reguła awansowania albo degradowania pętli na podstawie dowodów, a nie pewności siebie.
• CTO: definicja metryki poziomu zespołu i organizacji, której nie da się uśrednić do liczby na pokaz, oraz klasy ryzyka, które stoją obok poziomów, a nie w ich środku.
• Zarząd: jedno zdanie do raportowania wyżej („udział zmergowanych zmian wytworzonych na poziomie 4 lub wyższym, razem z ich wskaźnikiem awarii”) i lista zewnętrznych modeli, które nie są tym samym.

Jakie są trzy osie jednej mapy?

Każda oś odpowiada na inne pytanie inną jednostką, a pomylenie jednostek zaczyna większość sporów o dojrzałość.

Oś	Na jakie pytanie odpowiada	Wartości	Czego dotyczy	Strona kanoniczna
Dojrzałość	Kto czyta co, zanim zmiana się zmerguje?	L0 Ręcznie · L1 Z pomocą · L2 W parze · L3 Menedżer review · L4 Menedżer specyfikacji · L5 Ciemna fabryka	Jednej pętli	Drabina autonomii
Proces	Na jakim etapie życia zmiany jesteśmy?	Plan · design · build · test · deploy · maintain	Jednego etapu cyklu życia	AI-native cykl życia
Możliwości	Jaka maszyneria pozwala przejść ten etap bez człowieka?	Intencja · harness · pętla · graf · weryfikacja · wydanie	Jednej stacji fabryki	Poziom 5: sześć stacji

Pętla to powtarzalna klasa zmian z własnym wyzwalaczem, wyrocznią i warunkiem stopu: podbicia zależności, naprawa niestabilnych testów, praca nad funkcjami w serwisie checkout, migracje schematu. Poziom należy do pętli, nie do firmy: pętla podbijania zależności z deterministycznym sprawdzeniem może działać na poziomie 4, podczas gdy praca nad funkcjami obok niej jest na poziomie 2, i obie odpowiedzi są jednocześnie prawdziwe.

Sześć poziomów drabiny pochodzi od Dana Shapiro, „The Five Levels: from Spicy Autocomplete to the Dark Factory” (styczeń 2026); krótkie nazwy pochodzą od tego serwisu. Shapiro umieszcza większość programistów AI-native na poziomie 2 i pisze, że prawie wszyscy zatrzymują się na poziomie 3. Dlatego w większości zespołów większość komórek poniższej siatki leży w tych dwóch kolumnach.

Gdzie pasuje dziewięć węzłów zadań?

Drzewa narzędzi (Claude Code, Codex, Cursor) są zorganizowane według dziewięciu węzłów zadań. To nawigacja, a nie czwarta oś, i każdy węzeł da się przypisać do osi procesu i możliwości:

Węzeł zadań w drzewach narzędzi	Etap cyklu życia	Stacje, które głównie opisuje
Quick start	Konfiguracja, przed cyklem życia	Intencja, harness
Plan	Plan, design	Intencja
Build	Build	Harness, pętla, graf
Test	Test	Weryfikacja
Ship	Deploy	Weryfikacja, wydanie
Operate	Maintain	Pętla, wydanie
Automate	Od build do maintain	Pętla, graf, wydanie
Team	Przekrojowo (wspólne reguły i ludzie)	Intencja
Reference	Brak	Brak

Siatka: jakich dowodów wymaga każdy poziom na każdym etapie?

Wiersze to etapy cyklu życia; każdy wiersz wskazuje stacje, które wytwarzają jego dowody. Kolumny to poziomy drabiny. Komórka to dowód, który musi istnieć, a od poziomu L4 wzwyż musi go wytworzyć maszyna, zanim pętla może twierdzić, że działa na tym poziomie na tym etapie. L0 i L1 pominięto: tam dowodem jest człowiek, który napisał lub zaakceptował każdą linię.

Etap (stacje)	L2 W parze	L3 Menedżer review	L4 Menedżer specyfikacji	L5 Ciemna fabryka
Plan (intencja)	Intencja żyje w prompcie i w głowie programisty	Spisane zadanie z kryteriami akceptacji w zgłoszeniu	Zacommitowany intent.md albo specyfikacja z kryteriami akceptacji sprawdzalnymi maszynowo, zaakceptowana przez wskazanego właściciela przed uruchomieniem	Intencje przychodzą z kolejki (tracker, alert, incydent) i każda niesie własną wyrocznię; właściciel podpisuje intencję, nie kod
Design (intencja, graf)	Ustalany na żywo w sesji	Plan przejrzany w trybie planowania przed startem implementacji	Zacommitowane spec.md i plan.md; ograniczenia architektury zapisane jako reguły albo fitness functions, których agent nie może edytować	Dekompozycja działa jako wersjonowany workflow; zmiana designu poza uzgodnionymi ramami eskaluje do człowieka
Build (harness, pętla, graf)	Człowiek śledzi każdą edycję i odpowiada na prośby o uprawnienia	Agent pracuje bez nadzoru w worktree albo sandboksie; dowodem jest diff plus lokalny przebieg testów	Jawny tryb uprawnień i sandbox dla danego typu przebiegu, warunek stopu oceniany przez maszynę i limit ponowień	Przebiegi wyzwalane zdarzeniami, bez próśb o zatwierdzenie; konfiguracja harnessu jest wersjonowana i przeglądana jak kod
Test (weryfikacja)	Testy, które człowiek pisze albo czyta	CI jest zielone, a człowiek czyta diff razem z testami	Wyrocznia poza zasięgiem agenta (chronione testy, testy akceptacyjne ze specyfikacji) i pakiet dowodów dołączony do pull requesta	Siła wyroczni jest mierzona, a nie zakładana; liczba rund CI jest ograniczona; sama fabryka ma evale
Deploy (weryfikacja, wydanie)	Człowiek merguje to, co napisał razem z agentem	Człowiek zatwierdza merge po przeczytaniu każdego diffa	Decyzja o merge opiera się na pakiecie dowodów i klasie ryzyka; kod czyta się tylko w klasach, które tego wymagają	Klasy niskiego ryzyka mergują się automatycznie według reguły; progressive delivery z automatycznym rollbackiem po przekroczeniu progu SLO
Maintain (pętla, wydanie)	Ludzie obserwują produkcję	Agent robi triage na żądanie; poprawkę prowadzi człowiek	Przebiegi planowe albo wyzwalane zdarzeniami otwierają pull requesty z alertów, z sygnałami z produkcji w dowodach	Naruszenie pasma kontrolnego zapisuje następną intencję, a każdy incydent dodaje przypadek do wyroczni

Czytaj siatkę wierszami, nie kolumnami. Pętla jest na najniższym poziomie, który obsługuje którykolwiek z jej etapów. Pętla z wierszem testu na L4 i wierszem deployu na L3 jest pętlą L3, bo człowiek nadal czyta każdy diff przed merge.

Strony kanoniczne dla komórek to dowody zamiast kodu (co czyta człowiek na L4), pakiet dowodów (co musi nieść pull request), siła wyroczni (jak mocny jest wiersz testu) i progressive delivery (wiersz deployu na L5).

Jak ocenić zespół albo organizację?

Zespół nie ma poziomu. Ma rozkład: udział zmergowanych zmian wytworzonych przez pętle na każdym poziomie. Przyjmij tę definicję w takiej postaci.

Pole	Definicja
Jednostka	Jeden zmergowany pull request (albo zestaw zmian), oznaczony pętlą, która go wytworzyła
Poziom zmiany	Poziom, na którym była pętla w dniu merge, ustalony testem dowodów z następnej sekcji, a nie deklaracją
Okno	Kroczące 30 dni dla zespołów; kwartał dla organizacji
Poziom zespołu	Udział zmergowanych zmian na L0–L2, L3, L4 i L5 w oknie
Poziom organizacji	Ten sam rozkład dla wszystkich zespołów plus liczba pętli na L4 lub wyżej
Sparowana miara stabilności	Change failure rate (albo odsetek revertów) dla każdego poziomu, w tym samym oknie
Zakazane	Uśrednianie poziomów do jednej liczby („poziom 3,4”) albo raportowanie najlepszej pętli jako poziomu zespołu

Sparowana miara stabilności nie jest opcjonalna. Raport DORA 2025 (Nathen Harvey i Derek DeBellis, Google Cloud, 23 września 2025) stwierdził „a positive relationship between AI adoption on both software delivery throughput and product performance” i jednym tchem dodał: „However, AI adoption does continue to have a negative relationship with software delivery stability.” Rozkład, który przesuwa się w prawo, podczas gdy awarii przybywa, nie jest postępem.

Przykładowy zespół, ilustracyjny, nie zmierzony:

Pętla	Poziom	Zmergowane PR, 30 dni	Udział
Podbicia zależności	L4	60	30%
Naprawa niestabilnych testów	L4	20	10%
Funkcje w checkout	L3	84	42%
Migracje schematu (klasa krytyczna, zawsze czytane)	L3	12	6%
Integracja z dostawcą płatności	L2	24	12%

Zdanie do raportu brzmi: „Checkout: 40% zmergowanych zmian na L4, 48% na L3, 12% na L2, obok change failure rate dla każdego poziomu”. Zespół nie jest „na poziomie 3”. Prowadzi dwie pętle L4, a następna decyzja o awansie dotyczy jednej nazwanej pętli, nie zespołu.

Policz rozkład ze zmergowanych pull requestów

Wyeksportuj zmergowane pull requesty z ostatnich 30 dni za pomocą GitHub CLI, w terminalu, z katalogu głównego repozytorium:

# GNU date (Linux); na macOS użyj: date -v-30d +%F
SINCE=$(date -d '30 days ago' +%F)
gh pr list --state merged --search "merged:>=$SINCE" --limit 1000 \
  --json number,title,labels,author,headRefName,files,commits,reviews,mergedBy,mergedAt,body > merged-prs.json

# Odchudź eksport: surowy plik to jedna linia JSON, często kilka MB, której
# narzędzie do czytania plików nie przewinie fragmentami.
jq '[.[] | {number,title,labels:[.labels[].name],author:.author.login,branch:.headRefName,
  files:[.files[].path],commits:[.commits[]|{headline:.messageHeadline,body:.messageBody,
  authors:[.authors[]|{login,name}]}],reviews:[.reviews[]|{author:.author.login,state}],
  mergedBy:.mergedBy.login,body}]' merged-prs.json > prs-slim.json

Zapisz poniższy prompt jako prompts/level-distribution.txt i uruchom go w trybie tylko do odczytu w swoim narzędziu. --tools "Read" usuwa wszystkie pozostałe narzędzia Claude Code; w Codeksie profil uprawnień :read-only (beta) zastępuje starszą flagę --sandbox i nie wolno łączyć obu mechanizmów:

Claude Code

claude -p "$(cat prompts/level-distribution.txt)" --tools "Read" > level-distribution.md

Codex

codex exec -c default_permissions=":read-only" -o level-distribution.md "$(cat prompts/level-distribution.txt)"

Cursor

Otwórz czat agenta w repozytorium, dołącz prs-slim.json i wklej prompt. Zadanie nie wymaga poleceń w terminalu ani edycji, więc odrzuć każdą, którą zaproponuje agent, a odpowiedź zapisz jako level-distribution.md.

Prompt do skopiowania: rozkład poziomów zmergowanych zmian

Read prs-slim.json (GitHub pull requests merged in the last 30 days) and
loops.yaml if it exists. Assign every PR to a loop: a repeatable class of
change such as dependency bumps, flaky-test repair, feature work in one
service, or schema migrations. Use loops.yaml names where they fit and
propose new loop names where they do not.

Classify each PR first by what a human read before merge, and use
authorship only as a tiebreak. Use only evidence in the JSON, never the
title's claims. Treat a PR as agent-authored when its commits carry an agent
Co-authored-by trailer (Claude, Codex, Cursor), its author is a bot or agent
account, or its branch has an agent prefix.
- L0-L2: a human authored the change without agent co-authorship. Report
  L0, L1 and L2 together as one bucket.
- L3: agent-authored, and a human approved after reviewing the diff, with no
  evidence bundle in the body.
- L4: agent-authored, the body carries an evidence bundle (spec link,
  acceptance results, test output), and no test or CI files changed unless
  a code owner approved.
- L5: merged by automation with no human approval.
Mark every PR whose files touch auth, payments, schema migrations, secrets,
CI configuration or tests as risk class high or critical.

Output: a table of loops with level, merged count and share; the team
distribution by level; the PRs you could not classify and why; the PRs where
authorship and review evidence disagree (for example, a human author with an
evidence bundle); and every PR labelled L4 or L5 that changed its own tests
or CI files. If authorship
cannot be determined, list the PR as unclassified rather than guessing.

Dlaczego klasa ryzyka nie jest poziomem dojrzałości?

Poziom opisuje pętlę. Klasa ryzyka opisuje pojedynczą zmianę. Odpowiadają na różne pytania, a ich pomieszanie daje najgorszą awarię opisaną na tej stronie: „jesteśmy na poziomie 4, więc agent może zmergować zmianę w uwierzytelnianiu”.

Klasa ryzyka	Typowe zmiany	Czy może się zmergować na samych dowodach?	Kto podpisuje
Niska	Dokumentacja, teksty, narzędzia wewnętrzne, podbicia zależności w wersji patch z zielonymi testami kontraktowymi	Tak, w pętlach L4; według reguły w pętlach L5	Właściciel pętli, przez regułę
Średnia	Logika funkcji za flagą, zmiany wewnętrznego API	Tak, gdy człowiek przeczyta pakiet dowodów	Recenzent dowodów
Wysoka	Kontrakty publicznego API, zmiany modelu danych, ścieżki krytyczne dla wydajności, każda zmiana testów albo konfiguracji CI	Nie: dowody plus człowiek czytający wrażliwe ścieżki	Właściciel kodu
Krytyczna	Uwierzytelnianie, przepływ pieniędzy, migracje schematu na danych produkcyjnych, sekrety i uprawnienia, harness samego agenta	Nie: człowiek czyta kod, a wdrożenie wymaga osobnego zatwierdzenia	Wskazany właściciel i drugi zatwierdzający

Klasa ogranicza to, co poziom może zrobić z daną zmianą. Pętla L5, która otwiera pull request klasy krytycznej, eskaluje go dokładnie tak, jak zrobiłby to zespół na L2. Zmiany testów i CI są celowo w klasie wysokiej: to one są wyrocznią, a agent, który edytuje własną wyrocznię, zamienił sprawdzenie w sugestię. Polityka przypisywania klas jest opisana w governance i autonomii; lista zmian, przy których ktoś nadal czyta kod, jest w dowodach zamiast kodu.

Jak udowodnić, że pętla jest na deklarowanym poziomie?

Poziom to twierdzenie o dowodach, więc da się je sprawdzić bez czytania kodu. Przeprowadź ten audyt przed awansem pętli i potem raz na kwartał.

1. Wylosuj próbkę. Wybierz losowo 10 zmergowanych pull requestów z pętli z ostatniego okna.
2. Sprawdź dowody dla deklarowanego poziomu. Dla L3 każdy ma zatwierdzenie człowieka po przeglądzie diffa. Dla L4 każdy niesie pakiet dowodów, jego testy i pliki CI są nietknięte (albo zatwierdzone przez właściciela kodu), a przebieg zapisał warunek stopu. Dla L5 każdy zmergował się według reguły bez zatwierdzenia człowieka, a ścieżka rollbacku zadziałała co najmniej raz w ćwiczeniu.
3. Odpowiedz na cztery pytania rejestru autonomii z fabryk oprogramowania: jaka wyrocznia decyduje, że gotowe, czy agent może ją oszukać, po jakim czasie wychodzi zła odpowiedź i jaki jest zasięg szkód.
4. Porównaj stabilność. Change failure rate albo odsetek revertów pętli w oknie nie może być gorszy niż na poprzednim poziomie.
5. Zapisz werdykt w rejestrze pętli z datą i próbką, a awans niech podpisze tech lead.

Nieudane sprawdzenie degraduje pętlę; nie otwiera dyskusji. Awanse podpisuje tech lead, a CTO odpowiada za politykę klas ryzyka.

Artefakt, który czyni to powtarzalnym, to rejestr pętli, jeden plik na repozytorium:

# loops.yaml: one entry per repeatable class of change
- loop: dependency-bumps
  owner: platform-team
  trigger: Renovate pull request opened
  stages: [build, test, deploy]
  level: L4
  oracle: required CI jobs defined outside the paths the agent may write
  agent_can_edit_oracle: false
  time_to_surface_wrong_answer: minutes in CI, hours in canary
  blast_radius: one service, reversible by revert
  merge_on_evidence: [low]
  escalate_to_code_reading: [high, critical]
  last_audit: 2026-09-26, 10 of 10 PRs carried an evidence bundle
  next_transition:
    to: L5
    exit_criterion: auto-merge for the low class with canary rollback, 60 days without a loop-caused revert
- loop: checkout-feature-work
  owner: checkout-team
  trigger: ticket moved to Ready with acceptance criteria
  stages: [plan, design, build, test, deploy]
  level: L3
  oracle: unit and integration tests in the same repository (agent-editable)
  agent_can_edit_oracle: true
  merge_on_evidence: []
  next_transition:
    to: L4
    exit_criterion: acceptance tests generated from the spec and protected by CODEOWNERS; evidence bundle required by CI

Prompt do skopiowania: szkic rejestru pętli z historii repozytorium

Draft loops.yaml for this repository. Read the last 200 merged pull requests
(use the GitHub CLI if it is available, otherwise git log on the main branch),
CODEOWNERS, the CI configuration and any AGENTS.md or CLAUDE.md.

Group the changes into 4 to 8 loops, each a repeatable class of change with
its own trigger. For every loop fill in: owner, trigger, lifecycle stages it
covers (plan, design, build, test, deploy, maintain), the current level on the
autonomy ladder (L2 to L5) judged only by what a human read before merge, the
oracle that decides done, whether an agent can edit that oracle, time until a
wrong answer surfaces, blast radius, and the risk classes (low, medium, high,
critical) that may merge on evidence alone.

Do not promote any loop above what the evidence shows. For each loop, name
the single missing piece of evidence that blocks the next level, as an exit
criterion a script could check. Do not edit any file except loops.yaml.

Które starsze schematy zastępuje jedna mapa?

Ten serwis prowadził kiedyś kilka systemów numeracji obok siebie. Zostały wycofane i każdy wraca do jednej osi mapy. Jeśli trafisz na któryś w starej zakładce albo w wewnętrznej prezentacji, przetłumacz go tą tabelą.

Wycofany schemat	Co opisywał	Co go zastępuje	Gdzie o tym czytać
Fale 0–5	Wdrożenie w repozytorium w stałych falach	Przejścia po drabinie, jedna pętla naraz	Mapa wdrożenia
Tygodnie 1–8, „Miesiąc 2+”	Kalendarz nauki programisty	Kroki ścieżki z kryteriami wyjścia	Ścieżka dewelopera
Tygodnie 1–12, „Miesiąc 4+”, „Phased Enterprise Rollout”	Kalendarz wdrożenia w organizacji	Bramki stop/go zapisane jako przejścia po drabinie dla każdej pętli	Mapa drogi dla organizacji
Adoption Curve, Phase 0, modele według wielkości organizacji	Kto wdraża pierwszy i w jakiej kolejności	Przejścia po drabinie plus zaprojektowany pilotaż	Projekt pilotażu
Fazy 1–4	Lista kontrolna migracji narzędzia	Nienumerowane kroki migracji	Przewodnik migracji
„Tier 2 / Tier 3”	Agenci równolegli, potem przebiegi nocne	L3 (agenci równolegli, człowiek czyta każdy diff) oraz L4–L5 (przebiegi bez nadzoru)	Równoległość w zespole
„Reactive → Strategic Leader”	Etykiety dojrzałości przywództwa	Przedziały poziomów 1–4, które faktycznie liczy scorecard CTO: Z pomocą, W parze, Menedżer review, Menedżer specyfikacji	Przewodnik po scorecardzie CTO
Drabina etapów Every (etapy 0–5) jako druga drabina	Ścieżka wdrożenia jednej osoby	Drabina, dla każdej pętli; etapy Every pozostają własnym modelem Every (patrz niżej)	Compound engineering
„Risk tiers 0–3”	Jak niebezpieczna jest zmiana	Klasy ryzyka: niska, średnia, wysoka, krytyczna	Governance i autonomia

Przedział ze scorecardu CTO to samoocena praktyk (narzędzia, review, governance), a nie rozkład poziomów zmergowanych zmian. Nigdy nie raportuj go jako „naszego poziomu”; podawaj go osobno od rozkładu.

Wzorzec za tą tabelą: data nie jest dowodem, a miara niebezpieczeństwa nie jest miarą dojrzałości.

Inne modele dojrzałości, na które trafisz

Te modele krążą w branży i warto je znać. Żaden z nich nie jest drabiną autonomii i serwis nie mapuje ich na nią. Używaj każdego do tego, co faktycznie mierzy.

• JetBrains AIDEs Framework (blog JetBrains Research, wrzesień 2026; źródło z drugiej ręki: streszczenie z wyciągu wyszukiwarki, nie oryginalny wpis). Pięć poziomów delegowania, od L1 „Tool” do L5 „Competence Center”, w 35 czynnościach SDLC. „L3” w AIDEs to nie poziom 3 drabiny, więc nigdy nie przenoś twierdzenia w rodzaju „narzędzie X jest w okolicach L3” z jednego modelu do drugiego.
• Drabina etapów Every (przewodnik compound engineering firmy Every Inc. na every.to; Kieran Klaassen przedstawił metodę w sierpniu 2025). Etapy od 0 do 5 opisujące, jak zmienia się sposób pracy jednej osoby, od pisania każdej linii po kierowanie równoległymi agentami w chmurze. Strona o compound engineering omawia te etapy w kategoriach samego Every.
• DORA AI Capabilities Model (Kevin M. Storer i Derek DeBellis, Google Cloud, 23 września 2025). Siedem możliwości organizacji, bez poziomów; zobacz samoocenę według modelu DORA.
• DX AI Measurement Framework (Abi Noda i Laura Tacho, DX; znany z drugiej ręki, z wyciągu wyszukiwarki). Trzy wymiary: wykorzystanie, wpływ i koszt. To framework metryk, a nie model dojrzałości; jego miejsce to frameworki metryk.

Prompt do skopiowania: przełóż starą mapę wdrożenia na przejścia po drabinie

Read the attached rollout plan. It uses a calendar or tier scheme (waves,
weeks, phases, tiers or maturity labels). Rewrite it as ladder transitions:
for each step, name the loop (a repeatable class of change), its current
level on the autonomy ladder (L0 to L5), the target level, and the exit
criterion as evidence a script could check (for example: "10 of 10 sampled
PRs carry an evidence bundle; tests and CI files untouched"). Replace every
risk tier with a risk class (low, medium, high, critical) attached to kinds
of change, not to teams. Drop every date that is not tied to an exit
criterion. List anything in the original plan that measured activity
(seats, prompts, tokens) rather than evidence, and say what to measure
instead.

Gdzie jedna mapa zawodzi

Uśrednianie poziomów do jednej liczby. „Organizacja jest na poziomie 3,2” ukrywa dwie pętle, które mogłyby działać bez ludzi, i krytyczną pętlę, która nigdy nie powinna była opuścić L3. Naprawa: raportuj rozkład i liczbę pętli na L4 lub wyżej, nigdy średnią.

Ocenianie zespołu po pętli na pokaz. Jedna dopracowana pętla podbijania zależności na L4 zamienia się w „jesteśmy zespołem L4”. Naprawa: poziom zespołu to udział zmergowanych zmian, więc pętla, która daje 5% merge’ów, przesuwa rozkład o 5%.

Odczytywanie klasy ryzyka jako pozwolenia. Pętla awansowana na L4 zaczyna mergować migracje schematu na samych dowodach. Naprawa: klasy ograniczają poziomy; dopisz ścieżki krytyczne do CODEOWNERS i niech CI blokuje merge na samych dowodach, gdy dotyka tych ścieżek.

Deklarowanie poziomu, którego stacje nie udźwigną. Pętla nazywana jest L4, choć jej wyrocznia leży w tym samym diffie, który pisze agent. Naprawa: przeprowadź audyt opisany wyżej; pętla, której agent może edytować wyrocznię, jest na L3, dopóki wyrocznia nie trafi poza jego zasięg.

Przesuwanie się w prawo przy pogarszających się wynikach. Udział na L4 rośnie, a razem z nim odsetek revertów. Naprawa: zdegraduj pętlę, która spowodowała reverty, napraw jej wyrocznię i przeprowadź audyt ponownie, zanim znów ją awansujesz.

Dokąd iść dalej od jednej mapy

Czytanie dowodów zamiast kodu Co czyta człowiek na poziomie 4 i przy jakich klasach zmian ktoś nadal czyta kod.

Poziom 3: przeglądasz diffy Gdzie dziś jest większość pętli i dlaczego przepustowość review wyznacza sufit.

Poziom 5: sześć stacji Każda stacja fabryki zestawiona z tym, co dokumentują Claude Code, Codex i Cursor.

AI-native cykl życia Sześć etapów i artefakt, który commituje każdy z nich.

DORA, SPACE, DX Core 4 i pomiar AI Kanoniczne definicje miary stabilności, którą raportujesz obok rozkładu.

Ekonomia oprogramowania budowanego przez agentów Koszt zaakceptowanej zmiany i co oznacza dla niego rozkład poziomów.