One map: the autonomy ladder, the lifecycle and the factory stations

The one map combines three axes in a single grid. Maturity is the autonomy ladder, Level 0 to Level 5, measured per loop. Process is the six lifecycle stages, from plan to maintain. Capability is the six factory stations, from intent to release. Each cell names the evidence a loop must produce before it may run at that level.

Your adoption roadmap says “wave 3”, the CTO scorecard says “Level 2”, a vendor deck says “around L3”, and the compound engineering guide says “stage 2”. Then the board asks: what level are we at? Four numbers, four definitions, and none says which work may merge without a human reading it. This page reconciles them: one vocabulary for maturity, process and capability, and a map from every older scheme on this site back to it.

What the one map settles for each reader

• Developers: which evidence your loop has to produce before you stop reading its diffs, stage by stage.
• Tech leads: a loop register you can copy, and a rule for promoting or demoting a loop on evidence rather than on confidence.
• CTOs: a metric definition for team and organization level that cannot be averaged into a vanity number, and risk classes that sit beside levels instead of inside them.
• Executives: one sentence to report upward (“share of merged change produced at Level 4 or above, with its failure rate”) and the list of outside models that are not the same thing.

What are the three axes of the one map?

Each axis answers a different question with a different unit, and confusing the units starts most maturity arguments.

Axis	Question it answers	Values	Unit it applies to	Canonical page
Maturity	Who reads what before a change merges?	L0 By hand · L1 Assisted · L2 Paired · L3 Review manager · L4 Spec manager · L5 Dark factory	One loop	The autonomy ladder
Process	Where in the life of a change are we?	Plan · design · build · test · deploy · maintain	One stage of the lifecycle	The AI-native lifecycle
Capability	What machinery exists to run that stage without a person?	Intent · harness · loop · graph · verification · release	One station of the factory	Level 5: the six stations

A loop is a repeatable class of change with its own trigger, oracle and stop condition: dependency bumps, flaky-test repair, feature work in the checkout service, schema migrations. A level belongs to a loop, not to a company: a dependency-bump loop with a deterministic check can run at Level 4 while the feature work beside it sits at Level 2, and both answers are correct at once.

The ladder’s six levels follow Dan Shapiro, “The Five Levels: from Spicy Autocomplete to the Dark Factory” (January 2026); the short names are this site’s. Shapiro places most AI-native developers at Level 2 and says almost everyone tops out at Level 3, which is why most cells in the grid below sit in those two columns for most teams.

Where do the nine task nodes fit?

The tool trees (Claude Code, Codex, Cursor) are organized by nine task nodes. They are navigation, not a fourth axis, and each one maps onto the process and capability axes:

Task node in the tool trees	Lifecycle stage	Stations it mostly documents
Quick start	Setup, before the lifecycle	Intent, harness
Plan	Plan, design	Intent
Build	Build	Harness, loop, graph
Test	Test	Verification
Ship	Deploy	Verification, release
Operate	Maintain	Loop, release
Automate	Build to maintain	Loop, graph, release
Team	Across stages (shared rules and people)	Intent
Reference	None	None

The grid: what evidence does each level require at each stage?

Rows are lifecycle stages; each row names the stations that produce its evidence. Columns are ladder levels. A cell is the evidence that must exist, and be produced by a machine wherever the level is L4 or above, before a loop may claim that level at that stage. L0 and L1 are left out: at those levels the evidence is the human who typed or accepted each line.

Stage (stations)	L2 Paired	L3 Review manager	L4 Spec manager	L5 Dark factory
Plan (intent)	Intent lives in the prompt and the developer’s head	A written task with acceptance criteria in the issue	A committed intent.md or spec with machine-checkable acceptance criteria, accepted by a named owner before the run	Intents arrive from a queue (tracker, alert, incident), each carrying its own oracle; the owner signs the intent, not the code
Design (intent, graph)	Decided live in the session	A plan reviewed in plan mode before implementation starts	Committed spec.md and plan.md; architecture constraints encoded as rules or fitness functions the agent cannot edit	Decomposition runs as a versioned workflow; a design change outside the agreed envelope escalates to a human
Build (harness, loop, graph)	The human watches every edit and answers permission prompts	The agent runs unattended in a worktree or sandbox; the evidence is the diff plus a local test run	An explicit permission mode and sandbox for the run type, a stop condition a machine evaluates, and a retry bound	Event-triggered runs with no approval prompts; the harness configuration is versioned and reviewed like code
Test (verification)	Tests the human writes or reads	CI is green and a human reads the diff, tests included	An oracle outside the agent’s reach (protected tests, acceptance tests from the spec) and an evidence bundle attached to the pull request	Oracle strength is measured, not assumed; CI rounds are bounded; the factory itself has evals
Deploy (verification, release)	The human merges what they wrote with the agent	A human approves the merge after reading every diff	The merge decision rests on the evidence bundle and the risk class; code is read only for the classes that require it	Low-risk classes auto-merge by rule; progressive delivery with automatic rollback on a service-level breach
Maintain (loop, release)	Humans watch production	The agent triages on request; a human drives the fix	Scheduled or event-triggered runs open pull requests from alerts, with runtime signals in the evidence	A breached control band writes the next intent, and every incident adds a case to the oracle

