The AgenticDevelopment Ladder.

Everything below expands on this page. If you read nothing else, read this.

The three moves that matter most, whatever stage you are at

1. 01Make the merge gate bind. Branch protection on the integration branch with required status checks and no admin bypass. This single setting converts every downstream repair into an in-session fix. It is the highest-leverage change on this page and it costs zero engineering.
2. 02Give the agent a check it can run. One command that runs the same lint, type, test, build, and security checks as CI. The difference between a session you watch and a session you walk away from is whether the agent can find out for itself that it is wrong.
3. 03When something goes wrong, change the system. A hook, a lint rule, a CI gate, a type, a regression test. A sentence in a rules file is the weakest possible fix and should be your last resort, not your first.

The opportunity is real and the failure mode is real

The evidence from teams who have gone furthest is consistent. OpenAI's Codex team reported shipping an internal product over five months with roughly 1,500 merged pull requests and about a million lines of code, none of it hand-written, in about a tenth of the estimated time. Lauren Tan, whose twenty-plus agents handle bug fixes, testing and merging around the clock, says she "almost never looks at code anymore" because architectural constraints, CI, and verification flows took over the checks she used to do line by line. Simon Willison, one of the most careful sceptics in this space, wrote in May 2026 that for well-tested, well-specified changes he no longer reviews every line either. He treats the agent like another engineering team at a large company: a semi-black box that produces reliable output because the contracts around it are tight.

The same evidence says what happens when you skip the system-building. DORA's 2025 research found that AI raises delivery throughput but also raises delivery instability, and that about 30 percent of developers report little or no trust in AI-generated code. Their summary: AI does not fix a team, it amplifies what is already there. Mitchell Hashimoto warned that entire companies are in "AI psychosis," unable to talk rationally about what agents can and cannot do.

Put those together and the conclusion is uncomfortable but simple. Agents multiply whatever your process already is. A team with loose gates and agents gets loose outcomes faster. A team with binding gates and agents gets high-quality outcomes faster. The agents are not the variable. The gates are.

The thesis: trust is manufactured by verification, not by reading

Every serious practitioner converges on the same claim, in their own words.

• —Lauren Tan (pstack): verification comes first because everything else depends on it. Verify against the real artifact, never a proxy: run the feature, read the actual value, inspect the diff. "It compiles" does not count.
• —Mitchell Hashimoto: every time the agent makes a mistake, change the system so that mistake structurally cannot recur. Not the prompt. The rules, tools, constraints, and feedback loops.
• —Birgitta Böckeler (martinfowler.com): Agent = Model + Harness. The harness has two halves: guides that constrain the agent before it acts (rules files, plans, tool definitions) and sensors that check it after it acts (linters, tests, hooks, evals).
• —Anthropic's Claude Code guidance: give the agent a check it can run. It is the difference between a session you watch and one you walk away from.
• —OpenAI: "Humans steer. Agents execute." The faster an agent moves without constraints, the worse the architectural drift, so encode the project's principles into the repository itself.
• —1Password: the verifier is the bottleneck, and no system should grade its own homework.

The unit of trust is a check that runs, not a person who read. A human reading a diff is the fallback for things you have not yet learned to check mechanically, and this whole ladder is, in large part, a plan to shrink that set.

What "human control" means under this thesis

Control does not mean reading everything. It means humans hold, and never delegate, five things.

The operating principle has a name in pstack: never-block-on-the-human. Make reasonable decisions, proceed with reversible work, and let the human course-correct after the fact; reserve confirmation for irreversible actions. As autonomy rises, what humans look at shifts from code to evidence to metrics and exceptions. That shift is the ladder.

These are the beliefs that decide arguments. When two options look equally good, pick the one these favour. They apply at every stage.

1. 01

   Verification before everything.

   No feature is done until the agent has driven it through the real app and attached evidence. A green build is a proxy. A screenshot of the real flow, a passing test that would have failed before, a grader's PASS line: those are evidence.

   pstack prove-it-works · Claude Code best practices

