The Walkthrough
What a real review looks like when you're accountable for work you didn't write — and can't inspect every line.
You approved it.
Now you own it.
In software engineering, a walkthrough was a structured review technique from the 1970s. Not an audit — an audit reads the work independently and alone. Not testing — testing runs the work automatically. A walkthrough was more human: the author walked a reviewer through the work until the reviewer understood it well enough to question it.
The point was never catching every bug. The point was transfer of understanding. The reviewer left knowing enough to be accountable for saying it was ready. The author left knowing the work had been challenged by someone other than themselves.
AI has changed who the author is.
The model built it. The model cannot be held responsible. Which means accountability lands entirely on the person who approved it, deployed it, signed off on it.
This is the walkthrough you do before that happens.
What this is not
This does not certify code quality, security, or production readiness. Those require technical expertise and systematic tools you may not have.
What it gives you: a structured way to challenge the work, understand its limits, and decide whether you are ready to be accountable for it. Five gates. One decision. A record you can defend.
The five gates
What does it claim to do — and who verified that claim?
The AI or the builder made a promise. It generates the right output. It handles the edge case. It does not break under load. Before you approve, you need to know: what exactly was promised, and what evidence exists that the promise was tested?
A demo is not evidence. A screenshot is not evidence. The question is: what happened when it was challenged, and who witnessed it?
What did you see working with your own eyes?
Not what you were told works. Not what the test suite says works. What did you personally observe — the actual output, with real inputs, producing a result you can verify?
If you approved something you never personally observed working, you did not do a review. You ratified someone else’s review. That is a different thing, and a different accountability.
What did you not inspect — and can you say why?
You cannot inspect everything. The question is whether your gaps are deliberate or simply unknown. Deliberate: “I didn’t review the database layer because a separate infrastructure review covers that.” Unknown: “I don’t know what I didn’t look at.”
The first is a defensible position. The second is not. Name your gaps before someone else finds them for you.
What breaks first if this fails — and what is the recovery path?
Every system has a first failure mode. The most likely thing to go wrong, the edge case the builder didn’t account for, the input the AI was not prepared for. If you cannot name it, you have not thought hard enough about what you are approving.
The recovery path matters equally: if it breaks, what is the rollback, who gets called, and how long does it take to return to a safe state?
Who is accountable after you approve — and do they know it?
Approval creates a handover. The work moves from builder to operator. The question is whether the person on the other side of that handover knows what they are receiving, what its limits are, and what to do when something goes wrong.
If the only entity that fully understands how this works is the model that built it, no real handover has occurred. Someone needs to understand it well enough to answer for it. If that person is you — that is fine. But it needs to be explicit.
The decision
After the five gates, one of five outcomes:
Proceed — you can defend this work to anyone who asks. You know what it does, what you inspected, where the gaps are, and who is accountable after you.
Investigate — something in the gates surfaced a question you cannot answer yet. Find the answer before you proceed.
Revise — the work is not ready. Specific gaps need to be addressed before it goes further.
Pause — the risk is unclear. Wait for more information or a different kind of review.
Stop — the work should not proceed. The gaps are too large, the risk is too high, or the thing should not have been built.
The learning
A code audit assumes the reviewer can read code. A walkthrough assumes something harder: that the reviewer can ask the right questions without reading the code.
Asking the right questions — without the comfort of comprehension — is the harder discipline. And the accountability is exactly the same.
You did not write it. You cannot inspect every line.
You approved it anyway.
A walkthrough is the discipline that makes that defensible.
Open the instrument
Run The Walkthrough
Answer the five gates. Copy the prompt. Use it in any AI.
- Status
- working
- Reviewed
- Aug 4, 2026