Process

Self-verification

You might say: run your own change, author proof, evidence capture

The agent runs its change through the repository's checks and real user paths, then claims only what it actually verified. A separate verifier judges the result because an author naturally checks what it meant to build.

What it does

Gives the next gate evidence from an exercised change instead of a summary from its author.

Ask

What did the agent run, what evidence did it capture, and who other than the author judged it?

What to look for

1. A run that starts the app and exercises the changed path
2. Evidence links attached to the run or pull request
3. A fresh verifier that reads the result cold

Connections

• Made from: Control CLI
• See also: Automated review

Sources

1. Kent C. Dodds, kcd-skills, autopilot skillAgents run their own change before merge and claim only what they verified.
2. Kent C. Dodds, kcd-skills, autopilot skill, references/verification.mdAn agent that starts the app, signs in, and asserts on real responses catches its own bugs before merge.
3. Lauren Tan, pstack, ShippingOnly a verdict from an agent that did not write the code counts, because an author checks what it meant to build.
4. Lauren Tan, pstack, ShippingGreen CI and an approving bot review are not verdicts, because neither runs the change as a user would.
5. Matt Pocock, AI Coding Dictionary, HallucinationHallucinated code is plausible by construction: it's what the API would look like if it existed, which is exactly what makes it slip past a skim-level review and fail only when run.

Use it on your project

teardown-apply: hold "Self-verification" (self-verification) from the teardown at https://teardownatlas.com/software-factory/ against my project

Paste it into a coding agent that has the teardown skills.

An AI agent wrote this map with the teardown skill. It can contain errors: check the sources before you rely on a part. About and legal