How to Prompt AI to Check Its Own Work

How to prompt AI to check its own work: ask it to do three separate things instead of one vague one. List the assumptions it made, argue against its own answer, and redo any calculation using a different method. Bundling all that into "double check your answer" produces a model that rereads its own text, agrees with itself, and hands back the same answer with more confidence. Specific prompts force it to generate new information instead of restating old information, and new information is what actually catches an error.

Why "double-check yourself" doesn't work

Ask a model to double-check its own answer and it usually rereads the same reasoning, finds it convincing because it wrote it, and confirms it. This is not laziness, it is architecture: there is no separate verification process outside the generation process. "Check your work" asks the same pass that produced the error to also grade it, using the same context and often the same mistaken premise.

The fix is asking for output the first answer cannot satisfy by being repeated. Four patterns do this: listing assumptions, arguing against the answer, re-deriving a number differently, and naming what would prove the answer wrong. Each forces new work, not a restatement, and each sits downstream of the full prompt engineering playbook.

Four ways to prompt AI to check its own work

1. Ask it to list its assumptions

Most wrong answers are not wrong because of bad logic, they are wrong because of an unstated assumption never confirmed. A generic double-check rarely surfaces this, the assumption feels obvious to the model. Enumerating assumptions separates what it inferred from what it was told.

Before:

What's the fastest way to migrate our Postgres database to a new region with minimal downtime?

The model gives a confident replication plan, no caveats.

After, add:

List every assumption you made about our setup that, if wrong, would change your recommendation.

It now lists: a Postgres version supporting logical replication, no unsupported data types like large objects, an app tolerant of a brief write pause, superuser access to create a publication.

That surfaces a real gap: on an older Postgres version the plan is unusable. A plain double-check would not have found this, since the model was not wrong about the plan, only about a precondition it never stated.

2. Ask it to argue against its own answer

Asking for weaknesses usually gets hedged, generic caveats. Asking it to build the strongest case against its own conclusion, arguing the other side, produces a real counter-argument, since it now has a concrete adversarial role instead of open-ended reflection.

Before:

Should we use a message queue or a direct API call between these two services?

The model recommends a queue, citing decoupling and retries.

After:

Now argue the opposite. Make the strongest case for a direct API call instead, and say what would have to be true for that to be the better choice.

It now produces: if the caller needs a synchronous response, such as an order confirmation before checkout completes, a queue adds latency for no benefit; it only wins if the caller can move on without waiting.

That single question, does the caller need to wait, is the deciding factor the first answer skipped by defaulting to the more common architecture.

3. Ask it to re-derive a number a different way

Numeric answers are the easiest place for a self-critique prompt to earn its keep: re-derivation is objective, and two independent methods landing on the same number beats one confident derivation.

Before:

We had 214 signups last month and 189 the month before. What's the growth rate?

The model answers: "13.2% growth."

After:

Recalculate that using a different method than you just used, and tell me if the two agree.

Where this catches an error: if the first pass had quietly divided by 214 instead of 189, a reversed denominator, a second derivation using a different formula produces 11.7% instead of 13.2%. The mismatch is the signal; rereading the same arithmetic never reveals which base was used.

4. Ask it to name what would prove it wrong

This works for open-ended claims rather than numbers or plans. Ask what evidence, if it existed, would contradict the answer. If it cannot name anything concrete, that is informative too, it usually means the answer is a plausible generality rather than a claim grounded in specifics.

Before:

Is this function thread-safe?

The model asserts that it is.

After:

What would you need to see in this code to conclude it is NOT thread-safe?

A useful answer names something checkable: shared mutable state with no lock, a check-then-act sequence split across two statements, a static field written outside a synchronized block. If none apply, the original answer is more credible; if one is present, the "yes, thread-safe" answer was wrong, found only by asking for the falsifying condition instead of a restatement.

Where this breaks down

None of this makes self-review as reliable as a second pair of human eyes. A model can list assumptions and miss the one that matters. It can argue against itself and still talk itself back into the same wrong answer, more confident than before. Re-derivation only helps when the methods are genuinely independent; sharing the same wrong premise, two derivations agree with each other and are both wrong.

Watch for confident doubling down. Pushed hard on a self-critique prompt, a model sometimes builds an even more elaborate defense of the mistake, because now it is generating justification, not checking anything. That instability is related to why the same prompt gives different answers between runs; the same variance behind inconsistent answers also makes any single self-review unreliable.

Self-critique prompting is a filter, not a guarantee. It catches errors from unstated assumptions, unexamined defaults, and arithmetic slips, not a wrong premise baked into the question, or a training-data gap the model cannot detect from inside its own reasoning. For that, you still need external checks, real sources, or someone who knows the domain.

Putting it into one workflow

None of the four prompts needs to run every time. One is usually enough for a low-stakes question. For a decision, a report number, or code that ships, run more than one and compare results; an answer surviving an assumptions check, a counter-argument, and an independent re-derivation is a different signal than one that only survived "are you sure."

In a repeated workflow, treat the critique step as part of the prompt and test it the same way, the core idea behind getting consistent output across runs. If it keeps turning up the same error, that usually means the base prompt needs fixing, not a fifth pattern, and the broader troubleshooting checklist for a bad prompt is the more useful next stop.

None of these four patterns substitutes for spotting a hallucinated answer in the first place. A model that fabricated a fact will often defend it just as confidently under a self-critique prompt, since the fabrication never came from a reasoning error these prompts catch. Self-critique checks the reasoning behind a claim, it does not verify the claim was ever true.

Questions people ask

Does asking AI to double-check its answer actually work?

Rarely, on its own. A generic "double-check this" prompt asks the model to reread its reasoning with no new information, so it tends to confirm what it already said. Specific prompts, listing assumptions, arguing the other side, re-deriving, force a genuinely different pass instead of a repeat.

Can AI reliably catch its own hallucinations?

No, not reliably. A model that hallucinated a fact has no hidden correct answer it is withholding, it generated the wrong fact because it looked plausible, and reviewing that generation with the same pattern-matching often looks just as plausible the second time.

What's the best prompt to make AI verify its own answer?

There is no single best prompt, there are three or four for different failure types: "list every assumption that, if wrong, would change your answer" for missing context, "argue the strongest case against your own answer" for weak reasoning, and "recalculate using a different method" for numeric errors.

Why does AI sometimes insist it's right even after I point out an error?

Pointing out an error without giving the model a new way to check its work often triggers a defense rather than a real re-examination; it treats pushback as something to respond to, not new evidence. A concrete re-derivation task or adversarial role produces a more honest re-check than asking "are you sure."

Should I use self-critique prompting on every AI output?

No. It adds a step, and for low-stakes questions the added time is not worth it. Reserve it for output that feeds a decision, a calculation, or code that ships, and pick the pattern matching the likely failure mode instead of running all four every time.