AI Answers You Can Check

The dangerous AI answer is fluent, specific, plausible and wrong in a way you will not discover for three weeks. Detecting those is mostly mechanical. Here is the mechanism.

Written by Vladimir Miroshnichenko·Published August 26, 2026·Updated September 4, 2026·5 min read

The dangerous AI answer is not the one that is obviously wrong. It is the one that is fluent, specific, plausible, and wrong in a way you will not discover for three weeks.

Detecting those is a skill, and it is mostly mechanical. Here is the mechanism.

Why confidence is uninformative

Language models produce fluent text regardless of whether the underlying claim is grounded. A model that has genuinely traced your refund logic and a model that has assembled a plausible-sounding paragraph from three unrelated files will express themselves with identical assurance. Confidence is a property of the writing, not of the knowledge.

This is worse for questions about your own system than for general programming questions, because there is no shared reality to anchor against. If a model misstates how a sorting algorithm works, the internet disagrees. If it misstates how your invitation flow works, nothing disagrees. You are the only check.

So the practical question is not "is this model reliable" — it is "can I check this particular claim in under a minute?"

The habit: demand provenance

Add this to every question you ask about your codebase:

"Cite the file and line for each claim."

Eight words. It changes three things.

It makes verification cheap. A cited claim is checked in seconds. An uncited one has to be re-derived from scratch, which is the work you were trying to avoid.

It exposes the fabrications. A model that assembled an answer from fragments often cannot produce a coherent citation for it, and will cite something that does not say what the answer claimed. That mismatch is your signal, and it is far more legible than the prose.

It changes what you can hand on. A cited answer can go into a pull request description or a design note and survive review. An uncited one is hearsay with your name on it.

The three-citation spot check

You do not have to verify everything. Sample.

Take any substantive answer, pick three citations at random, open them and ask one question of each: does this file actually say what the answer claimed?

Three out of three — treat the answer as a good working draft.
Two out of three — verify everything before acting on it.
Fewer than two — discard the answer and, more importantly, distrust the whole session. A model that fabricated one citation is not being careful about the rest.

This takes about two minutes and is the highest-value habit in AI-assisted engineering. Most teams skip it because the answer reads like it was checked.

Where fabrications concentrate

They are not evenly distributed. In practice they cluster in four places, and knowing them tells you where to spend your two minutes.

Claims that span files. "The webhook fires after payment confirms" requires knowing two things and the relationship between them. Single-file claims are usually reliable; the relationship is where the reconstruction happens, and reconstruction is where errors are introduced.

Negative claims. "Nothing else uses this field" cannot be verified from a sample of retrieved fragments — it is a claim about everything the model did not see. Treat every "nothing", "only" and "never" as unsupported until checked directly.

Claims about intent. "This check exists to prevent double-charging" is an interpretation. It may be right, but the code says what it does, not why. Ask for the evidence separately and expect it to be thinner.

Anything with a number. "There are twelve places this is used." Counts are the easiest thing to check and among the most often wrong, because they require completeness rather than a plausible example.

Two protocols worth adopting

The rephrase test. Ask the same question differently, twenty minutes later, in a fresh session. If the answer changes materially, it was reconstructed rather than known — and both versions are hypotheses. This is the cheapest reliability check available and almost nobody runs it.

The uncertainty prompt. Add: "If you cannot determine something from the code, say so explicitly rather than inferring."

A system that then reports "I could not determine whether the webhook fires on this transition" has told you exactly where to look. One that never reports uncertainty is not more certain; it is not tracking it, which means you cannot tell its grounded claims from its inferred ones.

What good looks like

If you are evaluating a tool rather than a single answer, this is the standard worth holding it to:

Every claim carries a source you can open.
The citations say what the answer claimed — check by sampling.
Uncertainty is stated rather than smoothed over.
Asking twice gets the same answer.
Negative and quantitative claims are either supported or explicitly hedged.

That is a higher bar than most tools clear today, including for questions they answer correctly. Correct-but-uncheckable is a real category, and it is worth less than it looks, because the next person cannot tell it apart from the confident mistake.

The reframe

An answer you cannot check is a second opinion from a source with no accountability. It might be right. You have no way to know, and neither does the person reading your pull request.

Verification is not distrust of AI. It is the thing that makes AI answers usable as evidence rather than as vibes — and once every claim carries its source, the review becomes a two-minute audit instead of a re-derivation. That is where the time actually comes back.

Put a number on your own workflow

Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.

Build My Business Case → Start free →

Frequently asked questions

How do I check whether an AI answer about my codebase is accurate?

Ask for a file and line citation with every claim, then sample three at random and confirm the file says what the answer claimed. Three out of three means it is a good working draft; fewer than two means discard the answer and distrust the whole session. It takes about two minutes.

Where do AI hallucinations about code cluster?

In four places: claims that span multiple files, where the relationship has to be reconstructed; negative claims such as "nothing else uses this", which cannot be verified from retrieved fragments; claims about intent, which are interpretation rather than fact; and anything with a count, because counts require completeness rather than a plausible example.

What is the rephrase test?

Asking the same question differently, in a fresh session, twenty minutes later. If the answer changes materially, it was reconstructed rather than known, and both versions should be treated as hypotheses. It is the cheapest reliability check available and almost nobody runs it.

Should I ask AI to express uncertainty?

Yes — add "if you cannot determine something from the code, say so explicitly rather than inferring." A tool that names what it could not determine has told you exactly where to look. One that never expresses uncertainty is not more certain; it simply is not tracking it, so you cannot separate its grounded claims from its guesses.

Vladimir Miroshnichenko

Founder, GitMir

Founder of GitMir, the intelligence layer that gives AI real context about a company's software. I write about AI agents, context engineering, workflow economics and keeping AI-generated work under control.

LinkedIn →

← More articles