Summary
In the first part of this series, an adversarial design review had found three real problems before a line was written. The obvious question was what kind of workflow makes that repeatable, and this article is my answer. It also asks what the answer changes for every role in the software development lifecycle.
The rule is short: the specification is the source of truth, the invariants are the contract, the code is an implementation of that contract. When something breaks, I first ask whether the specification is wrong or incomplete, fix it there, and only then let the AI realign the code, never the reverse. In a classic project a specification drifts out of date while the code keeps moving; with an AI reading it as truth, that drift becomes dangerous, because the next session reintroduces the old behaviour from the old document.
Around that rule sits an operating system: a concise CLAUDE.md that delegates to focused rule files, skills with one purpose each, one plan per feature that is the state of record, prompts versioned as project assets, and tasks kept small enough that done means evidence rather than impression. The day I asked for real output instead of a prediction, a suite announced green turned out to have 138 failures.
What surprised me most is that quality became cheaper. When the mechanical cost of tests, migrations and documented decisions collapses, the right way is no longer the expensive way; on this project the test code outweighs the production code. Every role moves from producing an artefact to defining constraints and judging correctness. AI writes the code; it does not decide whether the code is right. That still requires an engineer, and perhaps more engineering skill than before.
Key ideas
- The specification is the source of truth, the invariants are the contract, the code is an implementation of that contract: fix the specification first, then realign the code.
- A concise CLAUDE.md that delegates to focused rule files, one plan per feature as the state of record, and prompts versioned as project assets.
- One task, one file, one verification: done means the real output of the verification command, not a prediction that the tests should pass.
- Quality became cheaper: when the mechanical cost of rigour falls, tests, migrations and documented decisions stop being luxuries.
- Do not ask whether AI can write your code. Ask whether you would know if it was wrong.
Why I wrote this
In the first part, an adversarial design review found three real problems before implementation. The obvious question was what kind of workflow makes that repeatable; this article answers it.