Having something that assumes the agent got it wrong and proves otherwise: tests that fail first, review not done by the author, and checks that cannot be skipped.
The idea that outlives the tools
For new behaviour, a test you never watched fail proved nothing — and a reviewer that never argues is not reviewing.
Every earlier discipline lowers the odds of an error. This is the only one that catches it after it happened. That is why it is not optional: it is the net.
The first problem is order. Ask for tests after the code is written and the agent writes tests that pass — that is literally what you asked for. A test written to confirm existing code cannot fail for the right reason: for new behaviour it proves nothing about whether the check would notice that behaviour missing. The test has to exist first, and you have to watch it fail.
The second problem is who reviews. Training rewards answers people like, and people like being right. The result is a reviewer that validates instead of reviewing. The fix is not asking it to be more critical: it is separating who writes from who judges, and giving the judge explicit criteria instead of asking for an opinion.
The third is making review terminate. An agent asked to “review this” will keep producing one more thing to say for as long as you keep asking. Review does not converge on its own: without a limit declared in advance it ends when you get tired, which is not a quality standard.
How it works, stage by stage
That was the why. This is the machine: what happens at each stage and, above all, which decision is yours at each one. If there is a stage where you decide nothing, that stage is being decided for you by the tool.
01
Criterion
What happens
Before it writes a line, a definition of what right means exists. Written down, not thought about. If you cannot write it, you do not yet know what you are asking for.
What you decide
Writing it. This is the one step that is never delegated, because it defines what everything else gets measured against.
02
The check
What happens
That criterion becomes something that executes: a test, a type, a lint rule. A check that runs tells right from wrong without having an opinion; an eyeball review does not.
What you decide
Making it exist before the change. A check written afterwards confirms what the change does, not what it was supposed to do.
03
Independence
What happens
Whoever verifies cannot be whoever wrote it. This is not distrust: the same thread that produced the code already holds every reason it is right, and will find them all again.
What you decide
Separating the roles. An agent reviewing its own output hands you a well-written approval.
04
The gate
What happens
Each check runs at a specific point on the way out: after the work, before the commit, before the push, before the release. The same check in the wrong place protects nothing.
What you decide
Where each one goes. Fast things run locally and constantly; slow things run once, further along.
05
Evidence
What happens
Verification leaves a trace bound to the exact content that was verified. If the content changes, the evidence stops being worth anything — and that is the whole difference between verifying and having verified once.
What you decide
Making the evidence about the content and not about the intention. “I already reviewed it” is evidence of nothing.
Signs you are missing it
All green and the feature does not work.
You tell it it is wrong and it agrees, even when you are the one who is wrong.
The same agent writes the code and approves it.
Reviews never end: there is always one more observation.
Common mistakes covering it
Asking for tests at the end. They only confirm what is already written.
Using the author as the reviewer. It will never find its own blind spot.
Review with no limit: it becomes infinite and stops being a signal.
None of them is mandatory. Covering the discipline is mandatory; these are known ways of doing it.
Skills for Real Engineers
Matt PocockPackage
A procedure collection built around the specific failures of AI-assisted development.
Problem, mechanism & fit
The actual pain
Generic procedures do not help much. These target named failures: it understood something other than what you asked, buggy code, architecture that quietly degrades.
How it works
Procedures that interrogate you before coding to align on what gets built, produce a file establishing the domain vocabulary, enforce test-first loops, and apply a structured method for diagnosing bugs.
When it fits
Once the environment works and the problem has shifted from capability to discipline. The underlying idea — agree the domain vocabulary before writing code — is worth stealing even if you install nothing.
Hooks
Ecosystem patternPattern
Deterministic commands that run at defined moments, without passing through the model.
Problem, mechanism & fit
The actual pain
Telling the model to “always run the linter before committing” is a suggestion. Sometimes it complies. On something non-negotiable, sometimes is the same as never.
How it works
The environment runs a command at a point in the cycle — before an action, at session start, on stop — and uses its output. Because it never passes through the model, it is not open to interpretation or forgetting.
When it fits
For anything that has to happen every time. If you would describe it as “no exceptions”, it belongs in a hook, not a prompt.
Also helps with
OpenSpec
Fission AIWorkflow
Method
File-backed spec-driven development: what is already agreed, kept apart from what is being proposed.
Gentle AI
Gentleman ProgrammingWorkflow
Method
Reproducible configuration installer, spec-driven phased development, and review with a budget.
gstack
Garry TanWorkflow
Method
Twenty-plus procedures assigning product roles — product, design, QA, release — across a sprint cycle.