Verification

Foundations

A model will tell you a task is done with complete confidence whether or not it actually worked. Confidence is free; it costs the model nothing to be wrong. Verification is how you turn “it says it’s done” into “I can see it’s done”. It’s the habit that separates people who trust AI output blindly from people who ship it.

Give it a check it can read

The most useful move in this whole site: hand the tool a check it can run and read by itself. Then it can tell whether its own work succeeded, inside the loop, before it comes back to you. See How AI coding tools work for why that loop matters.

Kind of work	A check the tool can read
Code	Run the test suite, the build, the type-checker, the linter
A bug fix	A test that fails before the fix and passes after
A script	Run it and read the output
Research / writing	Ask for sources, then open them and check they say what’s claimed
A data change	Query the result back and compare to what you expected

When the check is machine-readable, the model self-corrects. A failing test gets read, understood, and fixed in the same loop. You don’t have to be the one to notice.

Close the loop

Don’t accept “done.” Ask for the evidence, every time:

1. State the task and the check up front: “Add input validation, and make npm test pass.”
2. Let it work.
3. When it claims success, have it show the proof: re-run the test, paste the output, show the diff.
4. If there’s no check it can run, you are the check. Read the change before you accept it.

Tip

The single most effective phrase to keep in your back pocket: “Run the tests and show me the output.” It converts a claim into evidence in one step.

Evidence, not assertion

The pattern generalizes past code. For a research answer, “this is well documented” is an assertion; a link you can open is evidence. For a refactor, “behaviour is unchanged” is an assertion; a passing test suite is evidence. Train yourself to hear the difference and to ask for the second one.

Caution

A test the model wrote itself can be wrong: it can pass by checking the wrong thing, or assert the buggy behaviour it just produced. A green check is necessary, not sufficient. Skim the test, not just the result, on anything that matters.

Why this is non-negotiable

The faster the tool, the more output you have to trust, and the more a missing check costs you. Verification is what lets you move fast and sleep at night: you’re not betting on the model being right, you’re confirming it. Pair it with a steady loop (explore, plan, do, verify, commit) and you have A reliable workflow.

Where you’ll see this

Verification is where the tool guides get concrete, with tests, builds, and reviews wired into the loop:

Claude Code: Advanced Wiring tests and builds into the agent's loop.

Codex: Intermediate Letting the agent run checks and fix what fails.

GitHub Copilot: Advanced Verifying generated code before it reaches a PR.