Read the grid by row, not by column. A loop is at the lowest level any of its stages supports. A loop with an L4 test row and an L3 deploy row is an L3 loop, because a human still reads every diff before merge.

The canonical pages for the cells are evidence instead of diffs (what a human reads at L4), the evidence bundle (what the pull request must carry), oracle strength (how strong the test row is) and progressive delivery (the L5 deploy row).

How do you score a team or an organization?

A team does not have a level. It has a distribution: the share of its merged change produced by loops at each level. Use this definition as it stands.

Field	Definition
Unit	One merged pull request (or merged change set), tagged with the loop that produced it
Level of a change	The level the loop held on the merge date, established by the evidence test in the next section, not by self-report
Window	A rolling 30 days for teams; a quarter for the organization
Team level	Share of merged changes at L0–L2, L3, L4 and L5 in the window
Organization level	The same distribution across all teams, plus the number of loops at L4 or above
Paired stability measure	Change failure rate (or revert rate) per level, in the same window
Forbidden	Averaging levels into one number (“Level 3.4”), or reporting the best loop as the team’s level

The paired stability measure is not optional. DORA’s 2025 report (Nathen Harvey and Derek DeBellis, Google Cloud, 23 September 2025) found “a positive relationship between AI adoption on both software delivery throughput and product performance”, and in the same breath: “However, AI adoption does continue to have a negative relationship with software delivery stability.” A distribution that moves right while failures rise is not progress.

An illustrative team, not a measured one:

Loop	Level	Merged PRs, 30 days	Share
Dependency bumps	L4	60	30%
Flaky-test repair	L4	20	10%
Checkout feature work	L3	84	42%
Schema migrations (critical class, always read)	L3	12	6%
Payment-provider integration	L2	24	12%

The report line is: “Checkout: 40% of merged change at L4, 48% at L3, 12% at L2, with change failure rate per level beside it.” The team is not “Level 3”. It runs two L4 loops, and the next promotion decision is about one named loop, not the team.

Run the distribution from your merged pull requests

Export the last 30 days of merged pull requests with the GitHub CLI, in your terminal, from the repository root:

# GNU date (Linux); on macOS use: 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

# Slim the export: the raw file is one JSON line, often several MB, which a
# file-reading tool cannot page through.
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

Save the prompt below as prompts/level-distribution.txt, then run it read-only in your tool. --tools "Read" removes every other Claude Code tool; in Codex, the :read-only permission profile (beta) replaces the legacy --sandbox flag, and the two must not be combined:

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

Open the agent chat in the repository, attach prs-slim.json and paste the prompt. The task needs no terminal commands and no edits, so decline any the agent proposes, then save the answer as level-distribution.md.

Copy-paste prompt: the level distribution of merged change

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.

Why is a risk class not a maturity level?

A level describes a loop. A risk class describes a single change. They answer different questions, and mixing them produces the worst failure on this page: “we are Level 4, so the agent may merge the auth change”.

Risk class	Typical changes	May merge on evidence alone?	Who signs
Low	Docs, copy, internal tooling, patch-level dependency bumps with green contract tests	Yes, in L4 loops; by rule in L5 loops	The loop owner, through the rule
Medium	Feature logic behind a flag, internal API changes	Yes, when a human reads the evidence bundle	A reviewer of the evidence
High	Public API contracts, data model changes, performance-critical paths, any change to tests or CI configuration	No: evidence plus a human reading the sensitive paths	The code owner
Critical	Authentication, money movement, schema migrations on production data, secrets and permissions, the agent’s own harness	No: a human reads the code, and deployment needs a separate approval	A named owner and a second approver

The class caps what a level may do with a given change. An L5 loop that opens a critical-class pull request escalates it exactly as an L2 team would. Changes to tests and CI are high class on purpose: they are the oracle, and an agent that edits its own oracle has turned the check into a suggestion. The policy that assigns classes lives in governance and autonomy; the list of changes where someone still reads code lives in evidence instead of diffs.

How do you prove a loop is at the level you claim?

A level is a claim about evidence, so it can be checked without reading the code. Run this audit before promoting a loop and once a quarter after.

1. Sample. Pick 10 merged pull requests from the loop at random from the last window.
2. Check the evidence for the claimed level. For L3, each has a human approval after a diff review. For L4, each carries an evidence bundle, its tests and CI files are untouched (or code-owner approved), and the run recorded a stop condition. For L5, each merged by rule with no human approval, and the rollback path has fired at least once in a drill.
3. Check the four ledger questions from software factories: what oracle decides done, can the agent fake it, how long until a wrong answer surfaces, and what the blast radius is.
4. Compare stability. The loop’s change failure rate or revert rate over the window must be no worse than at its previous level.
5. Record the verdict in the loop register with the date and the sample, and have the tech lead sign the promotion.