2. 02

   Encode lessons in structure, not prose.

   When something goes wrong, the fix is a hook, a lint rule, a CI gate, a type that makes the wrong state unrepresentable, or a regression test. Text in a rules file is the weakest form of a lesson. Mechanism hierarchy: unrepresentable state › lint or banned API › canonical helper › runtime check › documentation.

   Hashimoto · pstack encode-lessons-in-structure

3. 03

   Writer and judge are never the same agent.

   The builder never grades its own work. Reviewers get the artifact and the contract, never the builder's reasoning, because independence dies the moment you tell a reviewer what you expect it to find. A test-writing agent should write tests from the spec without reading the implementation for the same reason.

   1Password: no system grades its own homework

4. 04

   A control is done when it fires, not when it merges.

   A review workflow that is ticked as done when the YAML lands, but never executes a turn, is worse than no workflow: it produces a permanently red or permanently green check everyone learns to ignore. Every gate, hook, or routine is verified by a run that proves it fired, and its failure mode must be loud, never continue-on-error.

   Common failure pattern, see Stage 2

5. 05

   Measure behaviour, not documents.

   Re-reading a rule tells you it exists. Running a fresh agent against a canned task and grading the output mechanically tells you the rule binds. Rule and skill changes should cite an eval run. Trend the score; a single run is weather, not climate.

   Golden-task evals, see Stage 2 and Stage 5

6. 06

   Fewer, sharper things.

   Teams that add a skill or rule for every problem end up with dozens of skills, dozens of rules, and tens of kilobytes of context loaded before the agent reads a single project file. Adding is the failure mode, not the fix. Every proposed addition must name what it replaces or why nothing existing covers it.

   pstack laziness-protocol · subtract-before-you-add

7. 07

   Go deep first, then go parallel.

   Speed comes from parallelism, and parallelism is only safe when each unit is small, verifiable, and independently checked. Competing attempts plus a separate judge beat accepting the first answer for anything architectural.

   pstack: "if you want to go fast, go deep first"

8. 08

   Honesty in the paper trail is a hard rule.

   A plan may say Complete only when every task and acceptance criterion is checked with named evidence. Deferrals are recorded, never silent. A pull request that was not browser-verified says UNVERIFIED and that is a merge blocker. Checklists that lie are the root of the worst incidents: a plan marked fully complete while the code does not compile.

   Enforce with a plan-status lint in CI

Six stages. In the staircase at the top of this page, the height of each step is the share of the team's attention that moves from reading code to reading evidence.

How to read the stage sections

Each stage below has the same five parts, so you can compare across stages.

• —What it looks like. The shape of the work, in plain language, with an example.
• —A day in the life. A realistic timeline for one developer at that stage.
• —Signs you are here. Two columns: what is true, and what typically breaks.
• —Exit checklist. The exact things to do to reach the next stage, in order, each with the evidence that closes it. These are deliberately few. If you cannot produce the evidence, the item is not done.
• —Do not skip. The mistake teams make when they try to jump this stage.

Timing guidance is given per stage. Confidence in those estimates is low to moderate: the engineering is well understood, but the constraint is almost always human attention on admin and infrastructure steps, and that varies enormously between teams.

Developers use AI as a faster keyboard and a smarter search engine. Every line that lands was typed or accepted by a person who read it.

What it looks like

Autocomplete in the editor. A chat window open on the side for "how do I do X in this library" and "explain this stack trace." Occasionally a developer pastes a function in and asks for a refactor, then pastes the result back and adjusts it by hand. The AI never touches the repository directly. There is no rules file for the AI, or there is one that a single enthusiast wrote and nobody else knows about.

Example. A developer is adding a date-range filter to a reports page. They type the component skeleton, accept a few autocomplete suggestions for the state hooks, ask chat how to format a date in the project's locale, and hand-write the tests. Total AI involvement: maybe 20 percent of the keystrokes, zero percent of the decisions.

Signs you are here

The agent does the typing. Humans do the thinking, the reviewing, and increasingly the waiting. Speed is now capped by how fast people can read.

What it looks like

Developers describe a task and the agent implements it: reads the codebase, edits files, runs tests, iterates. The developer watches, corrects, and reviews. Pull requests get bigger and arrive faster. Code review becomes the bottleneck, and reviewers start skimming because they cannot keep up. The rules file grows as people add "never do X again" lines after each incident. CI exists but may not be required for merge.

