Check AI output by what a mistake would cost, not by what looks uncertain: the dangerous parts are often the ones that look finished.
- Irreversible or public work: check all of it. Read it fully, verify its factual claims, and get a second reader if it carries your name.
- Names, dates, figures, quotes and links: check each one. These specifics are where errors concentrate, and a fabricated citation looks like a real one.
- Code: run it rather than just reading it. A test checks correctness faster than reading, for the cases it covers; if there is none, write one first.
- Formatting and tone: spot-check. Mistakes there are visible and cheap to fix.
- Review your own process monthly. Ask what shipped unchecked, and what you would miss if the output were quietly wrong for a month.
Checking everything is not a strategy — it is hard to keep up for long. Checking by risk is, and it spends the time where an error would cost most.
Sort by what it costs to be wrong, not by what looks uncertain. The parts that look uncertain are already getting your attention. The dangerous parts are the ones that look finished.
Four tiers, checked differently
Irreversible or public — check everything
Anything sent, published, paid or filed. Read it fully, verify every factual claim, and have someone else read it if it carries your name. The cost of being wrong is not recoverable, so the check is not optional.
Specific and verifiable — check every instance
Names, dates, figures, citations, quotes, URLs, legal references. These are where errors concentrate, because rare facts cannot be reliably recalled: a formal result puts a floor under the error rate on facts that appear only once in the training data — the mechanism is on why AI makes things up.Kalai, Nachum, Vempala & Zhang, Why Language Models Hallucinate, 4 Sep 2025, §1.1, read at source 23 Sep 2026: the hallucination rate “after pretraining, should be at least the fraction of training facts that appear once.” A formal lower bound, not an empirical measurement of which kinds of detail fail most.
A fabricated citation looks exactly like a real one, complete with volume and page numbers.Kalai, Nachum, Vempala & Zhang, Why Language Models Hallucinate, 4 Sep 2025, §1.2, read at source 23 Sep 2026: “Bluffs are often overconfident and specific, such as ‘September 30’ rather than ‘Sometime in autumn’ for a question about a date.” The volume-and-page example is this site’s own, not the paper’s.
Executable — check by running, not reading
Code, queries, configurations. Published vulnerability rates in AI-generated code run roughly 40% to 70% depending on model, language and method.Corrected 11 Sep 2026: previously read “25% to 62%… incl. Snyk 2026 (~48%)”. No Snyk publication stating ~48% could be found at source, and the 25–62% bounds traced to nothing; the range is now stated from the two studies that were read. Pearce et al., Asleep at the Keyboard? (arXiv 2108.09293, 2022): “In total, we produce 89 different scenarios for Copilot to complete, producing 1,689 programs. Of these, we found approximately 40% to be vulnerable.” arxiv.org/abs/2108.09293. Veracode, 2025 GenAI Code Security Report: “45% of code samples failed security tests and introduced OWASP Top 10 security vulnerabilities into the code”, with Java at “a 72% security failure rate across tasks” veracode.com. Veracode’s Spring 2026 update (24 Mar 2026) holds the overall figure: “across all models and all tasks, only 55% of generation tasks result in secure code” veracode.com. See also the full correction
Reading code for correctness is slow and easy to get wrong. Running it against a test is faster, and settles whatever the test covers. If there is no test, that is the first thing to generate.Reasoning, September 2026 — this site’s working rule, not a measured comparison. A passing test shows only that the cases it checks behave; it says nothing about the ones it does not.
Structural or stylistic — spot-check
Formatting, tone, organisation, summaries of things you already know. Errors here are visible and cheap, so sampling is proportionate.
What to look for, specifically
- Confident specifics you did not supply. A figure, a name or a date that arrived from nowhere is the highest-risk sentence on the page.
- Anything that agrees with your premise. If it echoed your framing back, that is not confirmation — see how AI influences you back.
- Round numbers. A round figure with no source beside it is worth tracing: it may be a rounding of what the source said, or of something the source never said.
- Attribution without a date. "Studies show" and "research suggests" are the shape of a citation, not one.
- Completeness claims. “All”, “every”, “none” — hard for anyone to establish and easy for a model to assert.
Check the thing that would be expensive to get wrong, not a sample of the easy parts.
Auditing the process, not just the output
Once a month, worth asking of your own use:
- What did I ship without checking? Not what did I check — what got through.
- What did I catch, and at which tier? If everything you catch is tier 4, you are not looking at tiers 2 and 3.
- Where did it actually save time, net of the checking? Some tasks cost more to verify than to do.
- What would I have noticed if it were quietly wrong for a month? If the answer is nothing, that is the thing to instrument.
The last one matters most, and it is the same failure mode as silent drift in automations: the output that keeps arriving on schedule, still confident, no longer correct.