A failed check demotes the loop; it does not start a debate. The tech lead signs promotions, and the CTO owns the risk-class policy.

The artifact that makes this repeatable is a loop register, one file per repository:

# 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

Copy-paste prompt: draft a loop register from repository history

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.

Which older schemes does the one map replace?

This site used to run several numbering schemes side by side. They are retired, and each maps back to one axis of the map. If you meet one in an older bookmark or an internal deck, translate it with this table.

Retired scheme	What it described	What replaces it	Where to read it now
Waves 0–5	A repository rollout in fixed waves	Ladder transitions, one loop at a time	Adoption roadmap
Weeks 1–8, “Month 2+”	A developer’s learning calendar	Track steps with exit criteria	Developer track
Weeks 1–12, “Month 4+”, “Phased Enterprise Rollout”	An organization rollout calendar	Stop/go gates stated as ladder transitions per loop	Transformation roadmap
Adoption Curve, Phase 0, org-size models	Who adopts first, and in what order	Ladder transitions plus a designed pilot	Pilot design
Phases 1–4	A tool migration checklist	Unnumbered migration steps	Migration guide
“Tier 2 / Tier 3”	Parallel agents, then overnight runs	L3 (parallel agents, a human reads every diff) and L4–L5 (unattended runs)	Team parallelism
“Reactive → Strategic Leader”	Leadership maturity labels	The Level 1–4 bands the CTO scorecard scores: Assisted, Paired, Review manager, Spec manager	CTO scorecard guide
Every’s stage ladder (stages 0 to 5), used as a second ladder	An individual’s adoption path	The ladder, per loop; Every’s stages remain Every’s own model (see below)	Compound engineering
“Risk tiers 0–3”	How dangerous a change is	Risk classes: low, medium, high, critical	Governance and autonomy

The CTO scorecard band is a self-assessment of practices (tooling, review, governance), not the level distribution of merged change. Never report it as “our level”; quote it separately from the distribution.

The pattern behind the table: a date is not evidence, and a measure of danger is not a measure of maturity.

Other maturity models you'll meet

These models are in circulation and worth knowing. None of them is the autonomy ladder, and this site does not map them onto it. Use each for what it measures.

• JetBrains AIDEs Framework (JetBrains Research blog, September 2026; secondary source: summarised from a search extract, not the original post). Five delegation levels, from L1 “Tool” to L5 “Competence Center”, across 35 SDLC activities. An AIDEs “L3” is not ladder Level 3, so never convert a claim such as “tool X is around L3” from one model to the other.
• Every’s stage ladder (Every Inc.’s compound engineering guide at every.to; Kieran Klaassen introduced the method in August 2025). Stages 0 to 5 that describe how one person’s working style changes, from writing every line to directing parallel cloud agents. The compound engineering page covers the stages in Every’s own terms.
• DORA AI Capabilities Model (Kevin M. Storer and Derek DeBellis, Google Cloud, 23 September 2025). Seven organizational capabilities, no levels; see the DORA AI capabilities self-assessment.
• DX AI Measurement Framework (Abi Noda and Laura Tacho, DX; read second-hand through a search extract). Three dimensions, utilization, impact and cost. It is a metrics framework, not a maturity model; its home is metrics frameworks.

Copy-paste prompt: translate an old roadmap into ladder transitions

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.

Where the one map goes wrong

Averaging levels into one number. “The org is at Level 3.2” hides the two loops that could run dark and the critical loop that should never have left L3. Recovery: report the distribution and the count of loops at L4 or above, never a mean.

Scoring the team by its showcase loop. One polished dependency-bump loop at L4 becomes “we are an L4 team”. Recovery: the team level is the share of merged change, so a loop that produces 5% of merges moves the distribution by 5%.

Reading a risk class as permission. A loop promoted to L4 starts merging schema migrations on evidence alone. Recovery: classes cap levels; add the critical paths to CODEOWNERS and make CI fail when an evidence-only merge touches them.

Claiming a level the stations cannot support. A loop is called L4 while its oracle sits in the same diff the agent writes. Recovery: run the audit above; a loop whose agent can edit its oracle is L3 until the oracle moves out of reach.

Moving right while getting worse. The share at L4 rises and so does the revert rate. Recovery: demote the loop that caused the reverts, fix its oracle, and re-audit before promoting it again.

Where to go next from the one map

Reading evidence instead of code What a human reads at Level 4, and the change classes where someone still reads the code.

Level 3: You Review the Diffs Where most loops sit today, and why review bandwidth is the ceiling.

Level 5: the six stations Each factory station mapped to what Claude Code, Codex and Cursor document.

The AI-native lifecycle The six stages and the artifact each one commits.

DORA, SPACE, DX Core 4 and AI measurement Canonical definitions for the stability measure you report beside the distribution.

The economics of agent-built software Cost per accepted change, and what the distribution means for it.