How to check an AI's answer

Why an answer is harder to check than an article#

There is a companion to this page about whether the thing you are reading is out of date. That job is easier than this one, and it is worth being clear about why, because the difference decides the method.

A published page sits still. It carries a date you can find, a name you can weigh, and an audience. If it is wrong there is at least a chance somebody already noticed: a correction, an angry comment, a better page ranking above it. None of that machinery exists around an answer generated for you. No date, no byline, no other readers, no comments, no corrections log.

Then there is the part that does the real damage. A wrong article is wrong for everyone in the same way, which is precisely what gives somebody the opportunity to catch it. A wrong answer is wrong for you alone. It was shaped to your question, uses your vocabulary, and addresses your actual situation, which is exactly what makes it read like the work of someone who understood the problem. That fit is not evidence of anything. Fitting the question is the thing these systems are best at, and it is independent of whether the content is true.

You also cannot re-read it in the way you can re-read a page. Ask again and you get a different answer, which turns out to be useful, and is the basis of one of the better checks below.

Confidence tells you nothing here#

Most people read confidence for competence, and with other people that is a reasonable heuristic. Someone who is unsure hedges, slows down, adds qualifiers, says the bit about not being certain. Those signals are largely involuntary and largely honest.

They do not survive the trip. A model's register does not move with its certainty. The same level, fluent, well-organised prose arrives whether the claim underneath was stated in ten thousand documents or assembled just now from the shape of your question. So the reading skill you have spent your life developing is not merely weakened here, it points the wrong way: the invented passage is often the most fluent thing on the page, because there was no awkward source material constraining how it came out. → Hallucination

Check what carries weight, not everything#

Verifying every sentence costs more than not using the tool at all, so any honest method has to start by throwing most of it away. The useful question is not "is this true" but "what happens if this is false".

Worth checking: anything you will act on, spend money against, put in front of somebody else, or repeat later as a fact. Anything that will be embarrassing to have wrong in six months, when you will have long forgotten where you got it.

Not worth checking: the reasoning, the structure, the phrasing, the summary of something you already know. Those are the parts these systems are reliably good at, and they are also the parts you can evaluate yourself while reading, without leaving the page.

The failures worth knowing by name#

Different kinds of claim fail in different ways, and knowing which failure to expect is most of the work.

A reference that exists is not a reference that supports. There are two separate failures here and people only check for the first. A citation can be invented outright, which a search reveals in seconds. Or the citation can be entirely real, correctly formatted, genuinely on the subject, and simply not contain the claim attached to it. The second is more common once a model can search, harder to catch, and worse, because everything about it survives a cursory check. Open the source and find the sentence.

Numbers deserve a prior question: could it have known? Before asking whether a figure is right, ask whether it was ever knowable. Prices, limits, model names and anything else that changes after a training cutoff cannot be recalled correctly except by luck, and a model with no search tool has no way to notice that it is guessing. → Training cutoff

Identifiers look correct right up until they do not work. Model IDs, API endpoints, function names, package names, configuration keys. These are generated by the same machinery that generates prose, so they come out plausible, well-formed, and consistent with the naming conventions of the thing they are meant to belong to. They fail later, somewhere else, for reasons that look unrelated to the answer that produced them.

Quotes are paraphrases until proven otherwise. A fluent restatement presented between quotation marks is a standard failure. If you are going to reproduce a quotation anywhere it matters, search for the exact string rather than the gist.

Negative claims are the hardest of all. "There is no way to do this", "no library supports that", "the documentation does not mention it". Absence is not the kind of thing that can be reliably recalled, and it cannot be confirmed by finding something. Treat a confident negative as the least reliable sentence in any answer. → What AI is actually bad at

Ask it twice, in a fresh session#

The cheapest check available, and the one almost nobody does. Open a new conversation, ask the same question, and compare. Anthropic's own guidance for developers lists this under Best-of-N verification: "Run Claude through the same prompt multiple times and compare the outputs. Inconsistencies across outputs could indicate hallucinations."

It works because of the difference between recalling and assembling. A fact the model genuinely has tends to come back the same way each time. A detail that was constructed to fit your question tends to be constructed slightly differently on the second pass: a different figure, a different author, a different function name. Watch the specifics rather than the overall shape, since the shape will match either way.

It has to be a fresh session. Asking again in the same conversation shows the model its previous answer, and consistency with itself is exactly what you were trying to test around. → Context windows

Its own check is not your check#

Asking a model to verify its own answer is genuinely worth doing, and Getting better results covers how to ask so that it works: a named standard rather than "are you sure". What it cannot do is stand in for you.

A self-check compares the answer against the material in front of it: the documents you supplied, the instructions you gave, its own earlier sentences. That catches internal inconsistency, arithmetic that does not add up, and claims with no support in a provided source, all of which are worth catching. It cannot catch a claim that is coherent, well-supported by the text it was given, and false about the world. Nothing in the loop is checking the world.

The same Anthropic guidance says so plainly, having just recommended the techniques: they "don't eliminate them entirely. Always validate critical information, especially for high-stakes decisions." Worth noting that page is written for developers building systems, not for people using an assistant. The techniques transfer; the responsibility does not move.

Where to stop#

There is a point where checking an answer costs more than producing it yourself would have. Reaching it is not a failure of method, it is information: for that particular task, this was the wrong tool, and the right response is to stop rather than to check harder.

Which suggests a way of choosing tasks in the first place. These systems are most useful where verification is cheapest. Code you can run, a fact with a primary source one search away, a draft you can read and judge in a minute: the check is quick, so a wrong answer costs you almost nothing. They are most dangerous in the mirror image, where you cannot easily tell a right answer from a plausible one and confirming it would take an afternoon. That is not a list of forbidden subjects, and it shifts as the tools change. It is a question to ask before you start, rather than after you have already relied on the answer.

Related → Is what you're reading out of date? · Hallucination · Getting better results · Sources