Part

Verification

You might say: proof, evidence, prove it works, validation harness

The evidence that a change does what its spec asked. Scenarios run end to end against the real app or a twin of its outside services, and a run that did not write the code judges the result. When the evidence is strong, a person can check the outcome instead of reading the diff.

What it does

Moves trust from reading code to checking evidence, so human review can leave the critical path for low-risk work.

Ask

What evidence shows this change works, which run produced it, and could the author have gamed it?

What to look for

1. Scenario results and captured evidence attached to a pull request
2. A verifier run that is separate from the author run
3. A pass rate against scenarios the author never saw

Parts

• Spec: A written description of the shared design concept: what a piece of work must do and how anyone will know it is done.
• Scenario: A user story, written down, that a harness runs from start to finish against the built software.
• Holdout scenario: A scenario kept where the coding agent cannot read it.
• Digital twin: A local service that copies the behavior and edge cases of an outside dependency at its boundary.
• Self-verification: The agent runs its change through the repository's checks and real user paths, then claims only what it actually verified.
• Satisfaction: The fraction of observed scenario trajectories that probably satisfy the user.
• Non-determinism: The same ticket on the same code can produce a different change on each run.

Connections

• Lowers: Review queue
• See also: Merge policy

Sources

1. Simon Willison, How StrongDM’s AI team build serious software without even looking at the codeI’m particularly invested in the question of what it takes to have agents prove that their code works without needing to review every line of code they produce.
2. Lauren Tan, pstack, Verify the result and open a PRVerification is the slowest step in most agent work, because it's the step that usually waits on a human.
3. Justin McCarthy (StrongDM), Software Factories And The Agentic Moment, The PrinciplesYour validation harness must be end-to-end, as close to the real environment as possible
4. Delinea, The Delinea Software Factory: Building Software with AI, The Delinea Software FactoryIt’s what happens when validation replaces code review.
5. Kent C. Dodds, You Own the Outcome: Product Engineering in the Age of AI, Shipping a feature without writing itI didn't read that diff line by line. I read the outcome: does it do what we decided it should do, and did the gates I trust pass? That's only reasonable because of everything I'd set up ahead of time

Use it on your project

teardown-apply: hold "Verification" (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