Skip to content

Level 3: You Review the Diffs

Level 3 on the autonomy ladder is the code-review manager: agents write most of the code in parallel sessions and worktrees, and the developer’s day becomes reading diffs. Dan Shapiro calls it the level almost everyone tops out at, because review bandwidth, not agent throughput, sets the ceiling. The articles here cover parallel agents, agent views, and review automation for Cursor, Claude Code and Codex.

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. Shapiro’s summary of the rung (The Five Levels, January 2026) is three words long: “Your life is diffs.”

What changes when agents stop waiting for you

Section titled “What changes when agents stop waiting for you”

The mechanical unlock is filesystem isolation. All three tools document worktrees for it: Claude Code’s “isolate parallel Claude Code sessions in separate git worktrees so changes don’t collide”, Codex’s “worktrees let Codex run multiple independent chats in the same project without interfering with each other”, and Cursor’s “worktrees let Agent work in isolated Git checkouts”. One checkout per agent turns concurrency from a merge hazard into a scheduling question.

The second unlock is a place to watch them from. Claude Code’s agent view “shows what every session is doing and which ones need your input”; Codex Micro is described as “your command center for Codex chats”; Cursor has an agents window. Outside the vendors, a tmux fleet or herdr gives you the same thing with a scriptable API, which matters when you want a fleet started by a command rather than by hand.

Delegation inside a single session is the third. All three document subagents, and only Claude Code documents a cap: 20 concurrent subagents per session by default, after which spawning another fails, raised with an environment variable. Codex exposes a configurable limit with no documented default; Cursor documents no maximum and instead warns against dozens of vague ones.

What review automation actually covers in each tool

Section titled “What review automation actually covers in each tool”

Checked against the vendors’ documentation on 28 August 2026.

Claude Code has three layers. /code-review “reviews a diff in your terminal without installing the GitHub App”. The hosted Code Review “analyzes your GitHub pull requests and posts findings as inline comments”, sorted into Important, Nit and Pre-existing, at a documented average of $15–25 per review. Ultrareview runs “a deep, multi-agent code review in the cloud with /code-review ultra”, where “every reported finding is independently reproduced and verified” — roughly $5 to $25 and 5 to 10 minutes, over diffs up to 500 changed files and 8,000 changed lines by default.

Codex puts review in the composer with /review, and on the forge through its GitHub and GitLab integrations: “request reviews with @codex review, enable automatic reviews, and write custom review rules in AGENTS.md.”

Cursor ships Bugbot, which “reviews pull requests and identifies bugs, security issues, and code quality problems”, alongside Security Agents for the vulnerability pass.

One detail decides how much of your ceiling these lift: Claude Code’s Code Review check run “always completes with a neutral conclusion so it never blocks merging”. An automated reviewer that cannot block is a second opinion, not a gate. The gate is still yours to build.

Why review bandwidth is the Level 3 ceiling

Section titled “Why review bandwidth is the Level 3 ceiling”

Faros AI’s Acceleration Whiplash report, April 2026, is two years of telemetry across 22,000 developers and more than 4,000 teams, and it measures both halves of this rung at once.

Throughput rose: epics completed per developer +66.2%, task throughput per developer +33.7%, pull request merge rate per developer +16.2%. In the same window, quality and review fell behind: bugs per developer +54%, incidents per pull request +242.7%, code churn +861%, and 31.3% more pull requests merging with no review at all.

The review numbers are two distinct metrics and deserve their own names. Median time in review rose 441.5% — how long a pull request sits in review from open to done. Median time to first review rose 156.6% — how long it waits before anybody looks. The first is the queue; the second is the response time. Both grew because generation scaled and reading did not.

DX’s June 2026 panel names the load in a different unit: median pull request size went “from 44 lines to 72 lines per pull request between July 2025 and June 2026”. More diffs, bigger diffs, same reader.

Layered review is the standard answer: deterministic gates first, an automated reviewer second, a human last and only where judgment is required.

The deterministic layer is anything that exits non-zero — types, tests, lint, a schema check, a grep for the pattern you are migrating away from. It is free to run, impossible to charm, and it removes whole categories from the human’s queue. The automated layer is the tool from the section above, scoped to a diff size it handles well. The human layer is what remains: schema, auth, pricing, public interfaces, anything whose blast radius exceeds a revert.

What breaks when five agents share one reviewer

Section titled “What breaks when five agents share one reviewer”

The queue becomes the product. Time in review is the first metric to move, and it moves before anyone notices, because each individual pull request still looks reasonable.

Review turns into approval. Faros’ +31.3% unreviewed merges is what that looks like at the end. The honest version is a gate that says which classes may merge unread; the dishonest one is a reviewer who stopped reading and did not say so.

Parallel agents collide outside the repository. Worktrees isolate files, not ports, databases, caches or a shared dev server. Assign each agent its own port block and its own local state, or two green runs will disagree about the same machine.

Reviewers rubber-stamp the tool’s output. An automated reviewer that never blocks trains people to scroll past it. Pick the small set of findings it is allowed to fail the build on, and treat the rest as comments.

The diff is too big to review honestly. When a pull request exceeds what a person can hold, the answer is a smaller unit of work — one agent task, one concern — not a faster reader.