AnthropicClaude Certified Architect – Foundations2026-104.6 Design multi-instance and multi-pass review architectures
Distinguish independent review from self-review and effort
Completed by the knowledge check
Learning objective
Use an independent review instance without the generator’s reasoning history; distinguish it from same-session self-review or simply increasing thinking effort.
Core idea
A reviewer needs the requirement and the implementation, but not the conversation that persuaded the generator its implementation was correct. Separate those inputs before asking for a verdict. Anthropic’s Claude Code best practices state the rationale directly: fresh review context avoids bias toward code the model just wrote.
The distinction is architectural. A stricter instruction changes the review request; a separate context changes the evidence available to the reviewer. More thinking can improve analysis, but it does not remove the author’s assumptions from that evidence. The deciding property is whether the review inherits the generator’s reasoning history, not how strongly the prompt asks it to challenge that history.
See 3.6.5 for the CI session controls and Writer/Reviewer pattern. This lesson distinguishes self-review, increased thinking effort, and independent review by what each changes about the author’s influence on the verdict.
How it works
Separate requirements from the generator’s interpretation
A generation session can contain the original ticket, a plan, explanations of design choices, tool results, and the produced code. Claude Code’s context includes conversation messages, read files, and command output. Asking that session to review its work leaves those materials available.
Suppose a ticket requires rejecting refunds after 30 days, while accepting a refund on day 30. The generator restates the rule as rejecting refunds at 30 days and implements an inclusive rejection check. A subsequent self-review can judge the code against that restatement instead of the original boundary. The implementation and the plan agree; the implementation and the ticket do not.
The independent reviewer should receive the original boundary, the changed code, relevant surrounding code, and the review criteria. Exclude the generator’s plan and its explanation that the inclusive check is intentional. That explanation is the disputed interpretation, not evidence that the requirement changed.
Do not remove authoritative design constraints merely because the generator also read them. An approved specification describing time zones is relevant evidence. A generator’s unsupported claim that time zones do not matter is not. Choose inputs by their authority for the review, rather than by whether the author encountered them.
Establish independence through the actual request
Use the independent claude -p session controls in 3.6.5 rather than resuming the authoring conversation.
With the Messages API, independence is an explicit input choice. The API is stateless, and the caller supplies conversation history in messages. Construct the review request from the requirements and artifact instead of reusing the generation conversation’s messages array. A separate HTTP request containing the same authoring history still exposes that history to the reviewer.
Keep standing project context such as CLAUDE.md focused on stable conventions rather than an authoring narrative; see 3.6.5 for its persistence across review sessions.
Keep effort separate from context selection
The following choices alter different parts of the review:
| Choice | What changes | What remains to check |
|---|---|---|
| Ask the writer to review critically | The instruction in the existing conversation | The writer’s plan and assumptions remain available |
| Increase reasoning effort | The analysis effort allocated to the request | The review can still inherit the generator’s interpretation |
| Use an independent review instance | The conversation and artifact inputs | Requirements and surrounding code must be sufficient |
In Claude Code, --effort sets the reasoning effort for the session; available levels depend on the model. It changes effort within that session, not the history inherited by it. A resumed authoring session with a higher --effort still carries the authoring conversation, while a fresh review session can also use --effort.
For the API’s manual thinking mode, thinking.type: "enabled" and budget_tokens control a thinking budget on supported models. For adaptive thinking, the migration guidance uses thinking.type: "adaptive" and output_config.effort. Neither configuration specifies which conversation messages the application sends. Raising an effort setting is therefore not a replacement for selecting independent inputs.
Increasing effort targets insufficient analysis: the reviewer can examine more conditions or follow a longer chain of implications. Isolation targets a different failure: the reviewer accepts the author’s interpretation as the premise for that analysis. If the premise says day 30 is expired, deeper reasoning about how to reject expired refunds can still miss the requirement that day 30 is eligible. Choose the remedy from the observed failure, not from the length or confidence of the review.
Self-review remains useful as an early check for obvious omissions. Treat it as another opportunity to find a defect, rather than the independent challenge to a potentially mistaken interpretation. A fresh reviewer can also be wrong; isolation reduces one source of bias, not the need to verify findings.
Key distinctions and trade-offs
Separate instance versus different model: See 3.6.5 for why changing the model does not establish context independence.
Authoring history versus review evidence: Exclude planning and self-justification. Include requirements, approved constraints, code, and relevant callers. An isolated reviewer starved of evidence can report imagined defects or miss real ones.
Self-review versus independent review: Self-review is inexpensive because the session already has the implementation context. Independent review costs another invocation and a deliberately assembled evidence set, but can challenge the premise the writer accepted.
Fresh context versus stronger reasoning: These are compatible choices. You can allocate more reasoning to the independent reviewer when warranted. Do not spend that effort only in the writer’s context and call the result independent.
Architecture / decision scenario
A Claude Code CI job generates a refund eligibility change. The ticket accepts refunds through day 30, but the generator’s plan treats day 30 as expired. The same-session review approves the resulting boundary check. The team considers adding a harsher review instruction, increasing thinking effort with --effort, or starting a separate reviewer.
Choose the separate reviewer. Its input contains the ticket’s original wording, the changed eligibility code, the date calculation it calls, and a criterion requiring checks on both sides of each boundary. It does not contain the generation transcript or the author’s explanation of the cutoff. The reviewer can compare behavior on days 29, 30, and 31 directly against the requirement.
If the team implements review through the Messages API, it builds a dedicated messages input for that evidence. If it uses Claude Code, it starts the review through claude -p without resuming or forking the generation conversation. The fresh Claude Code reviewer can also receive --effort; increasing it on a resumed writer session would leave the mistaken interpretation in context. A larger thinking allocation can supplement either independent path, but does not decide its independence.
Return the review finding to the writer as feedback, following Anthropic’s Writer/Reviewer pattern. Before accepting the correction, verify the claimed boundary behavior; see 4.6.3. For a large change, partition the independent review rather than forcing all analysis into one call; see 4.6.2.
Common exam traps
- Treating “review your work critically” as removal of the author’s reasoning history.
- Assuming a larger thinking budget creates a different evidence set.
- Calling a resumed conversation independent because
--fork-sessiongives it a different ID. - Copying generation
messagesinto a second API request and calling it a fresh review. - Omitting the original requirement while retaining the author’s paraphrase.
- Removing surrounding code so aggressively that the reviewer cannot verify the claimed behavior.
Where the exam guide differs
The exam guide contrasts independent review with “extended thinking.” Read that contrast as context isolation versus more reasoning, rather than as a universal instruction to configure budget_tokens. Anthropic documents manual thinking.type: "enabled" with budget_tokens as deprecated on Claude 4.6 models, where requests still succeed, and unsupported on Claude 4.7 and later models, where requests return a 400 error. Its migration uses adaptive thinking and output_config.effort. The exam’s architectural distinction holds under either supported thinking mode.
What to remember
Give the reviewer authoritative requirements and implementation evidence without the generator’s reasoning history. Independence comes from the context supplied, not a model change, a different session ID, or a larger thinking allocation. Keep enough surrounding code to test the interpretation rather than merely challenging it in prose.
Knowledge check
A Claude Code CI job implements a ticket that deactivates accounts inactive for “more than 90 days”. The authoring plan restates the rule as “90 days or more”, and a review run in the same session approves the matching check. You need a review that can catch this kind of misreading. Which change does that?
--effort to max within the authoring sessionclaude -p review with the ticket, diff, and criteria--fork-session and request a reviewclaude -p session compares the code with the ticket’s own wording. More effort and a sterner instruction both leave the plan in context, and --fork-session gives a resumed conversation a new ID while keeping its history.Your API pipeline reviews generated code with a second Messages API request. That request reuses the generator’s messages array, appends a final user turn asking for a critical review, and names a different model. Which change makes the review independent of the generator’s reasoning?
messages from the requirements and changed code onlyoutput_config.effort on the review requestmessages the caller sends. A separate request that carries the authoring history still exposes that history. Independence comes from assembling a new input from the requirements and the artifact; a model change, an instruction, or more thinking leaves the same evidence in place.An independent reviewer will check a billing change. Available inputs are the original ticket, an approved specification on time-zone handling, the generator’s plan explaining why it ignored time zones, the changed code, and the date helper that code calls. Which input set should the reviewer receive?
A fresh-context reviewer already receives only the ticket, the diff, and the relevant callers. It misses a defect that appears only after five nested conditions, and its report shows it traced the first two branches and then gave a general verdict. Which change targets this failure?
--effortReferences
- Anthropic, Best practices for Claude Code
- Anthropic, CLI reference
- Anthropic, Using the Messages API
- Anthropic, Extended thinking
- Anthropic, Claude Certified Architect – Foundations Exam Guide