The idea is appealing. After the model produces an answer, ask it to review that answer, identify problems, and revise. Two passes instead of one, quality improves, everyone is happy.
It does work — on a specific class of task. On everything else it produces a model confidently endorsing what it just wrote, at double the cost, with the appearance of rigour.
What changed in 2026
- The evidence sharpened. Enough evaluation accumulated to make clear that reflection's benefit tracks the availability of external verification rather than being general.
- Verifier models emerged as an alternative. A separately-trained model scoring candidates proved more reliable than self-critique — see verifier models.
- Coding agents made it standard. Where tests provide ground truth, generate-run-fix loops became the default architecture.
- Cost scrutiny increased. As agent bills grew, reflection steps that did not demonstrably improve output came under review.
The dividing line
| Task |
External signal available? |
Reflection helps? |
| Write code |
Yes — tests, compiler, linter |
Substantially |
| Produce JSON to a schema |
Yes — validator |
Yes |
| Solve a maths problem |
Partly — recompute and compare |
Somewhat |
| Extract fields from a document |
Yes — check against source |
Yes |
| Summarise an article |
No |
Marginal |
| Write marketing copy |
No |
Little |
| Judge whether a response was good |
No |
Confirmation bias |
The pattern is unambiguous. When something outside the model can say whether the output is wrong, reflection becomes a loop with real feedback: generate, run the check, see the failure, fix it. The model is not evaluating itself; it is reading an error message.
When no such signal exists, the model is asked to assess its own output using the same reasoning that produced it. It tends to find the output reasonable, because it found it reasonable a moment ago. Where it does find fault, it may revise a correct answer into a worse one — which is a real observed failure, not a theoretical worry.
Making it work
Give it something to check against. Tests, a schema validator, a linter, the source document, a second retrieval. The check does not need to be sophisticated; it needs to be independent.
Use a separate critic prompt. Rather than "review your answer", frame a distinct role with distinct instructions — "you are reviewing this for factual claims not supported by the provided source". Different framing surfaces different problems, and it avoids the model simply re-reading its own reasoning approvingly.
Ask for specific defects, not a verdict. "Is this good?" invites agreement. "List every claim in this answer not supported by the source text" produces something actionable.
Cap the iterations. Two rounds is usually the point of diminishing returns. Unbounded reflect-revise loops burn budget and can oscillate between two versions.
Measure it. Run your evaluation with and without the reflection step. If scores do not move, you are paying double for nothing — and that is a common finding worth checking rather than assuming.
What it costs
Three model calls where there was one: generate, critique, revise. On a long agent run that multiplies across every step it applies to.
There is a context cost too. The critique and the revision both enter the conversation, so the accumulated context grows faster, which matters in long loops.
The pragmatic approach is selective application: reflect on steps that are consequential and checkable, not on every step by default. An agent that reflects before a write operation and not before a read is spending the budget where it can help.
Common mistakes
- Reflection on subjective output. Confirmation, at double cost.
- "Review your answer" as the critique prompt. Invites agreement.
- Unbounded loops. Oscillation and unbounded spend.
- Not measuring the benefit. Frequently zero, and nobody checks.
- Reflecting at every step. Apply it where the stakes and checkability justify it.
- Revising without evidence. A correct answer changed on a hunch is a regression.
FAQ
Does a separate model critic work better?
Usually yes, and the gain comes as much from a different prompt and framing as from different weights. Even the same model with a genuinely different critic role outperforms plain self-review.
How does this compare to a verifier model?
A verifier is trained specifically to score correctness, which makes it a stronger and more consistent signal than prompted critique. It is also more work to build — see verifier models.
Should coding agents always reflect?
Where tests exist, the generate-run-fix loop is not really reflection at all — it is reading real feedback, which is why it works so well. That is the shape to aim for.
Can reflection make output worse?
Yes, and this is the finding people find surprising. A model asked to find fault will often find something, and revising a correct answer to address an imagined problem is a genuine regression.
Where to go next
For the trained alternative to prompted critique, read verifier models. For the loop this sits inside, ReAct agents, and for measuring whether it helped, multi-turn evals.