Example. The same date-range filter. The developer writes a three-paragraph prompt: what the filter does, where it goes, that it should use the project's existing date utilities and follow the existing filter components. The agent finds those components, builds the feature, writes tests, and runs them. Forty minutes of agent time. The developer then spends thirty minutes reading a 400-line diff, finds that the agent duplicated a date-formatting helper that already existed, asks for a fix, re-reads. Total elapsed time is similar to Stage 0 but the developer's time has shifted almost entirely into reading.

Signs you are here

The agent works inside a system. Mechanical correctness is the machine's job. Humans still verify behaviour, but they read less code and more output.

What it looks like

A short rules file steers the agent before it acts. Hooks block dangerous writes as they happen. One validation command is the gate, locally and in CI. A builder-checker loop runs to green without a human relaying errors. Branch protection means nothing merges red. A handful of read-only reviewer agents (security, architecture, performance, error handling) fan out on a branch before merge and return findings in a shared format. The human reads risky diffs and the reviewer findings, and trusts the machine for the rest.

Example. The date-range filter again. The developer starts the build command with a link to the approved plan. The builder reads the plan and the topic rules for UI components, finds the existing date helpers because the rules file tells it where they live, builds the feature and the tests. The checker runs the validation command, reports a lint violation and a failing test verbatim, the builder fixes both, the checker returns all green. Reviewer agents flag that the new server function does not validate its input. The builder fixes that. The developer reads the reviewer findings, spot-reads the server function, opens the PR. CI runs the same validation command and passes. A colleague approves in a few minutes because the PR body says what was checked. Total human reading time: ten minutes instead of sixty.

Signs you are here

A pull request from an agent arrives with everything a human needs to merge it without reading the diff, and for routine work humans actually do that.

What it looks like

The agent does not just build the feature. It drives it through the real application, records what it saw, runs the reviewer fan-out, and assembles all of that into a structured PR body: checker output, verification screenshots, review verdict, residual findings, and each acceptance criterion ticked with a pointer to its evidence. The human reads that page, not the code. Merge takes seconds for routine work. Code gets read when the evidence is thin, a reviewer flagged something, or the change touches a place where the team has decided humans always look (auth, payments, data migrations).

Example. The date-range filter PR body now reads: "Acceptance criteria: 1. Filter defaults to last 30 days: PASS, screenshot 1. 2. Custom range persists in URL: PASS, screenshot 2 and URL shown. 3. Invalid range shows inline error: PASS, screenshot 3. Checker: all green, output attached. Reviewers: security PASS, performance one low-confidence note about an unbounded query, architecture PASS. Residual: none. Not verified: dark-mode rendering, noted UNVERIFIED." The reviewer reads that in ninety seconds, glances at the unbounded-query note, sees it is a paginated endpoint, and merges.

Signs you are here

The team of agents works while you sleep. The human's day is spent on direction, exceptions, and taste.

What it looks like

Issues tagged ready-for-agent in the tracker are picked up by a routine that writes a plan if none exists, waits for a human to approve it, then builds, verifies, and ships a PR with its evidence bundle. Several agents work in parallel, one owner per PR, small verifiable units, stacked where dependent. Other routines watch the system rather than the code: nightly error triage, a weekly retro that opens a PR against a rule when a metric moves the wrong way, a scheduled drift scan that files refactoring PRs. Humans approve plans, merge PRs, and handle escalations. A human looks at code when a metric or an escalation says to.

Example. Monday morning. Over the weekend, the queue routine picked up six tickets tagged ready. Four had approved plans and are now PRs with evidence bundles. Two are draft plans waiting for approval. Error triage opened two fix PRs for a null-pointer path that appeared in production Friday night; both have a failing test committed first and both verified in the browser. The drift scan opened one PR consolidating three near-duplicate date helpers into one. The retro routine flagged that QA-waived PRs rose from 2 to 7 last week and drafted a PR tightening the ship workflow to refuse a waiver without a named reason. The engineering lead spends the first ninety minutes of the week reading evidence and approving plans, and the rest on the one architectural question no agent should decide.

