Generate, critique, revise: when a self-verification loop pays for itself

What it is

A self-verification loop asks the model to produce a draft, then to critique it, then to revise it in the light of the critique, possibly several times. The Self-Refine paper describes this with a single model acting as generator, refiner and feedback provider, without additional training. Anthropic's engineering guide lists the same shape as the evaluator-optimizer workflow: one call generates, another evaluates and gives feedback, in a loop. The cited paper on self-correction adds the caveat that matters for practice: in its reasoning experiments, models struggled to self-correct without external feedback, and at times performance degraded after self-correction.

Why it matters

The loop is cheap to add and expensive to run. Each round is at least two calls, and the draft is part of the input of both, so cost grows with the length of the output and the number of rounds. A loop that revises a correct answer into a wrong one costs money and quality at once. Whether the loop helps depends on what the critic can see.

How to apply

• Give the critic an external signal: test output, a schema validator's message, a diff against the specification, a fetched source. A critique that only re-reads the draft is the case the self-correction paper warns about.
• Fix the rubric before the first round (what "wrong" means for this task) and make the critic answer it point by point; a free-form "find problems" prompt finds problems in anything.
• Bound the rounds, usually to one or two, and stop early when the critique reports nothing actionable or repeats the previous one.
• Separate the roles by prompt, and where the budget allows by model, so that the critic does not share the draft's assumptions.
• Log every critique and the change it caused; a critic whose findings are never acted on, or always acted on, is miscalibrated.
• Measure on a held-out set with and without the loop before making it a default; the cost is certain, the benefit is task-dependent.

Pitfalls

Revision drift: each round changes wording the critic did not object to. A critic that scores its own previous revision. Using the loop as a substitute for tests that could run in milliseconds. Counting the loop's calls outside the task's cost budget.