Level 3: You Review the Diffs

Level 3 of the autonomy ladder is the stage where agents write most of the code in parallel sessions and a developer reviews every diff before it merges. It is a stage, not a destination: review bandwidth caps it. Teams leave it by moving one change class at a time from line-by-line reading to evidence and automated gates.

This page is for developers who already run two or more agents at once, and for tech leads whose review queue grows faster than the team. Five agents are running and four of them are right. You find out which four by reading, and reading is the one part of the pipeline that did not get faster. CTOs and executives can skip to the measures section: it defines the four numbers that show whether your teams have hit the ceiling.

What you get from this Level 3 guide

• A four-point test that tells you whether you are at Level 3 or still at Level 2.
• The parallel-agent setup in Claude Code, Codex and Cursor, with the commands to start it.
• A map of what each tool’s review automation does, and the one detail that decides whether it gates anything.
• Six steps that raise the review ceiling, including a CI check that turns Claude Code’s review into a blocking gate.
• Three copy-paste prompts: measure your review queue, make agents hand you evidence, and design the review gate.
• The exit criteria for moving a change class to reading evidence instead of code.

Are you at Level 3? The four-point test

Dan Shapiro’s ladder (The Five Levels: from Spicy Autocomplete to the Dark Factory, 23 January 2026) describes Level 3 in three words: “Your life is diffs.” He adds that “almost everyone tops out here.” You are at Level 3 when all four statements are true:

1. The agent writes most of each change. You edit its output, but you rarely type the first draft.
2. More than one agent works at a time, each in its own checkout, while you do something else.
3. You read every diff before it merges. Reading, not the agent, is the step that decides.
4. Your queue of unread work grows during the day. Agents finish faster than you review.

If statement 2 is false, you are at Level 2 and the Level 1–2 guide comes first. If statement 3 is false for some changes and nothing replaced your reading, you are not at Level 4. You are at Level 3 with the check removed, which is the most common way to fail at this rung.

How do you run parallel agents at Level 3?

The mechanical unlock is filesystem isolation: one git worktree per agent, so parallel edits never touch the same files. The second unlock is one screen that shows which sessions need you.

Claude Code

Start each task in its own worktree, in the foreground or in the background (checked with Claude Code 2.1.285):

# Terminal: one isolated session per task
claude --worktree feature-auth
claude --worktree fix-pagination --bg   # runs in the background, prints an id

# Terminal: agent view lists every background session and what it needs
claude agents

Agent view is a research preview. Inside a session, the bundled /batch skill splits one large change into 5 to 30 units, each run by a background subagent in its own worktree. See agent view in Claude Code.

Codex

Worktree support is on by default since Codex 0.156.0, but a session runs in a worktree only when you opt in (checked with codex-cli 0.157.1):

# Terminal: one session per task, each in a new managed Git worktree
codex --worktree

# Terminal: browse every agent session on the local app-server daemon
codex agents

In the TUI, /worktree does the same for a running session and /agents opens the command center. See Codex worktrees.

Cursor

Cursor documents worktrees as the isolation unit: “Worktrees let Agent work in isolated Git checkouts” (checked 2026-08-28; cursor.com was unreachable from the writing environment on 2026-09-26). You run and watch parallel agents from the Agents Window. Check the current setup steps in Cursor’s documentation before you script anything around them.

Worktrees isolate files, not ports, databases, caches or a shared dev server. Give each agent its own port block and its own local state, or two green runs will disagree about the same machine. The git worktrees guide covers ports and state; ephemeral environments cover the rest. For fleets you start from a script, see tmux for agent fleets and herdr, the agent multiplexer.

Why review bandwidth is the Level 3 ceiling

Generation scales with the number of agents; reading scales with the number of reviewers. Two independent datasets measured what happens in between.

Faros AI’s AI Engineering Report 2026: The Acceleration Whiplash (April 2026) covers two years of telemetry from 22,000 developers and more than 4,000 teams. Throughput rose: epics completed per developer +66.2%, task throughput per developer +33.7%, pull request merge rate per developer +16.2%. Quality and review fell behind in the same window:

Faros measure (April 2026)	Change	What it tells you
Median time in review	+441.5%	The queue: how long a pull request sits in review
Median time to first review	+156.6%	The response time: how long before anyone looks
Pull requests merged with no review	+31.3%	Review turning into approval
Incidents per pull request	+242.7%	What the skipped reading cost
Bugs per developer	+54%	The same, measured per person

Faros’s data is vendor telemetry from its own customer base, so read it as a direction, not a forecast for your team. DX measured the load in a different unit: median pull request size grew “from 44 lines to 72 lines per pull request between July 2025 and June 2026” (DX, Justin Reock, 17 June 2026). More diffs, bigger diffs, same reader. The state of agentic engineering page has the full numbers with sources.

What does review automation cover in Claude Code, Codex and Cursor?

