Done is a claim, not a fact: how to verify AI work before you ship it

The most expensive sentence in AI-assisted work is "done, everything passes." I have watched an AI agent say it about code that did not compile. I have watched one say it about a form that looked perfect and silently sent nothing. The agent was not lying. It genuinely believed the work was finished, the same way an eager junior believes their first pull request is ready. Belief is not the standard. Evidence is.

So the rule I run every AI session under is simple: done is a claim, not a fact. A claim becomes a fact when there is fresh evidence behind it, and never before.

Why models say done when it is not

Language models are trained to be helpful and complete. Finishing the story is what they do, and "I finished the task" is the natural last line of the story about doing a task. There is no discomfort circuit that makes a model hesitate the way a careful engineer hesitates before saying something works. It will describe the tests it would pass with the same fluent confidence whether or not those tests were ever run.

Once you accept this, the problem stops being a character flaw to fix and becomes an engineering property to design around. You do not need the model to be honest about being done. You need a process where its opinion of being done does not matter.

Fresh evidence or it did not happen

The core discipline: before any piece of AI work is accepted, the verification actually runs, and someone reads the actual output. Not the model's summary of the output. The output. Run the build and read the exit code. Run the tests and count the passes. Load the page and click the button. Send the test email and check the inbox.

The words to ban are the hedge words: "should work," "probably passes," "seems fine." Each of those means the same thing: no one has looked. In my Claude Code setup, this is a standing rule the agent reads at the start of every session: no completion claims without fresh verification evidence. It sounds bureaucratic. It takes seconds. It has caught more bad merges than any other rule I run.

Give the agent a feedback loop it cannot argue with

The next level up is making verification something the agent does to itself. An AI agent with a test suite is a fundamentally different tool from one without. When there are tests, the agent writes code, runs the tests, sees the failure, and fixes its own mistake before you ever see it. The loop closes without you. Without tests, you are the test suite, and you will be worse at it than a machine that never gets bored.

This is why the old test-first habit matters more with AI, not less. Have the agent write the test before the fix and watch it fail for the right reason. A test that fails first proves it is testing something real. Then the implementation has a target, and "done" stops being an opinion and becomes a green light that either turns on or does not. Builds, linters, and type checkers play the same role: hard gates that do not care how confident the model sounds.

For anything visual, look at it

Code checks do not catch visual damage. A page can build cleanly, pass every test, and render as an unreadable mess on a phone. AI agents are especially prone to this because they edit styles without ever seeing a pixel, like a designer working blindfolded who insists the layout is balanced.

The fix is boring and absolute: anything a customer will see gets looked at before it ships, at desktop and mobile widths. My agents take screenshots of the pages they touched and the screenshot gets judged against the goal, not the code. If you are reviewing AI-built UI without ever rendering it, you are not reviewing it.

The maker never grades its own homework

Here is the subtle failure mode: asking the same AI that did the work whether the work is good. It will say yes. Not because it is covering anything up, but because the same reasoning that produced the mistake will reproduce the mistake while checking it. Blind spots do not reveal themselves to themselves.

Two separations fix this. First, separate the checker from the maker: I hand finished work to a fresh agent that sees only the artifact and the checklist it must satisfy, never the working session, the reasoning, or the excuses. It judges what exists, not what was intended, and it fails things the maker waved through. Second, when the stakes are worth it, make the checker a different model family entirely. Different models have uncorrelated blind spots, and an independent reviewer on a different model has caught bugs in my own shipped work that the original model reviewed and approved twice.

Make it fail loud, not polite

The last piece is cultural. The default AI failure is quiet: a skipped step here, a mocked call there, a "this part can be finished later" buried in paragraph four. So the standing instruction is: before claiming done, list every step that was skipped, stubbed, or left unverified. If that list is not empty, the work is not done, full stop. "Tests pass" is false if any test was skipped.

This one instruction changes the texture of what the agent reports. Instead of a cheerful summary, you get an honest ledger: what is verified, what is assumed, what still needs a human look. That ledger is worth more than any amount of polish, because it tells you exactly where the risk still lives.

The bottom line

None of this is exotic. Run it before you believe it. Read the real output. Give the agent tests so it catches itself. Look at anything visual. Never let the maker grade its own work. Make silence about skipped steps a rule violation instead of a default. Together these turn AI from a confident storyteller into something you can actually ship from, and they cost minutes against the hours that one plausible-looking failure burns.

This verification layer is the part most AI setups skip, and it is the part that makes the rest trustworthy. If you want AI doing real work in your business with a checking loop that actually catches mistakes before your customers do, send a briefand I'll scope it with you.