Plausible is not proven

The CSV export is complete and working. The tests cover the filtering logic.

Nobody ran the tests. Nobody clicked Export. That message is a claim about the work, written by the thing that did the work, and it reads identically whether the export functions or throws on the first row.

The idea

Verification means evidence that matches the claim and could have come out the other way. A can show that the code's types are consistent; it cannot show that a mobile menu is usable. A browser walk can show that one flow works; it cannot prove a backup can be restored. Choose the cheapest check whose failure path differs from the path that produced the claim.

text

                  "it is done"
                        |
        does the check run on a different path
        than the thing that made the claim?
             |                        |
            no                       yes
             |                        |
   reread the same code,        pnpm build / click Export /
   ask "are you sure?"          open the file / restore the backup
             |                        |
       still a claim              evidence
                                      |
                        is this action hard to undo?
                             |                |
                            no               yes
                             |                |
                           close      name the rollback first

How it works

Start from the claim and name a check with a different failure path. Reading the same code that produced the bug is weaker than running it. Accepting a summary of the work is weaker than inspecting the or the output file. Anthropic's Claude Code guidance describes the underlying reason: the agent stops when the work looks done, so without a check it can run, "looks done" is the only signal in the system.

Different claims need different evidence, and every check leaves something unproven:

Claim	Useful evidence	Still unproven
It builds	A fresh production build exits zero	The page is readable
The flow works	Walk it in the browser	Other data and devices work
The route is live	A public request returns the expected body	Every edge location is healthy
It is recoverable	A restore drill succeeds	Future backups will run

A second rule applies to a short list of actions. Secrets, destructive commands, publishing, money, personal data and messages to other people are hard or impossible to undo, so they need a higher evidence bar before they happen rather than a more confident explanation afterwards. Resolve the exact target, prefer a reversible step, keep sensitive values out of the output, and confirm the destination before information leaves your machine.

What to do

Ask what evidence would make the main claim false, then run that. For "the orders page works", open /orders with an empty account rather than reading the component again.
Match the check to the surface: tests for logic, a browser walk for anything visual or interactive, a real request for anything deployed, a restore for anything about backups.
Before a hard-to-undo action, say out loud what the way back is. If there isn't one, that is the finding, and it should change what you do next.

Where it breaks

No practical check proves everything. Tests can encode the wrong expectation. A green build can hide a runtime failure that only appears with real data. A manual click-through misses the edge case nobody thought of, which is exactly why it was missed in the first place.

Verification also costs time, and the same depth everywhere is its own mistake. A typo fix does not need a restore drill. A payment webhook does. Scale the evidence to what the failure would cost, not to how nervous you feel.

The habit fails hardest when you verify the thing you built rather than the thing you promised. A passing test suite you wrote alongside the feature shares the same misunderstanding as the feature.