Signs you are here

The system edits itself, but every edit is evidence-gated and human-merged. Humans are product owners and editors of principles.

What it looks like

When an agent is corrected, the system proposes the structural change that would have prevented the correction, with an eval run attached showing the new rule binds. When a metric moves the wrong way, a routine proposes the rule or workflow change and the eval that proves it. When a golden eval fails, a task is opened and a mechanism PR follows. Humans read trend lines and the rare novel failure. They still own direction, taste, the never-do list, and every irreversible action. The never-do list has not shrunk since Stage 1.

Example. A human corrects an agent for putting a business rule in a UI component instead of the domain layer. The reflect step captures it. Overnight, a routine drafts a lint rule that flags domain logic in the UI folder, runs the golden evals with and without the rule, shows that the "add a page" task now PASSES the layering criterion where it used to be coached, and opens a PR with the rule, the eval diff, and a one-paragraph rationale. The human reads the rationale and the eval diff in two minutes and merges. Nobody will make that mistake again, and nobody wrote a sentence in a rules file.

Signs you are here

Answer honestly. Your stage is the highest row where every statement is true. Most teams overestimate by one stage because they count things that are written down but do not bind.

If you failed a row on exactly one item, you are "late" in the stage below and that item is your next move. If you failed on several, do them in the order the exit checklist gives, because the order is chosen so that each item makes the next one safe.

Made explicit so nobody mistakes "reading less code" for "losing control."

Ten numbers, reviewed weekly. Start collecting the first five at Stage 2; the rest come online as the stages that need them arrive.

• —Start every session with a workflow, not a blank prompt. A build command, a fix command, a plan command. The workflow carries the loop, the stop rules, and the checkers. Freeform sessions are how gates get skipped.
• —Use a prompt template. One-sentence goal with the ticket ID, the plan path, acceptance criteria you could verify yourself, an explicit evidence demand ("paste the checker output"), and "do not merge."
• —Never tell an agent to skip a gate silently. If a skip is needed: "skip X and record the skip and the reason in the plan changelog."
• —Merge on evidence, after green. If the PR body says UNVERIFIED, treat it as a blocker, not a note.
• —Feed failures back verbatim. Paste the error. Paraphrased symptoms send the builder guessing.
• —Ask for the generalisation. After a bug fix: search for the class of bug repo-wide, add a lessons entry with a covering test.
• —One session, one surface, one branch. Check what is already in flight before spawning another agent on the same area.
• —When something goes wrong, change the system. A hook, a lint rule, a test, a grader criterion. If you only wrote a sentence in a rules file, you are not done.

Templates and reference, collapsed. Open what you need.

# <Project> — Agent rules

Stack: <language, framework, database, hosting>. Package manager: <one>.

## Run
- Install: `<cmd>`   Dev: `<cmd>`   Validate (lint + types + build + tests + secrets): `<cmd>`
- Run validate before declaring anything done. Paste its output.

## Critical rules (violations break the codebase)
1. <error-handling convention>
2. <import / module-boundary convention>
3. <data-access convention, e.g. tenant filter on every query>
4. <validation at boundaries>
5. <search before creating: components, helpers>

## Never
Push to a shared branch · merge · force-push · delete data or branches ·
edit generated files by hand · write secrets · weaken, skip or delete a check.

## Loop stop rules
Stop on: ALL GREEN · 5 cycles · same failure twice in a row ·
a fix breaks a previously passing check. Escalate with the evidence attached.

## Topic rules
Loaded by path from `rules/`: database, ui, testing, error-handling.

## What
<one paragraph, links to plan and ticket>

## Acceptance criteria
- [x] AC1 <text> — evidence: <test name / screenshot #>
- [x] AC2 <text> — evidence: ...
- [ ] AC3 <text> — UNVERIFIED: <reason>

## Checker output
<pasted validate output, ALL GREEN>

## Verification
<flow → observable end state → screenshot> ×N

## Review fan-out
security: PASS · architecture: PASS · performance: 1 low-confidence note (below)
## Residual findings
<none, or listed with confidence>