Most people I train arrive with one of two habits. They send what the AI produced and hope, or they check every line themselves and then wonder what they saved. Neither habit is a strategy, and both habits get worse as the AI does more of the work.
Those people are in good company. In the Stack Overflow 2025 Developer Survey, 45.7% of developers said they distrust the accuracy of AI output, against 32.7% who trust it. The most common frustration, named by 66%, was "AI solutions that are almost right, but not quite." Almost right is the expensive kind of wrong, because the work looks finished.
What fixes both habits is a routine: a small, written way of deciding what needs your judgement and what a machine should check the same way every time. Here is the routine I teach.
Two different jobs that people keep mixing up
When someone tells me a piece of AI work "looks correct", that is a review. When they tell me "I ran this command and here is the result", that is verification. I keep the two words apart on purpose, in every session, because mixing them produces vague reviews and false confidence at the same time.
Review is judgement. Is it right, clear, on-brand, useful, safe to send? A person decides, or an AI acting as a reviewer gives an opinion that a person weighs.
Verification runs checks and reports what happened. The links resolve, the form submits, the figures add up, the tests pass. A machine decides, and it leaves evidence behind.
One rule applies in both directions. A reviewer may not claim the tests passed without running them. A verifier may not claim the design is good because the commands passed. Each job has its own output, and neither output stands in for the other.
Sort your checks before you build anything
The first exercise in my review and verification session is a sorting game. I read out six claims and the group types into the chat whether each one needs a human or a command. Three of them always cause an argument:
- "The error message tells the user what to do next." A test can pin the exact wording. Only a person can judge whether that wording helps.
- "The build produced an artifact." A command settles it in seconds.
- "This code will be hard to change in six months." Nothing you can run will settle that one. It stays a judgement call.
For non-technical groups I use a deliberately flawed newsletter instead: a factual error, an unsupported claim, a broken link, an off-brand paragraph and a missing call to action. People list what is wrong, then sort each item into needs a human or a machine could catch this. The broken link belongs to the machine. The off-brand paragraph belongs to you.
Sorting your checks once, on your own work, changes what you ask the AI for. You ask it to run the specific checks a machine is good at, then hand you the short list that needs your eye.
Two questions I ask every time
When someone says their AI-built thing works, I ask: What did you run? What proves it?
Often the real answer is "Claude said it was done." There is a real difference between the AI reporting that something works and something independent checking it. Claude will announce success with complete confidence. That announcement is only a claim until something has run.
Two follow-up questions do most of the remaining work: What changed? and What would show this is wrong? If nobody can answer the second question, nothing has been verified yet.
Write the verification down as a separate contract
The participants who get the most from the review and verification session build two separate things and keep them apart.
A review skill looks at the work and proposes changes. It reports each finding with what is wrong, where it is, why it matters and what to do about it. The review skill never silently rewrites the whole piece, because a rewrite you didn't ask for is a review you can't check.
A verification contract runs the real checks and reports:
- the commands it ran and their results
- which failures were already there before this change, and which are new
- what it could not check
- how confident it is, and where that confidence stops
The third item, what it could not check, matters more than it looks. A report that lists what it couldn't check is telling you exactly where your attention should go.
Not everyone is building software. If your work is documents, spreadsheets or a monthly report, the equivalent is a checklist the AI runs and reports against, with the output compared to a known-good example. The discipline stays the same and only the mechanism changes. I cover non-technical work in more detail in whether non-developers can use Claude Code.
Watch the check fail once, on purpose
A check that has never failed has proved nothing. In the build sessions I insist that people break what they built first and watch the check catch the fault, then fix the fault and watch the check pass. Every group tries to skip this step unless I hold them to it.
For web work, Claude can drive a real browser through Playwright, click through the page and report what actually happened. A browser check can tell you the confirmation email never sent. A browser check still has limits. A check can confirm that the form submitted, and whether the form is worth filling in remains your call.
Turn the rules you repeat into gates
Once you know which checks you run every time, stop relying on remembering to ask. The line I use is this: an instruction influences behaviour, a control guarantees it.
A rule written in your project's instructions file is still worth having, and it is still only a request. A hook is a small script the tool runs at a fixed moment, whether or not anyone remembered. A hook can block the action, inject a rule, or require a check first, and the ability to refuse is what makes it a control.
Useful gates people build in my sessions include:
- run the linter after every edit
- prevent a commit when the tests fail
- warn me when a change gets big
- never delete anything without asking me first
- run the checklist before anything is published
A developer from one of my JustSolve groups summed up what stuck in one line:
"Using automatic checks instead of doing manually. Clear rules made to keep the quality of work high"
Exact checks belong to scripts, tests and hooks. The AI handles interpretation and the exceptions. Your attention goes where no check can judge.
Gates matter even more once work runs without you watching. If you want to read about unattended work next, start with what you can safely let an AI agent run without you.
Trust grows from evidence
Trust in AI output comes from a routine that tells you which parts have been proved, which parts still need you, and what nobody has checked yet. For engineering and product teams, the same review and verification work runs inside the programme for teams, against your own codebase.
Build your own routine with me
If you run a business or lead people and want this routine for your own work, the AI Bootcamp has a session called Knowing when to trust it. You leave with a review routine and a checking routine, both running on real work, written down and yours to keep.