How to check AI work before it ships

The AI drafts that hurt you are not the bad ones. A bad draft announces itself and gets rewritten in five minutes. The dangerous draft is the one that is 95% right: the structure is sound, the tone is yours, four of the five figures are correct, and the fifth is wrong by a factor of ten. Stack Overflow’s 2025 developer survey found that the most common frustration with AI tools was not failure. It was “AI solutions that are almost right, but not quite,” named by 66% of respondents [6].

That single property should decide how you check. You are not proofreading for typos, and you are not reading for quality, because quality is the thing the tool is best at faking. You are auditing a confident document produced by something with no way to signal doubt, and the audit has to be cheap enough that you keep the time the tool saved you. What follows is a routine: how to sort work by what being wrong costs, what to look at inside a draft, and how to test a claim without asking the model whether it is sure. It assumes ordinary business output, meaning proposals, emails, listings, posts, spreadsheets and small pieces of code.

Sort the work by what it costs you to be wrong

Most people check everything with the same effort, which in practice means checking everything badly. The first move happens before you read a word: decide what happens if this specific piece is wrong, and check to that level.

Three tiers cover almost everything. Work that can be wrong without consequence ships after a skim, and a brainstorm list, an internal summary or a first-pass outline belongs here. Work that embarrasses you gets a read-through and a source check on anything specific, which covers most client email, most marketing copy and anything with your name on it in public. Work that costs money, breaks a contract or misleads a regulator gets the full pass, every claim traced and every number recomputed, however good the model has become.

The top tier is not hypothetical. The AI Hallucination Cases database tracks legal decisions in which a court or tribunal addressed the use of AI in “more than a passing reference” [7]. As of 3 September 2026 it listed 2,009 such decisions, 1,378 of them in the United States [7]. Those are documents filed by people whose entire profession is checking citations. The lesson is not that lawyers are careless. It is that fluent output defeats a skim, and a skim was never the right check for a court filing.

Underline the claims and leave the prose alone

Read the draft once with a pen, real or otherwise, and mark every checkable thing: every number, date, name, price, product tier, statute, statistic, quotation and link. Ignore the sentences that connect them. The connective prose is almost always fine, because writing plausible prose is exactly what the machine does well. The marks are where the failures live.

Then trace each mark to a source, and hold yourself to the right question. Not “does this sound plausible,” which is the question the model already optimised against, but “where did this come from.” OpenAI’s own account of why models hallucinate is blunt about the incentive: most evaluations “measure model performance in a way that encourages guessing rather than honesty about uncertainty,” because a guess sometimes scores and a blank never does [2]. Their SimpleQA comparison shows the size of the effect. One model abstained on 52% of questions and got 26% wrong; another abstained on 1% and got 75% wrong, at almost the same accuracy, 22% against 24% [2]. Volunteering an answer is a habit the training rewarded, not a signal that an answer exists.

You can shift some of that work onto the model before it drafts. Anthropic’s guidance is to give it explicit permission to admit uncertainty, which it says “can drastically reduce false information”; for long documents, to ask it to pull word-for-word quotes before doing anything else; and to make the output auditable by requiring a cited quote for each claim, then running a second pass in which any claim it cannot support with a quote must be retracted [1]. That last instruction is the highest-value sentence in this guide. It turns a paragraph you have to fact-check into one that has already deleted its own weakest sentence.

Make the draft carry its own receipts

A draft with no sources is a draft you have to research from scratch. A draft with sources is a draft you only have to open links for. The difference in your time is enormous, so ask for the receipts up front rather than reconstructing them afterwards.

Where the model can search, turn search on. Google’s Grounding with Google Search connects Gemini to real-time web content and returns inline citation annotations that map spans of the answer back to the source URLs behind them; Google’s stated benefits are reducing hallucinations “by basing responses on real-world information” and showing “the sources for the model’s claims” [4]. It is supported across the current Gemini 3 and 2.5 model families [4]. Turning search on changes your job from “is this true” to “does this page say this,” and the second question is one you can actually finish before lunch.

What grounding does not do is verify anything. A citation is a pointer, and a pointer can aim at a real page that says something adjacent to the claim, or supports half of it, or said it two years ago. So open them. All of them, in the top tier, and every one attached to a number in the middle tier. Two minutes of clicking catches the failure that a re-read never will, because a re-read shares the model’s blind spot for things that look correct.

Do not verify by asking the same model again

