The idea
When an AI assistant gives you a weak code outline or test plan, it is tempting to rewrite the whole request. A more controlled option is prompt iteration: use several focused requests instead of one all-purpose request.
In this lesson, a draft is an initial answer that you expect to inspect and improve. A criterion is a specific condition used to judge that answer, such as “covers empty input” or “does not change the public API.”
The loop has three stages:
- Ask for a draft.
- Ask for a review against named criteria.
- Ask for a revision using the review.
This is a practical form of prompt chaining: splitting a complex task across consecutive model calls. Anthropic describes self-correction as a common pattern: create a draft, check it against criteria, and refine it from that check. Its documentation also says explicit chaining remains useful when you need to inspect intermediate results or enforce a particular pipeline. Source
Plain English: Do not ask only for a better final answer. Ask for an answer, a concrete inspection of that answer, and then a targeted fix.
This is not a claim that the model truly understands its mistakes. “Self-correction” names the workflow: the model is given another opportunity to compare text with your stated requirements. You still decide whether the result is acceptable.
The value for developers is visibility. You can see whether a problem began in the initial approach, the review, or the revision. You can also keep a record of each stage and compare versions. For a tiny, unambiguous request, one prompt may be simpler. Use the loop when the checkpoint itself matters.
A small example
Example: You want a test plan for a function that parses a comma-separated list of integers.
First request: “Draft a unit-test plan for this parser. Do not write production code.”
Second request: “Review this plan against these criteria: empty input, whitespace, invalid tokens, negative numbers, duplicate values, and expected error behavior. List only missing or ambiguous cases.” Paste the draft below that request.
Third request: “Revise the test plan using this review. Preserve valid cases. Add tests only for the reported gaps. For each test, state input and expected outcome.” Paste both the draft and review.
The review stage has a narrow job. It is not “make it better.” It must compare a known draft with a known list of conditions. That makes disagreement easier to inspect. Before changing a prompt, define success criteria and ways to test them; Anthropic recommends doing this before prompt revision. Source
Try it
Set aside five minutes for this exercise. Pick a small task you already understand: a test plan, error message, README paragraph, or function outline.
Write three to five criteria before opening the assistant. Make each observable. “Has examples for invalid input” is more useful than “is high quality.” Then send three separate messages: draft, review, revision. Keep the text from each stage.
Finally, compare the first and final versions yourself. Which criterion caused a concrete change? Which criterion was ignored or interpreted loosely? That answer tells you what to improve next: the criteria, the input context, or the task itself.
Watch out
A model reviewing its own output is not an independent guarantee of correctness. It can repeat the same mistaken assumption in both stages. For code, run appropriate real tests, builds, or other checks before treating a revision as correct.
Prompt iteration also cannot resolve missing product decisions. If “correct error behavior” has no defined meaning, ask a person to decide it rather than asking the model to guess. More stages also mean more material to read and manage.
Finally, do not turn every task into a pipeline. Models can handle many multi-step tasks internally, while explicit chaining is particularly useful when you need inspectable stages or a forced sequence. Source