One of the most copied prompt patterns is a simple wrapper: before answering, the model lists ways its first draft could be wrong, then writes a final answer that fixes them. We call it the "red-team yourself" prompt. It is cheap, works with any model, and often catches real mistakes.
It also has a well-documented failure mode: on some tasks, asking a model to doubt itself makes it change correct answers into wrong ones. This guide explains how the pattern works, what research says about self-critique and self-correction, when to use it, and when to choose something else.
The basic prompt
Three details matter. The critique must be specific (three concrete ways, not "check your work"). The model must judge each critique rather than assume every concern is valid. And the final answer must be clearly separated so your code or reader can find it.
Why self-critique can help
Generating an answer and evaluating an answer are different tasks, and models are often better at the second. When a model writes a draft, it commits to each token in sequence. When it reviews the complete draft, it can see the whole answer at once, notice a requirement it skipped, or spot that step four contradicts step two.
Research supports this for some task types. Madaan et al. (2023), "Self-Refine," showed iterative self-feedback improving outputs on tasks such as code optimisation, dialogue responses and constrained text generation. The common thread is that these tasks have checkable criteria: did the code get faster, does the text include all required words, is the tone right.
Why self-critique can backfire
Huang et al. (2023), "Large Language Models Cannot Self-Correct Reasoning Yet," examined self-correction on reasoning benchmarks without any external feedback. They found that asking models to review and revise their own answers often failed to improve accuracy and sometimes reduced it, because models changed correct answers to incorrect ones about as readily as they fixed errors.
The intuition: when there is no external signal, a request to "find problems" is itself a signal that problems exist. A model that is uncertain may "fix" an answer that was right. Self-critique is only as good as the model's ability to tell real errors from imagined ones.
| Task | Likely effect | Why |
|---|---|---|
| Checklist requirements (include X, Y, Z) | Helps | Missing items are easy to verify |
| Code with tests or a runnable check | Helps | External feedback anchors the critique |
| Writing quality, tone, length | Usually helps | Criteria are explicit |
| Arithmetic or logic with one right answer | Mixed, can hurt | Model may "correct" a right answer |
| Factual recall | Mixed | Model cannot verify facts it doesn't know |
Make the critique grounded
The most reliable way to improve self-critique is to give it something external to check against.
- Requirements lists. Ask the model to check the draft against an explicit list of requirements you provide, item by item.
- Tool feedback. For code, run tests or a linter and feed the results into the critique. Real error messages beat imagined ones.
- Source documents. For grounded answers, ask the model to verify each claim against a quoted passage; see prompting for citations that check out.
- Conflict checks. For rule-heavy tasks, ask the model to list conflicting requirements before answering, as in our contradiction-trap eval.
Five variants for common tasks
Requirements check
Pre-mortem for plans
Counterargument for analysis
Ask the model to write the strongest case against its own conclusion, then decide whether the conclusion survives. This is useful for recommendations and reduces one-sided answers.
Keep-or-change gate for single answers
For tasks with one correct answer, add an explicit bar: "Change the answer only if you can point to a specific error. If you cannot, keep the original answer." This directly targets the right-to-wrong flip.
Separate reviewer
Use a second call, ideally with a different prompt or model, to critique the draft. Separation reduces the tendency to defend or reflexively change the first answer. If you do this at scale, calibrate the reviewer as you would any model grader.
Where to put the wrapper in a production system
Self-critique does not have to run on every request. Three placements cover most needs.
Inline, for high-stakes outputs only. Apply the wrapper to the small share of requests where an error is expensive: contract summaries, financial figures, medical or legal information, and anything sent to customers without review. Route everything else through the normal prompt.
As a second pass on failures. Run the cheap prompt first, validate the result in code, and only invoke the critique step when validation fails or confidence signals are low. This keeps the extra cost proportional to the actual error rate.
Offline, as a quality monitor. Run a critique prompt over a daily sample of production outputs and flag the ones it finds problems with for human review. This does not slow down users at all, and it gives you a stream of real failure cases to add to your eval set.
Whichever placement you choose, log both the draft and the final answer. When the critique changes an answer, you want to be able to see what it changed and whether it was right to.
Measure before you adopt it
Self-critique adds tokens and latency, often 50 to 100% more output, so it should earn its place. Run your eval set with and without the wrapper and track three numbers:
- Wrong to right: answers the critique fixed.
- Right to wrong: answers the critique broke.
- Cost and latency increase.
If right-to-wrong flips are close to wrong-to-right fixes, the wrapper is adding cost without benefit. On reasoning tasks, sampling several answers and taking a majority vote (self-consistency) is often a better use of the same tokens.
Frequently asked questions
Does asking an LLM to check its own work improve accuracy?
Sometimes. It tends to help when the task has explicit, checkable criteria or external feedback such as test results. On pure reasoning tasks without feedback, research has found self-correction can fail to help or even reduce accuracy.
What is the "red-team yourself" prompt?
It is a self-critique wrapper in which the model drafts an answer, lists specific ways the draft might be wrong, judges each concern, and then writes a corrected final answer.
How do I stop the model from changing correct answers?
Require a specific, named error before any change, keep the original answer by default, and ground the critique in external information such as requirements, tests or source documents.
Is self-critique worth the extra cost?
Only if your evals show it fixes more answers than it breaks. Measure wrong-to-right and right-to-wrong changes, along with token cost and latency, on your own tasks.
