Self-Critique
PromptingDefinition
A pattern where Claude reviews its own output before finalizing it. Useful for catching obvious errors but limited: Claude tends to confirm its own reasoning due to anchoring bias. For high-stakes verification, use a separate Claude instance with independent context.
Example Usage
Ask Claude to review its draft for completeness and accuracy before presenting to the user — but use a separate API call with a fresh context for critical verification.
Why It Matters for the CCA-F Exam
Self-critique appears in Domain 4 questions about output quality patterns and agentic review architectures. The exam frequently tests whether candidates understand the anchoring bias limitation and when to escalate to a multi-instance verification setup rather than relying solely on self-critique.
In Depth
Self-critique is a prompting pattern where Claude is asked to review its own output before finalizing it. The simplest form is a two-turn sequence: generate a draft, then ask Claude to evaluate the draft for errors, gaps, or quality issues and produce a revised version. More structured variants give the critique step an explicit rubric — "check for logical consistency, completeness, and factual accuracy" — or separate the generation and critique into two sequential API calls.
The appeal of self-critique is obvious: it adds a review layer at near-zero marginal cost, using the same model that generated the output. For catching surface-level issues — incomplete sentences, missing required fields, obvious factual contradictions — it works well. The pattern improves output quality in measurable ways on tasks where errors are unambiguous.
However, self-critique has a well-documented limitation that every CCA-F candidate must understand: anchoring bias. When Claude evaluates its own output, it starts from the same reasoning chain that produced the output. If the underlying reasoning was flawed, the critique step is likely to follow the same reasoning and confirm the original conclusion rather than challenge it. The model tends to find what it is looking for: if asked "is this correct?", it tends to confirm; if asked "what is wrong with this?", it finds something. The quality of self-critique is therefore highly sensitive to how the critique prompt is framed.
For high-stakes verification tasks — financial calculations, legal analysis, security review, medical recommendations — self-critique alone is insufficient. The correct architecture is multi-instance verification: a separate API call with an independent context window, no access to the original reasoning chain, and an explicit adversarial or skeptical framing. This is sometimes called a critic agent or evaluator agent (see Evaluator-Optimizer Pattern).
The practical design decision is: use in-context self-critique for quality improvement on low-to-medium stakes tasks; use an independent-context critic for high-stakes verification. The Validation Loop (Retry-with-Feedback) pattern complements self-critique — self-critique is a qualitative review step, while validation loops handle structural correctness against a schema.
In the context of Multi-Pass Review Architecture, self-critique is the first pass; an independent instance with fresh context is the second pass when the stakes warrant it.
How It Compares
| Approach | Context | Anchoring Risk | Cost | Best For |
|---|---|---|---|---|
| In-context self-critique | Same conversation | High — same reasoning chain | Minimal (few extra tokens) | Low-stakes polish, surface error detection |
| Two-call self-critique | Separate call, original output included | Moderate — sees prior output | Low | Medium-stakes review, quality check |
| Independent-context critic | Separate call, no prior reasoning | Low — fresh reasoning chain | Moderate (full inference) | High-stakes verification, adversarial review |
| Human review | N/A | None | High | Irreversible actions, compliance, safety-critical |
Example
N/AHow It's Tested & Common Confusions
Exam questions present a scenario (high-stakes output, repeated errors surviving self-critique) and ask which architectural change would most improve reliability. The correct answer is almost always independent-context review, not more elaborate self-critique prompting. Expect questions that distinguish when self-critique is sufficient vs. when multi-instance verification is required.
Frequently Asked Questions
Why does self-critique fail to catch errors in complex reasoning?
Because the model's critique starts from the same underlying assumptions and reasoning path that produced the error. If the original reasoning was systematically wrong — a flawed premise, a misread requirement — the critique step is likely to follow the same logic and confirm the output rather than challenge it. This is anchoring bias: the model is anchored to its own prior output.
How does independent-context review differ from self-critique?
Independent-context review sends the output to a separate API call with a clean context window — no access to the generation reasoning chain. The reviewer model must evaluate the output on its merits alone, which breaks the anchoring bias. Framing matters too: "Identify every problem with this output" yields more critical evaluation than "Is this output correct?".