All three tools ship an automated reviewer. None of them is a merge gate until you make it one.

	Claude Code	Codex	Cursor
Local review	/code-review in a session (/review is an alias; --fix, --comment)	/review in the TUI; codex review --base main or codex exec review from a script	Not verified here (cursor.com unreachable on 2026-09-26)
Deep or security review	claude ultrareview [target] or /code-review ultra: a cloud fleet in which “every reported finding is independently reproduced and verified”, typically 5 to 10 minutes	@codex security review on the pull request (checked 2026-08-28)	Security Agents for the vulnerability pass (checked 2026-08-28)
Review on the pull request	Managed Code Review: research preview, Team and Enterprise, tuned by a root REVIEW.md	@codex review on GitHub and GitLab, automatic reviews, rules in AGENTS.md (checked 2026-08-28)	Bugbot “reviews pull requests and identifies bugs, security issues, and code quality problems” (checked 2026-08-28)
Can it block a merge?	Not by itself: the check run “always completes with a neutral conclusion”	Not documented (checked 2026-08-28)	PR Routing & Approval “can approve low-risk PRs when your criteria are met” (checked 2026-08-28)

Claude Code rows were checked against Anthropic’s documentation and claude --help on 2026-09-26; the Codex CLI rows against codex --help 0.157.1. Costs for Ultrareview and Code Review are billed as usage credits; see automated code reviews in Claude Code for the current figures and plan limits. The per-tool guides for Codex review and Cursor Bugbot cover setup.

An automated reviewer that cannot block is a second opinion. It raises your ceiling only after you decide which of its findings fail the build.

How do you raise the review ceiling at Level 3?

Six steps, in this order. Each one removes a category of work from the human queue before the next one starts.

1. Measure the queue. Record median time to first review, median time in review, and median pull request size per repository for the last 50 to 100 merged pull requests. Use the first prompt below. Without a baseline, you cannot tell whether any later step helped.

2. Make the deterministic gate block. Types, tests, lint, a schema check, and a grep for the pattern you are migrating away from all exit non-zero on failure. They cost nothing to run and cannot be talked round. Mark them as required checks, so no pull request reaches a human while one is red.

