Independent Review Instances vs. Self-Review

1.Why the generator is a weak grader of its own work

By the time a session finishes writing code, its context holds every decision it made along the way: the approach it picked, the edge cases it decided not to handle, and the reasons behind each choice. Ask that same session to review the code and it reads the diff through all of that. Claude Code's best-practices guide shows what accumulated context does to quality. In the "correcting over and over" anti-pattern, "Context is polluted with failed approaches." The fix it gives is a clean context, not more instructions in the same one.

This doesn't make self-checks useless. The prompting guide recommends appending a line like "Before you finish, verify your answer against [test criteria]" and notes that "This catches errors reliably, especially for coding and math." It also says Claude Opus 5 verifies its own work well without being told to. A self-check like this is still the same mind marking its own homework, though. Claude Code's verification options make the difference clear. A check can run inside one prompt, a separate evaluator can re-check a /goal condition after every turn, a Stop hook can run a script, or a second opinion can come from a fresh model.

A note on scope: the exam guide claims that independent instances beat extended thinking as well as self-review instructions. The sources for this lesson compare independent review only with self-check instructions and same-session iteration. They don't discuss extended thinking.

The core limitation is that a model retains its reasoning context from generation. In the evaluator-optimizer cookbook, a generation turn begins with the model's own thoughts, for example "To achieve O(1) for getMin(), we need to maintain a second stack that keeps track of minimums." Once that reasoning is in the session, every later turn in the same session reads the code with that plan already in view. The code looks like the plan carried out, so the decisions behind it feel settled and the model is less likely to question them. A choice that was wrong but felt justified at writing time reads as justified again at review time.

A reviewer outside the session lacks that reasoning, so it has nothing to defer to. The Outcomes cookbook builds its grader this way: it "can't see the writer's reasoning and has no idea what shortcuts were taken," so it has to judge the artifact against the criteria. Be precise about what the sources establish. They show the design, where the grader is deliberately kept out of the writer's context. They do not measure how much less likely a model is to question its own decisions, so treat that as the exam guide's framing of why the design exists, not as a quantified result.

Sources1234

2.What makes a review instance independent

Independence depends on the reviewer's context, not its name. In the Agent SDK, each subagent runs in its own conversation, which starts fresh unless the subagent is a fork. Its intermediate tool calls stay inside it, and only its final message goes back to the parent. A reviewer subagent that starts fresh sees the diff and whatever you put in its prompt. It doesn't see the reasoning that produced the diff.

The Managed Agents Outcomes feature is built around the same idea. After each writer turn, the platform spins up a fresh grader with the same model and tools as the writer. The grader can't see the writer's reasoning and has no idea what shortcuts the writer took. It shares the writer's capabilities but none of the writer's context, and that combination is the point.

So picking up the generating session again, or forking it, doesn't give you an independent reviewer, even if you change its instructions. The conversation that wrote the code is still there.

Sources54

3.Wiring a second instance to review generated code

Claude Code documents two practical ways to do this. The first uses two sessions. Session A (the writer) implements a rate limiter. Session B (the reviewer) gets a focused prompt: "Review the rate limiter implementation in @src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with our existing middleware patterns." You then paste B's output back into A: "Here's the review feedback: [Session B output]. Address these issues." B never saw A's reasoning, so it reviews only the code.

The second uses a reviewer subagent in the same session: "Use a subagent to review the rate limiter diff against PLAN.md." The subagent gets its own context and returns only its findings. Define it as read-only so it can analyze code but can't change it. The Anthropic cookbook calls this a generator/evaluator loop, in which "one LLM call generates a response while another provides evaluation and feedback in a loop."

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

---
name: code-reviewer
description: Reviews code for quality and best practices
 ? : Read, Glob, Grep
model: sonnet
---

Sources13

4.Making the independent reviewer actually check

A fresh context alone doesn't guarantee a useful review. The Outcomes cookbook warns that "The default failure mode is a grader that approves everything." A criterion like "check that the brief covers demand charges" lets the grader skim, spot a matching paragraph, and approve without opening a single source. A criterion that says where to look and what has to be there forces the grader to produce evidence.

The cookbook's rubric principles apply directly to code review. Require concrete evidence, such as a file:line reference, before passing anything. Anticipate the shortcuts the writer is likely to take. Give the reviewer a no-fire list so it doesn't thrash on style nits, pre-existing issues, or scope creep, and have it self-check each finding before raising it. The Claude Code version of this is the reviewer prompt that ends with "Report gaps, not style preferences." The trade-off is lopsided: a grader that is too strict costs you an extra loop, while one that is too lenient lets the bad version ship.

Sources14

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Continuing or forking the session that generated the code, then giving it a reviewer prompt, counts as an independent review.Why is that wrong?

   Independence comes from a fresh context. A subagent starts fresh only when it isn't a fork, and a continued session still holds the generator's reasoning.

   Covered in What makes a review instance independent

2. 2.Adding a "verify your work" instruction to the generating prompt gives the same assurance as a second reviewer.Why is that wrong?

   Self-checks catch errors, but the worker still grades itself. The second-opinion pattern uses a fresh model specifically so that the worker isn't the grader.

   Covered in Why the generator is a weak grader of its own work