Make AI Output Prove Itself: Five Ways to Ask for Evidence

For anyone who uses AI to write code, look things up or hand work to an AI agent, including beginners. No background is needed. Every term comes with an everyday example, and the calculation part is marked so you can skip it if you do not need it.

The numbers come from public sources, listed at the end. Examples labeled "illustration" are made up, and they do not name any real person or company. Nobody fully understands how AI works inside, so the pictures below are only aids for remembering. The five ways in this article are a synthesis of practice drawn from the documents and studies cited, not five techniques that have each been tested in a controlled experiment.

---

Quick summary#

• Most people who use AI are already used to checking its work. The 2026 Stack Overflow survey found that 48% of respondents trust AI only when they can easily verify the result, and only 6.6% trust it for important decisions.
• Checking by "reading carefully and thinking it through again" is the most expensive way. If the AI hands in evidence you can open, checking moves from "rebuild the whole argument" to "look at one specific thing".
• The five ways to ask for evidence: sources you can open, a runnable check with its raw output, small, separate changes, a sort into ran, only read and assumed, and a way for someone else to rerun it.
• Each has its own weak spot: sources can be invented, a test can be written by the AI to pass, output can be cut off. The article shows how to catch each one.
• In this article's worked example, checking a summary with 8 claims takes about 48 minutes without evidence and about 18 minutes with it. These are illustration numbers so you can recompute with your own team.
• Evidence is not a guarantee. It makes checking cheaper, but a person who understands enough still has to look at it.

---

Hard words, plain meaning#

---

1. Picture it first: the repair slip#

Picture taking your motorbike to a shop. The mechanic says, "All done, runs great." You have no way to check except to ride it and hope. Now picture the mechanic handing you a slip: front brake pads replaced, brakes tested at 30 km/h on the slope behind the shop, stopping distance normal, brake fluid system not inspected. Same mechanic, but now you know what they did, what they tried and what they have not touched.

AI works the same way. "Done, all tests pass" gives you almost nothing to check. It only gives you something to believe. The Claude Code documentation describes this exactly: an agent stops when the work looks done, and if it has nothing to run, then "looks done" is the only thing it has, so you become the test suite. The documentation also recommends asking for concrete evidence such as the command that was run and its output.

Takeaway: saying "done" costs nothing. Evidence is what makes checking cheap. Your job is not to decide whether to trust, but to design the request so the result carries its own way of being checked.

---

2. Why it matters: users are doing the checking#

2.1 Two numbers from the 2026 Stack Overflow survey#

According to the results page of the Stack Overflow Developer Survey 2026 (more than 30,000 responses, per one news report), about 48% of respondents said they trust AI when they can easily verify the result, and 6.6% trust AI for many tasks, including important decisions. The survey also records that 69.9% ask an AI agent when they face an unfamiliar task. So people use AI a lot, but trust it with conditions.

Two cautions. First, I read a summary rather than checking each table, and one number on the page ("over 87% have some level of trust, up from 31%") sounds out of line with the 6.6% figure, so I do not use it. Second, on citing sources, the sources I read give 78.7% (one news report) and 93% (a summary of the survey page) for the share who consider citing sources important when judging an AI answer. The two numbers may differ because of how they were counted or how the question was asked, so read it as "most people, roughly 80% to 93%".

Takeaway: users have said what they need: results that are easy to check. What is missing is a way to make them easy to check.

2.2 A real case: court cases that did not exist (Mata v. Avianca, 2023)#

In a lawsuit in a federal court in New York, the plaintiff's lawyer used ChatGPT to draft a legal filing. The filing cited cases with airline names, quotations and docket numbers all filled in, but six of them did not exist. On June 22, 2023 the court fined two lawyers and their law firm a total of 5,000 USD. More detail is in the article Why not to trust AI blindly.

What stands out is this: the filing had "sources", but nobody opened them. Evidence is only useful when someone opens it.

Takeaway: asking for sources is step one, and opening the sources is step two. Without step two, step one is decoration.

2.3 Why AI so often answers with confidence: an argument worth knowing#

Kalai, Nachum, Vempala and Zhang (OpenAI and Georgia Tech, September 4, 2025) argue that the way models are trained and scored often rewards guessing over saying "I am not sure". Their example: asked for someone's birthday, a guess has about a 1 in 365 chance of being right, while answering "I don't know" always scores 0, so guessing pays. In the accompanying post, OpenAI reports a comparison on the SimpleQA benchmark: one model declined to answer 52% of the questions and was wrong on 26%, while an older model declined 1% and was wrong on 75%.

Read this as the authors' own argument and the company's own measurement; I did not find independent verification in my search. It gives a practical hint: if a system tends to answer even when unsure, then ask it to state what it is unsure about, instead of waiting for it to say so by itself.

Takeaway: "I am not sure" often does not show up on its own. Ask for it in the request.

---

3. Five ways to ask for evidence#

To make this easy to picture, think of each way as one box on the repair slip: where it read, what it tried, what it changed, what it has not done, how I can try it again myself.

