lemon Lesson 6 of 7 · 5 minutes

Verify the result

Ask for the smallest useful proof, then check the artifact instead of trusting a summary.

An agent can give a fluent account of work that is incomplete, aimed at the wrong target, or never actually checked. Treat the summary as a map to the evidence, not as the evidence itself.

Ask what could prove the change wrong

Start with the smallest focused check capable of failing for this specific change. Then run the normal project check when the risk justifies it.

For a bug fix, the strongest pattern is a before-and-after pair:

Reproduce the problem and show the failure.
Make the change.
Run the same probe and show it passing.

For a visual change, inspect the rendered page. For a data transformation, compare a small known input and output. For a build-system change, run the command that future users will run.

When the same check matters repeatedly, save it as a small command instead of rebuilding the procedure in each prompt. The agent can decide when the check applies; the command can perform the exact measurement consistently. This is how verification becomes part of the working environment rather than a habit that depends on memory.

Good reports include limitations

“The build passes” is useful. “The build passes, the focused check covers the new behavior, and I could not test the screen reader” is better. A named gap lets you decide whether to accept it or add another check.

Prefer nouns over adjectives: a URL, diff, test result, screenshot, or output file tells you more than “robust,” “complete,” or “production-ready.”

This really happened. A health check with a broken file path reported “nothing wrong” on its very first run, and a fix shipped on the strength of that reassuring nothing. The check could not fail, so its pass meant nothing. That is why a brand-new check should fail at least once before you trust it: entry AF-01 on the watch-out list.

Go deeper with Prove it before and after.

Try it

Make the call

Pick an option to see how the rest of the session plays out.

you

You said the mobile menu fix is done. Before I look: how do we know?

Which completion report gives you evidence rather than confidence?

A“Done. The implementation is robust and production-ready.”

you

Which check did you actually run?

agent

I reviewed the code carefully. It follows solid patterns.

you

So nothing ran. On my phone the menu still overlaps the logo.

not yet

Confidence adjectives are not checks. Nothing here tells you what ran or what you can inspect. AF-04

B“The focused navigation check passes, the full build passes, and the diff contains two files. I could not test VoiceOver.”

you

Show me.

agent

Here is the build output, the focused check that fails if the links overflow, and the two-file diff. The VoiceOver pass I couldn’t run in this environment, so that gap is yours to accept or to test.

you

I can tap through each claim. The one thing not checked is labeled, not hidden.

good call

You get named checks, a bounded change surface, and an explicit limitation. Each claim can be inspected.

C“All tests pass, so the requested behavior is correct.”

you

Which of those tests fails if the menu overflows?

agent

None. No existing test covers the menu.

you

So the suite was green before the bug and green after. It never saw the thing we changed.

close, but

Passing tests matter only if they cover the requested behavior. Ask which test was capable of failing for this change. AF-05

Take it to your tool

Try this in your agent

With the project open in your coding agent, paste:

Verify this change with the smallest focused check that could prove it wrong, then run the normal project check if appropriate. Show me the exact result and any limitations. Do not summarize a check you did not run.

Got the idea?

Mark it complete on this device. You can return or reset the course at any time.