The natural way to test a doubtful line is to ask the model whether it is sure. It is also the one move guaranteed not to work. Push back on a correct answer and you will often get an apology and a new answer that agrees with you. OpenAI’s April 2025 write-up on sycophancy in GPT-4o describes an update that produced responses that were “overly flattering or agreeable,” and traces the cause to weighting short-term user signals such as thumbs-up and thumbs-down ratings too heavily [3]. Your correction is exactly that kind of signal, arriving mid-conversation.

Three replacements work. Take the claim to a source, which is the only real verification. Take the question, not the answer, to a fresh conversation or a different model, with no hint of what the first one said, and see whether the two land in the same place. Or probe by stating the opposite of what you actually believe: if it agrees with that too, the answer was never held in the first place and both versions are worthless.

Treat any second-model critique as leads rather than verdicts. What you want from it is a cheap list of places to look, produced by something that does not get bored or polite. You still make the call.

Test what can be tested instead of reading it

For anything executable, running beats reading, and it is not close. Code goes against cases where you already know the answer, including one case you expect to fail. A spreadsheet formula gets tried on a row whose result you can do in your head. A process document gets walked through once, literally, following your own steps. A price quote gets rebuilt from its inputs in a spreadsheet rather than checked against the model’s total.

Numbers deserve their own rule, because they are the part that fails silently and the part that moves money. Never accept a number you did not see calculated. Ask for the formula and the inputs instead of the result, then compute it yourself. If the model has a code tool, make it do the arithmetic in code and show the code. And when a recomputation disagrees, do not ask the model to fix the number, because a model that quietly corrects one wrong figure often corrects it to a different wrong figure.

The cost of skipping this is well documented among the people who do it most. In the same Stack Overflow survey, 45.2% of developers named “debugging AI-generated code is more time-consuming” as a frustration, and trust in the accuracy of AI output was thin: 3.1% said they highly trust it and 29.6% somewhat trust it, against 26.1% who somewhat distrust it and 19.6% who highly distrust it [6]. That distribution is not pessimism. It is what people report after shipping the output.

Attach the check to the moment of sending

A routine that depends on remembering is not a routine. Tie the check to a physical trigger, and the reliable trigger is the act of sending: nothing AI-assisted leaves your desk until its marks are traced and its numbers are recomputed. Put the check in the place that already tells you a job is finished, whether that is a template, a project checklist, a definition of done, or a line in the draft that you delete once the pass is complete.

Then keep the arithmetic honest. The point of the tool is time, so the number that matters is end-to-end: your time to produce the thing yourself, against your time to prompt, wait, read, check and fix. If the check regularly costs more than the task did, the tool has not earned its place in that workflow and the answer is to change the workflow, not to skip the check. The same test decides everything else in how to choose AI tools for a small business, and the failure classes each check is aimed at are catalogued in what AI still gets wrong.

What still goes wrong

Every check here catches the failure it was designed for and misses the others. Requiring quotes kills invented sources but not misread ones, because a genuine quote can be lifted from a paragraph that argues the opposite. Recomputing numbers kills arithmetic drift but not a wrong assumption you fed in at the top. Opening links proves a page exists and says the words; it does not make the page right. Anthropic states the limit on its own advice plainly: these techniques “significantly reduce hallucinations” but “don’t eliminate them entirely,” and critical information should always be validated [1].

The harder problem is that you are a bad judge of whether this is paying off. METR ran a randomised trial with 16 experienced open-source developers across 246 real tasks and found they took 19% longer when allowed to use AI tools. The developers had expected a 24% speedup, and after living through the slowdown still believed they had been sped up by 20% [8]. METR is explicit that it does not claim its developers or repositories represent a majority or plurality of software development work [8], and these were experienced people in repositories they knew well, which is close to the position of a solo operator working on their own business. The honest reading is not that the tools do not help. It is that your sense of how long the whole loop took, including the checking, is not evidence. Time it once, on real work, before you decide.

This guide is also the wrong document for a regulated process. OpenAI’s usage policies prohibit “automation of high-stakes decisions in sensitive areas without human review,” naming legal, medical, employment, financial activities and credit, insurance, housing and essential government services among them, and prohibit “provision of tailored advice that requires a license, such as legal or medical advice, without appropriate involvement by a licensed professional” [5]. In those settings verification is not a personal habit you tune to taste. It is a documented control with a named owner, and you need a longer document than this one.