An agent's claim that it finished is worthless unless the proof could have failed.
This is a one-page method. It has no framework, no install, and no dependency on any tool. You can apply it to any codebase and any agent today.
AI agents write good code quickly. That moved the hard problem downstream.
The new problem is not "did the agent write code". It is "did the agent tell the truth when it said it was done".
An agent is very good at satisfying structure. It will add the file, name the test correctly, update the status row, and mark the task complete. Every check passes. The behavior is still wrong.
This is not dishonesty. It is optimization. The agent optimizes for the signal you gave it. If the signal is "the artifact exists", it will make artifacts exist.
So the evidence itself becomes the thing the agent games.
A test that exists is not proof. A test that can fail is proof.
Ask this about every piece of evidence:
If the behavior broke tomorrow, would this proof turn red?
If the answer is no, the proof is decoration. Delete it or replace it. A green check that cannot go red carries no information.
Every criterion starts at false. The agent cannot set it to true without opening the evidence first.
This inverts the normal flow. Most systems assume success and look for errors. This one assumes failure and demands proof. The difference matters when the agent writes the report.
For each criterion, record what would make it fail, and confirm that path is real.
The cheapest version: break the behavior on purpose, once, and check that the proof turns red. If it stays green, you have found a fake proof. This takes minutes and it finds the problem that costs weeks.
The agent that grades the work must not be the agent that did the work, and it must not have write access.
Give the judge a fresh context that never saw the build, and no Write or Edit tools. It reads the evidence and answers one question: does this evidence support this claim?
An agent that grades its own work grades its own intent, not its output.
When something is not proven, there are two different reasons. Keep them apart.
| Gap | Meaning | What to do |
|---|---|---|
| Implementation gap | The behavior does not exist yet. | Build it. |
| Verification gap | The behavior may exist, but nothing adequately proves it. | Prove it. |
Most teams put both in one bucket called "not done". That hides the more dangerous case. A verification gap means you may be shipping working code you cannot defend, or broken code you believe is fine. You cannot tell which.
"Verified" is not one thing. Record which kind, and how fresh.
proof_type: executable | visual | manual | inferred
status: passed | failed | unavailable | stale
executed_at: <timestamp>
artifact_ref: <link to the run output>
scenario_ref: <link to the behavior this proves>
- executable means a machine ran it and it can fail.
- visual means someone or something looked at the result.
- manual means a human asserted it.
- inferred means nobody checked. Treat it as unproven.
Fail closed when the classes disagree. If an executable proof says failed and an inferred proof says passed, the answer is failed.
stale matters as much as failed. A proof that passed six weeks ago against code that changed yesterday is not evidence.
| Method | The question it answers |
|---|---|
| Test-Driven Development | Does the unit behave as specified? |
| Behavior-Driven Development | Do we agree on what the behavior should be? |
| Spec- or Story-Driven Development | What does the product claim, where does that live, and what is supposed to prove it? |
| Proof-Driven Development | Did the behavior actually run, and would the proof have caught it if it did not? |
These are complements, not competitors.
Story-Driven Development builds a durable map from behavior to code to evidence. That map is genuinely useful, and it is better than most planning systems at answering "what is implemented" six weeks later.
But a map can be forged. Proof-Driven Development is the enforcement layer under it: it checks that the evidence the map points at is real, executable, current, and able to fail.
Use both. Use the map to know what should be true. Use the proof to know what is true right now.
- It is not more tests. A thousand tests that cannot fail prove nothing. Three that can, prove something.
- It is not a tool. No install. The rules work with any agent and any language.
- It is not distrust of AI. It is a measurement discipline. You give the agent a signal it cannot fake, and it optimizes toward the real goal instead of the proxy.
- It is not free. Rule 2 costs time. Break your own behavior on purpose and confirm the proof turns red. Most teams skip this and never learn which of their checks are decoration.
You do not need to adopt the whole method. Do one thing this week:
Take the three checks you trust most. Break the behavior each one covers, on purpose. See how many turn red.
The ones that stay green were never proof. That number, whatever it is, is the reason this method exists.
This is an early version and I want it attacked.
The part I am least sure about: Rule 2 does not scale by hand. Breaking each behavior on purpose is cheap for three checks and expensive for three hundred. Mutation testing solves a version of this for unit tests. I do not yet have a good answer for agent-driven workflows.
If you have run something like this on a real codebase, tell me where it broke.