Way 1. Ask for sources you can open#

Picture it as: a book with footnotes. A footnote is only worth something if you can flip to that page.

A sample line to put in the request:

For every claim about code or documentation, attach a place I can check:
file path and line number, or a link to the official documentation.
If a claim has no source, write "no source".

How to read the result: pick one or two of the most important claims, open the source and see whether it really says that. A link that opens is not enough, the content has to match.

Weak spots: an invented source (like the court cases above), a real source that says something else, an outdated source. How to catch them: open it, and look at the date.

Way 2. Ask for a runnable check, with its raw output#

Picture it as: squeezing the brake to test it. The result shows "stops" or "does not stop", and nobody has to comment.

A sample line:

Before reporting done, run the following check and paste the command
and its output word for word (do not summarize): npm test
If any test fails, fix it and run it again.
State how many tests ran.

The Claude Code documentation lists things that can serve as the check: a test file, the exit code of a build, a linter, a script that compares output with a sample result, or a screenshot placed next to the design. What matters is that the check returns pass or fail and the AI can read the result.

Weak spots: a test the AI wrote to fit its own code (the same mistake sits in both places), the AI editing the test to match the code, and only part of the tests running. How to catch them: read the diff of the test folder, compare the number of tests run with the number that exist, and break it on purpose: change one line to be wrong yourself and see whether the test turns red. Better ways to write tests are in the article Testing AI-written code.

Way 3. Ask for small changes, one part at a time#

Picture it as: handing in homework one question at a time instead of the whole notebook. The grader can finish during a break.

A sample line:

Work on one thing at a time. Each round, make one change that can be
described in one sentence, at most about 100 changed lines. After each
part, say what the part is for and where I look to see it working.

Google's public code review guide says small changes are reviewed faster and more thoroughly, because a reviewer can find five minutes several times instead of blocking out a 30 minute stretch, and large changes make it easy to miss important points. They give a rough guide: about 100 lines is usually reasonable and 1,000 lines is usually too large. This is a rule of thumb for human review, not a hard number, and it can vary with the number of files.

Weak spots: splitting into small pieces that depend on each other and are hard to follow. How to catch it: make the AI state the order and the reason for the split. When a change really has to be large (a mass rename), ask the AI to point out which part is mechanical and which part has logic.

Way 4. Ask for a sort: ran, only read, or assumed#

Picture it as: a doctor's record saying "examined", "looked at the scan", and "guess based on symptoms". The three are not allowed to mix.

A sample line:

At the end of the answer, sort the results into three groups:
(a) ran and saw the result, with the command;
(b) read the code but did not run it;
(c) assumed or guessed.
If you are unsure about something, put it in (c), do not leave it out.

The reason: as in section 2.3, a system may tend to give a complete-sounding answer, while "I have not run this" does not arrive by itself. A three-group table gives uncertainty a place to live.

Weak spots: the AI files under (a) something it only read. How to catch it: every item in (a) must have the command and the raw output right next to it. An item in (a) with no command counts as (b).

Way 5. Ask for a way for others to rerun it, or for an independent reader#

Picture it as: a recipe. If you repeat the steps exactly and get the same dish, that dish is more believable than the cook's praise.

A sample line:

Give me one command (or a few steps) so I can see the result again
myself on a clean machine. State the versions and environment
variables that are needed.

And if the work matters, ask a fresh session that has not seen the earlier reasoning to reread the change against the original request. The Claude Code documentation describes this with a review command that runs in a new sub-agent that never saw the conversation, so it is not swept along by the reasoning that produced the code. Take it as a reasonable practice, not a guarantee, because another AI can make the same kind of mistake.

Weak spots: the command works on the AI's machine and not on yours (a missing environment variable, a different version). How to catch it: really run it once on a clean machine or in CI. And for important work, have a person read it, not only a machine.

Putting it into one short block#

If you want to use this over the long term, paste the block below into AGENTS.md or the tool's instruction file so every session reads it:

## When reporting that a task is done
- Paste the check command you ran and its raw output, with the number of tests run.
- Give a file and line number for every claim about code.
- One change per purpose, about 100 lines or fewer.
- Sort results into: ran / only read / assumed.
- Give me one command to rerun this on a clean machine.

Five lines, short enough for both people and AI to read all of it. Keeping it short is deliberate: a long list can get skipped.

---

4. A calculation you can recheck yourself (illustration, can be skipped)#

This is an illustration with made-up numbers, not measurements. Suppose the AI hands in a summary of a change with 8 claims (for example "fixed the date format bug", "did not touch the payment function"). You need to confirm each claim before approving.

• Without evidence: you rebuild each claim yourself, say 6 minutes each.
• With evidence: you only open what is pointed to, say 1 minute each. For the 2 riskiest claims, you check deeper for another 5 minutes each.

claims, rebuild, glance, deep, risky = 8, 6, 1, 5, 2
without = claims * rebuild              # 48 minutes
with_proof = claims * glance + risky * deep   # 8 + 10 = 18 minutes
print(without, with_proof, without - with_proof)
# 48 18 30