3. Let the automated reviewer fail the build on a short list. Pick the finding classes you trust, such as Important findings in Claude Code Review, and block on those only. Claude Code writes a machine-readable severity count into the check run, which a CI step can read with a token that has read access to checks:

   # CI step, after the "Claude Code Review" check run completes
   CHECK_RUN_ID=$(gh api "repos/$OWNER/$REPO/commits/$SHA/check-runs" \
     --jq '.check_runs[] | select(.name=="Claude Code Review") | .id')
   counts=$(gh api "repos/$OWNER/$REPO/check-runs/$CHECK_RUN_ID" \
     --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson')
   important=$(echo "$counts" | jq -e '.normal') || { echo 'No severity counts in check run'; exit 1; }
   if [ "$important" != "0" ]; then
     echo "Claude Code Review reported $important Important findings"
     exit 1
   fi

   The first call finds the ID of the Claude Code Review check run on commit $SHA, as Anthropic’s Code Review page describes. The normal key holds the count of Important findings. jq -e makes the step fail closed: if the check run carries no severity counts, the build stops instead of passing.

4. Make agents hand you evidence, not a summary of the diff. Every agent pull request states the behaviour it changes, maps each acceptance criterion to a check that ran, and lists any test, fixture or CI file it touched. Use the second prompt below in your context file or task template.

5. Split the queue by risk class. Authentication and authorization, money, schema, data migrations, and any change that edits its own tests always get a human reader. Everything else can be triaged on evidence. The agent PR review triage turns this into a six-step protocol with verdicts.

6. Move one change class to evidence review. Choose the class with the strongest checks, such as dependency bumps or copy changes, and approve it on the evidence from step 4 while you keep reading everything else. The exit criteria below say when a class is ready.

Who signs off stays the same throughout: a named reviewer approves every merge. What changes is what that person reads. At Level 3 it is the diff; after each class moves, it is the evidence plus the diff only for the escalation classes.

Copy-paste prompts for the Level 3 review ceiling

Copy-paste prompt: measure your review ceiling

Measure this repository's review queue. Use the GitHub CLI:
gh pr list --state merged --limit 100 --json number,author,createdAt,mergedAt,additions,deletions,reviews,body
For each pull request compute: time to first review (createdAt to the earliest
review's submittedAt), time in review (createdAt to mergedAt), size (additions +
deletions), and whether it merged with zero reviews. Mark a PR as agent-authored
when its author is a bot account or its body names an agent.
Output one table with the median of each measure, split into agent-authored and
human-authored, and into size buckets under 100, 100-400 and over 400 lines.
Then list the five PRs that waited longest for a first review. Do not estimate:
if a field is missing, say so and leave the cell empty.

Copy-paste prompt: an evidence summary on every agent pull request

Before you open the pull request, write its description in this order and
nothing else:
1. Behaviour change: two sentences on what a user or caller now sees that they
   did not see before. No file-by-file summary of the diff.
2. Acceptance evidence: one line per acceptance criterion, as
   criterion -> command or test name -> result. Run every command yourself;
   paste the exit code, not your expectation.
3. Oracle changes: every test, fixture, snapshot, lint or CI file you added,
   edited or deleted, with one line on why. Write "none" if there are none.
4. Risk flags: say yes or no to each of authentication, authorization, money,
   schema, data migration, public API. For each yes, name the file.
5. Unsure: anything you guessed, skipped or could not verify.
If any command in section 2 failed, do not open the pull request; fix it or
stop and report.

Copy-paste prompt: design the review gate for a repo agents now write

Design the review gate for this repository, given that agents open most of the
pull requests. Read .github/workflows, CODEOWNERS, the test scripts and the last
50 merged PRs first, and then output exactly four things.
1. The classes of change that may merge on a green pipeline alone, each with the
   command that proves it and the file globs that identify it.
2. The classes that always need a human reader, with the same globs, and one
   sentence each on the blast radius that earns them a human.
3. The automated review layer in between: which tool runs, on what diff size,
   what it may block on, and what it may only comment on.
4. The single metric that tells us the gate is failing: name it, say where it
   is measured today, and give the threshold that triggers a change.
Propose nothing you cannot enforce with a file in this repository.

What should tech leads, CTOs and executives measure at Level 3?

Four measures, per repository, show whether a team has hit the ceiling. Adopt the definitions as written and set each threshold from your own last-quarter baseline, not from another company’s numbers.

Measure	Definition	Ceiling signal
Time to first review	Median hours from pull request opened to first review submitted	Rises while agent count rises
Time in review	Median hours from opened to merged	Rises faster than merge rate
Unreviewed merge share	Merged pull requests with zero reviews, divided by all merged	Any rise that no written policy allows
Median pull request size	Median of additions plus deletions	Grows beyond what one reviewer reads in one sitting

A rising unreviewed merge share is the number to watch. It means reviewers have stopped reading without a gate taking their place. The review queue guide for teams covers how to staff and route the queue.

What breaks when five agents share one reviewer?

The queue grows before anyone notices

Symptom: each pull request looks reasonable, yet time to first review doubles over a month. Recovery: run the measurement prompt every two weeks, cap concurrent agents per reviewer at the level where the queue stays flat, and spend the freed time on step 2 of the list above.

Review turns into rubber-stamping

Symptom: approvals arrive minutes after a 400-line pull request opens. Recovery: name the classes that may merge on evidence (step 6) and require a real read for the rest. An honest gate says which classes merge unread; a reviewer who stopped reading and said nothing is the failure Faros measured.

Everyone scrolls past the automated reviewer

Symptom: the bot comments on every pull request and nobody acts on its findings. Recovery: block on one finding class (step 3), turn the rest into comments, and tune the reviewer’s instructions (a root REVIEW.md for Claude Code Review, review rules in AGENTS.md for Codex) until its blocking findings are right most of the time.

Parallel agents collide outside the repository

Symptom: two worktrees pass alone and fail together, or one agent’s migration breaks another’s tests. Recovery: assign each worktree its own port block and database, and start dev servers on those ports instead of the defaults.

The diff is too big to review honestly

Symptom: a pull request exceeds what one person can hold, or Ultrareview refuses it as too large. Recovery: return it and split the task: one agent task, one concern, one pull request. A faster reader is not the fix.

When is a change class ready to leave Level 3?

Leave one class at a time, never the whole repository at once. A change class is ready for evidence review when all four hold:

• A deterministic gate for the class is a required check and has blocked at least one bad change.
• Agents cannot weaken the oracle unnoticed: any edit to tests, fixtures or CI in the same pull request sends it to a human.
• Every pull request in the class carries the evidence summary from the second prompt.
• Your reading over a run of recent pull requests in the class (for example, the last 10) found nothing the checks had missed.

Keep a short trust log of each class, when it moved, and what sent it back. Reading evidence instead of code explains what you read instead of the diff and the signs that you stopped reading too early. Reviewing an agent’s pull request is the day-to-day triage. When most of your merged changes are approved on evidence, your runs can last hours, and Level 4 begins.

Where to go next from Level 3

Reading evidence instead of code What a human reads once the diff stops being the unit of review.

Reviewing an agent's pull request A six-step triage: approve, return or escalate without reading every line.

Level 4: You Write the Specs Stop conditions, hooks and runs you can leave.

Layered PR review The three-layer gate, and why agent pull requests need it.

Team PR review automation Layered AI reviewers across a team.

One map The ladder, the lifecycle and the factory stations on one grid.

Find your level Twenty-five questions that place your workflow on the ladder.