ClaudeVerification mistakesLevel 2: Context

How Do You Check Code Claude Wrote Before Shipping It?

Run it, and ask for proof. Give Claude a check that comes back pass or fail, such as a test file, a build or a linter. Then read the command and its output, not a sentence saying it passed. Clean-looking code tells you very little about whether it works.

Prompt to copy
Make this change: [what should change].

Run [your test, typecheck or build command] after the change, and keep going until it passes. A syntax check doesn't count.

Fix the code, not the test, and don't hard-code values to make a test pass. If a test seems wrong, tell me.

When you're done, show me the command you ran and its output. If you couldn't run a real check, say which one and why, and don't report the change as done.
  1. 1In the promptClaude decides when it's satisfied
  2. 2/goala separate model checks each turn
  3. 3Stop hookClaude Code enforces it
  4. 4CIchecks outside the session
Options from Anthropic's Claude Code guide, from least strict at the top to most strict at the bottom.

Try it now

  1. 1In your repo, put the exact test command in CLAUDE.md, or include it in the prompt above.
  2. 2Send the prompt, and press Esc if you see Claude start to drift.
  3. 3When it finishes, read the output it shows, then run /code-review for a review from a fresh subagent. To check the running app, use /verify.
  4. 4You'll know it worked when you can point to the command, its output and a passing result for the code you changed.

Use it when

Any code you'll commit, deploy or build on. It's most important for code touching data, money, login or outside APIs, and for anything with boundary cases such as dates, empty inputs and retries.

Skip it when

Throwaway snippets, or code you're only reading to understand an approach. Also don't set up hooks and goals for a one-off script. Asking for the check in your prompt works today, with no setup.

Why it works

Anthropic's Claude Code guide says Claude stops when the work looks done. If it has nothing to run, "looks done" is all it has, and you become the test suite. Give it a pass or fail check, and it can make the change, run the check, read the failure and try again. Model settings also play a part. Anthropic's Sonnet 5.5 guide says the model generally checks its work, but at low effort it sometimes reports a change as done without running a check that exercises it. The guide suggests asking for a real test, type-check or build, and for the model to say so when no real check could run. Evidence matters because a claim that tests pass tells you little, and reading the output is quicker than rerunning them.

Example

Say Claude writes a function that counts the days in a date range, and it reads perfectly. Ask it to add cases for a range across a month boundary, a one-day range and an end date before the start, then run them. If the month-boundary case fails, you'll see it in the output. You'd otherwise be relying on a read-through to spot a mistake in date logic.

Going further

Watch for checks that pass for the wrong reason. Anthropic's docs warn that Claude can focus too heavily on making tests pass and suggest asking for a general solution, not hard-coded values. To enforce a check, add a Stop hook that exits with code 2 when your typecheck fails, which sends Claude back to work until it passes or reaches the block limit. A line in CLAUDE.md works most of the time, not every time. For review against a plan, ask a subagent to compare the diff to your spec and to skip style, since the guide warns that a reviewer asked to find problems will always find something. Anthropic's Fable 5 guide says fresh-context verifiers tend to outperform self-critique.

Common mistakes

  • Accepting "all tests pass" with no output. Ask for the command and what it printed.
  • Testing only the normal case, so empty inputs, boundaries and error paths are never run.
  • Letting Claude edit a test to get a pass without checking why it failed.
  • Assuming /rewind undoes everything. Checkpoints cover files changed with Claude's file tools, and a file changed only by a Bash command isn't restored, so keep using git.

Sources

Checked 6 November 2026. Products change often, so confirm details with the vendor.

Related

Beyond the course