Why self-critique is shaky

Why the model's own critique is shaky

The toy critic has two numbers: how often it finds a real problem, and how often it invents one in a part that was fine. Varying both:

(Compare with 47% for not looking again.) Read it like this:

• A critic that finds few problems and invents some does worse than not looking at all (the red cell).
• Even a very good critic loses ground as false alarms rise: at 90% detection, going from 0% to 20% inventions costs 29 points.
• A critic that only finds, never invents, is a gain at any detection rate. So reduce false alarms by asking for specific, checkable claims ("quote the sentence that breaks the rule"), not an overall impression.

Why this happens with real models, in plain words: the critic and the writer share the same blind spots; a model that does not know the refund rule will not notice a refund that breaks it. A model asked "what is wrong with this?" feels pushed to find something. And a model asked "is this OK?" tends to agree with itself. The producer and critic split helps with some of this (a different instruction, sometimes a different model), but it is still text judging text.

Put the critic outside whenever you can

Where could the second look come from?

Rule of thumb: if you can write a check, write it; use a model critic for what you cannot check, and measure that critic like any other component. The messages from checks should say what is wrong and what is expected (the example's refund message), so the revision has something to act on.

Stopping rules

A reflection loop needs three ways to end:

1. Success: all checks pass (outside check) or the critic reports nothing (model critic: weaker, since it may simply be missing problems).
2. A round cap (three in the example, five at most): beyond it the gain is small and the cost keeps growing.
3. No progress: the same problems appear twice in a row, or the number of problems stopped dropping. Then return the best draft with its open problems, or hand over to a person.

Also keep the best draft so far, not only the last. A revision can fix one problem and cause another; in the example 8% of fixes did.

Lessons that last: the Reflexion idea

Reflection inside one job fixes that job. Reflection across jobs keeps what a failure taught. The pattern (named Reflexion in research papers) is to write a short lesson from each failure ("dates must be written year-month-day") and put the lessons in the next prompt.

In the example, each failed check adds a lesson, and a lesson cuts that slip's rate to 30% of its normal value. Over 60 jobs in a row, looking only at first drafts:

(The "with lessons" curve is already ahead in the first 15 jobs because the lessons start working from the second job on.) Lessons turn the checks into training signal for a prompt, not for model weights. Three cautions: lessons that are too many or too general bloat the prompt (Level 7, on memory and context, covers this); a wrong lesson persists, so keep each lesson tied to evidence and drop it if it stops helping; and lessons do not replace the checks, because a slip that returns still has to be caught.

A checklist

1. Can I write a check? If yes, use it as the critic. If no, add a rubric and test the critic on known good and bad examples.
2. Name the problem and the expected value in each message.
3. Cap the rounds; stop when nothing changes; keep the best draft.
4. Only change what was flagged. A broad "improve this" invites damage.
5. Count the cost: a model critic doubles the calls per round.
6. Log each round (draft, critique, revision) so you can see which step helps (module 7).
7. Measure spoiled drafts, not only rescued ones.

For the curious Checks that matched inside longer numbers

The refund check looked for $8 anywhere in the text, so $80 would have passed, and the same was true of an order id followed by extra digits. The checks now require that no digit follows. The published tables did not change, because the writer in the example never produced those cases, but a real writer can.