Send a second wave of subagents to attack the first wave's findings

You ran a review pass. It came back with fourteen findings. Three of them are real, two are style opinions dressed as bugs, and the rest are the reviewer inferring behavior from a function name. By the third false alarm you have stopped reading carefully, which means you will also skim past the one that mattered.

The fix that people who build this stuff reportedly use is structural, not a better prompt: run review in two rounds, and make round two adversarial. Round one is parallel and broad — separate subagents, each on its own axis. Round two exists only to attack round one's output.

The shape

Round one, in parallel, one subagent per axis:

• Style and conventions — does this match how the repo already does things?
• Prior art — comb the project history. Does this already exist somewhere? Was it tried and reverted?
• Bugs — the obvious correctness pass.

Round one produces candidates, not findings. Then round two: a batch of subagents whose entire instruction is falsify these. For each candidate, go to the source, reproduce the failure path, and report back whether it survives. Anything that cannot be reproduced from actual code is dropped, not softened.

The two-round part is what people skip, and it is the part that does the work. A single pass has no incentive to delete its own output — every agent that finds nothing feels like it failed. A round-two agent's success condition is the opposite, so it kills candidates cheerfully.

What the docs already give you

The mechanism is documented; the practice of assembling it yourself is not.

sub-agents.md describes exactly this nesting shape as a supported use: nested subagents suit a delegated task that itself splits into parallel subtasks, "such as a reviewer subagent that dispatches a verifier per finding," so intermediate output never reaches your main conversation. By default a subagent can spawn its own subagents up to three layers below your conversation, which is enough for main → reviewer → per-finding verifier. CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH changes the cap; set it to 1 to turn nesting off.

That last property matters as much as the verification does. Fourteen candidates and their rebuttals never touch your context — only the survivors come back.

That default is recent, so check your version before you build the nested shape. env-vars says the variable "Requires Claude Code v2.1.217 or later" and that "In v2.1.217 through v2.1.218, the default was 1, so a subagent couldn't spawn its own unless you raised the limit; v2.1.219 raised the default to 3." Below v2.1.219 the three-layer default is not what you get, and the docs say nothing about the depth on clients older than v2.1.217. The two-round structure survives that: dispatch both waves from your own conversation instead of nesting them, and pay the context cost of the candidates passing through you.

Before you build it, check whether you need to

Most of this now ships as a product, and one of the shipped versions does the same two-phase thing.

Read that middle column carefully, because the sentence everyone quotes belongs to a different surface. code-review.md describes Code Review on GitHub — the app you install on a repository — as multiple agents analyzing in parallel on Anthropic infrastructure, each looking for a different class of issue, "then a verification step checks candidates against actual code behavior to filter out false positives." The local /code-review command lives in a separate section of the same page, which says it "reviews a diff in your terminal without installing the GitHub App" and "runs as a background subagent with its own context window" — and describes no verification step of its own. What it gives you instead is an effort dial: at "low and medium, the review reports only the findings it's most confident in, so you see fewer false positives." Of the two you can launch from your own session, ultrareview.md is the one that promises the falsification step: every reported finding is independently reproduced and verified.

The paired habit: do not hand control back on red

The same setup is usually described with a Stop hook that runs the test suite and, on failure, tells Claude to fix it rather than end the turn. That still works, and hooks.md documents the guard rails: Stop hooks receive stop_hook_active, and Claude Code overrides the hook and ends the turn after 8 consecutive blocks. A hook that does not check that field will burn all eight on a condition that can never resolve.

INPUT=$(cat)
if [ "$(echo "$INPUT" | jq -r '.stop_hook_active')" = "true" ]; then
  exit 0
fi

There is now a lighter option for the session-scoped case. /goal sets a completion condition that a small fast model checks after every turn, and clears itself when the condition is met, judged impossible, or a turn hits an error you have to fix. goal.md calls a Stop hook the right tool when you want the rule in settings for every session, or a deterministic script check; /goal when you want it for this session only.

What is unverified here

The two-round structure is attributed to Boris Cherny describing his own setup on the Every podcast in October 2025 — roughly three round-one agents and about five round-two attackers. No one has re-run that configuration and measured it. The counts in particular are one person's recollection of one habit, not a tuned parameter, and the whole account predates the shipped review commands that took over part of the job.

What is solid: the docs corroborate every mechanism the tip leans on — nested reviewer-dispatches-verifier subagents (on v2.1.219 or later for the three-layer default), parallel-agents-plus-verification as the architecture of Code Review on GitHub and of /code-review ultra, the Stop hook and its 8-block cap. What is not established is the marginal value of hand-rolling it now that the built-ins exist.

What would settle it: run both over the same diff and count. Take a branch with known planted bugs, run /code-review high on it, then run your own two-round version, and compare true positives and false positives against the planted set. That is a half-hour experiment, and nobody in this tip's chain of custody has done it.