Verify Like a Director

The Build Loop, same as every rung — spec, direct, checkpoint, verify. This rung sharpens the last turn: verify — the one that decides whether you shipped working software or collected plausible-looking files. It's the turn most people shortchange, and, honestly, the hardest one to hold.

You already know the difference between reassurance and proof. You've sat in status meetings where everything was "on track" and nothing was demonstrable. You know the gap between a direct report saying "it's handled" and that same report showing you the signed contract. Verifying an agent's work is that exact instinct, pointed at a faster, far more confident subordinate — one that will tell you "it works" every single time, mean it, and sometimes be wrong.

Tell verification from ceremony

Here's the tell that saves you the rest of this essay: ceremony produces reassurance; verification produces evidence you could hand to someone else.

Three things I did for weeks that turned out to be pure ceremony. Watching the code stream by — it looks industrious, and you can judge exactly none of it. Accepting "it compiles" as a milestone — an agent will happily produce code that passes every technical check and does nothing useful, because unless you say otherwise it optimizes for correct code, not a working tool. And asking "did it work?" — the answer is always yes, and the yes is worth what you paid for it.

Everything that actually protected my builds came down to four practices. They're the rest of this rung, and none of them require reading code.

Demand a demonstration, not a report

The verification that mattered most cost one sentence, written before the work started: a success criterion I could perform with my own hands. Not "the search feature is complete," but: "I can type a plain-language question, see results, and click one to open its source." I learned this by failing it — a cycle delivered a feature where everything technically worked and nothing was usable, because it leaned on three pieces that didn't exist yet. The fix wasn't better engineering. It was defining "done" as "I can use it," in writing, in advance. You already write acceptance criteria; you just call them something else. Write the sentence, then perform it yourself when the work comes back. If you can't perform it, it isn't done — whatever the report says.

Verify as you go, not at the end

I built two cycles without checking anything, then spent a third fixing what had silently broken. That was the whole tuition; skip it. Agent-built software fails a specific way: it works on the happy path — the everything-goes-right case — and breaks on the edges the agent didn't think to handle because they weren't in your instructions. Catch those cycle by cycle, while they're cheap. So every cycle ends with something I can try myself, immediately: a demonstration now, not a promise of integration later.

Make the system testify about itself

Here's the move that surprises engineers. I can't audit the code — so I make the software produce evidence a machine auditor can read, and my auditor is another agent. Every feature keeps a structured record of what happened on each run: inputs, outputs, timing, errors. When something breaks, I hand that record to a fresh agent and ask what failed; it reads five hundred lines in one pass and points at the break. You don't need to understand the record. You need to insist it exists — a director's demand, one line in the spec.

Make "release" mean something

My cleanest example of ceremony wearing verification's clothes: early on, the version number bumped every time a file was edited. After a week it was a session counter dressed up as a release history. The fix was separating saves from releases. Edits are saves. A release is a decision — an explicit step that checks everything, names a version, and archives a snapshot of what changed since the last one. Numbers that climb on their own verify nothing; meaning takes intent. Make "release" a thing someone does on purpose, and the release record becomes evidence instead of noise.

Turn the checklist into a receipt

Now make it reusable, because judgment should compound into something you keep. Every cycle, the same short list — and the agent fills it with evidence, not checkmarks:

• What was asked — the success criterion, quoted back from the spec.
• What was demonstrated — the thing you can perform yourself, and where.
• What the record shows — runs, errors, anything odd.
• What didn't get done — deferred items, named, so "done" isn't quietly hiding a scope cut.
• What changed in this release — when the cycle ends in one.

Notice what's on that list: demonstrations, records, releases. Notice what isn't: code. Every line is something a person who can't read a pull request (the format engineers use to review each other's code changes) can check — which was the constraint I started with, and turned out to be the discipline everyone should want.

The receipt is the review. You don't inspect the work; you inspect the receipt — and because you named what it had to contain before the work began, you can check it every cycle without reading a line of code.

But doable isn't the same as easy, and this is where the rung earns its place. Building is the half the agent does for you — faster, cheaper, all day. Verification is the half it can't: it will tell you "it works" every single time and mean it, and someone still has to decide whether that's true. That someone is you — not because you're the only one who can read the receipt, but because you're the only one accountable for what ships under your name. The agent builds; you decide it's done. That call is the harder half of the work, it doesn't delegate, and holding it is the whole difference between directing the build and watching it stream by.

→ The companion — In Tropo: Your First Receipt — has you write one performable success criterion, then build the reusable verification receipt you'll run on every job after.

Power Play

Don't verify a build with the agent that built it — it's the last one who'll tell you it's wrong. Open a fresh agent that never saw the work, and set it against you:

"Here is the spec, and here is what was built from it. Your job is to prove it does NOT meet the spec. Find every place the result falls short, every requirement that's missing, every case where it does something other than what was asked. Assume it's flawed, and show me where."

An agent told to find fault will find it. What survives that — what the skeptic can't knock down — is the part you can actually trust. This is how serious teams verify their own work: not by asking "is it good?" but by trying to break it and seeing what holds.

Terms worth knowing

• Acceptance criterion — a plain sentence, written before the build, describing something you can do with the finished thing. "Done" means you can perform it.
• Happy path — the case where every input is expected and nothing goes wrong. Agent-built software tends to handle it well and stumble everywhere else.
• Trace / record — a structured account of what the software did on a run: inputs, outputs, timing, errors. You don't read it; your auditor agent does.
• Release — a deliberate, named snapshot of the software, as opposed to an ordinary save. A release you can roll back to and compare against.