per_month = 2 * 20                      # 2 summaries a day, 20 days
print(without * per_month / 60, with_proof * per_month / 60)
# 32.0 12.0   (hours per month)

Reading the result: 48 minutes drops to 18 minutes per summary, about 38% of the original. With two summaries a day over 20 working days, that is about 32 hours versus 12 hours a month for one reviewer.

To be clear: 6 minutes, 1 minute and 5 minutes are numbers I assumed, not measured. Real work can differ a lot, and asking for evidence also costs the AI extra time to run and write. Time yourself a few times with your own team and swap in your numbers.

---

5. Where asking for evidence also fails#

Picture the repair slip again: a mechanic can still write "tested the brakes" without testing them.

5.1 Illustration: one afternoon with and without evidence#

This is an illustration that does not refer to any real person or product.

Version without asking for evidence:

• 14:00. A dev asks the agent: "Fix the bug where December 31 shows as next year in the report."
• 14:20. The agent replies: "Fixed, tests pass." The dev skims the change, finds it reasonable and merges it into the main branch.
• 16:30. A customer reports that the year-end report is still wrong with a different date format. The agent fixed only one of the two places.

Version with asking for evidence:

• 14:00. The same request, with the five-line block above.
• 14:20. The agent hands in: ran npm test, 12 tests pass, with one new test for December 31 in the dd/MM format. Group (b): read the second date format function but did not run it. Group (c): assumed every report uses the dd/MM format.
• 14:25. The dev looks at groups (b) and (c) and adds a December 31 case for the second format. The test turns red. The agent fixes the remaining place.
• 14:40. Merged with two new tests.

The action in both versions: stop "done" at groups (b) and (c). The place where the AI honestly says "not run" tells the dev where to look. This is an illustration, so it proves nothing. The evidence lies in the studies: Perry and colleagues (Stanford, 2022) found that users of an AI assistant wrote less secure code in most of the tasks but were more confident that their code was secure, so skimming and approving gives real cause for worry. See also the article Reviewing AI-written code.

---

6. Numbers and documents used#

Reading it correctly: the sources above support making results easy to check. I did not find a controlled study that directly measures how many errors asking for evidence removes. The five ways above are a synthesis of practice.

---

7. Level of evidence by risk#

You do not need all five things for every task. Picture shopping: for vegetables you look, for a watch you want the warranty card.

---

8. Habits to apply from tomorrow#

8.1 Eight questions before accepting a result#

1. What way of checking does this result carry: a source, a check, or only words?
2. Have I opened at least one important source, and does it say what is claimed?
3. Are the check command and its output word for word, or only a summary?
4. How many tests ran out of the total that exist?
5. Who wrote the new test, and does it turn red when I break one line on purpose?
6. Is the change small enough for me to read all of it?
7. Which parts did the AI mark "only read" or "assumed", and what will I do about them?
8. Can I rerun it on a clean machine, or have I only taken the AI's word for it?

8.2 Three things to do right away#

1. Paste the five-line block into the instruction file of the tool you use.
2. Pick one small task today and time the checking before and after asking for evidence.
3. Ask a colleague to read one "ran, only read, assumed" report and tell you whether it is usable.

---

9. A balanced view: what evidence can and cannot do#

What it can do: make checking cheaper and faster, force the AI to say what it has not run, leave a trail for others to check again, and help spot gaps between the request and the change.

What it cannot do:

• Evidence is not a guarantee of correctness. A test can be wrong, a source can be invented, and a neat table can create too much of a sense of safety. The study by Perry and colleagues suggests users can become more complacent when they have an AI assistant.
• Asking for evidence costs extra time to run and write, so for low-risk work it is too much.
• I did not find a controlled experiment measuring the effect of each way separately. Measure it with your own team.
• Another AI rereading the work can make the same kind of mistake. For important work, a person is needed.

Do not exaggerate: this is not a formula that makes AI stop being wrong. Do not downplay it either: the cost of accepting "done" with nothing to check usually shows up at the end, when the error has already reached the customer.

---

10. Conclusion#

An AI's "done" sounds like an answer, but it is really a promise. Evidence turns the promise into something you can check: sources you can open, a check you can run, small changes, three groups of ran, only read and assumed, and a command to rerun it. Put these requests into the very prompt you give the AI, and always be the one who opens the evidence.

---

References#

The numbers come from public sources as of October 2026. Some figures are reported differently by different outlets, so open the original source to check before quoting.

• Stack Overflow, 2026 Developer Survey (read through a summary, each table not cross-checked)
• Anthropic, Best practices for Claude Code (section "Give Claude a check to run")
• Kalai, Nachum, Vempala, Zhang, Why Language Models Hallucinate (9/2025) and OpenAI's post
• Google Engineering Practices, Small CLs
• Mata v. Avianca, Inc.: Wikipedia and LawNext on the sanctions
• Pearce et al., Asleep at the Keyboard? (2021) and Perry et al., Do Users Write More Insecure Code with AI Assistants? (Stanford, 2022)