How I work with AI agents
Agents work alongside me. Evidence decides when something is done.
I build my products with AI agents working alongside me. That makes building fast; it does not make it right. So the method turns on one question every change has to answer: what evidence shows it is done?
The rules come from how engineering organisations already separate and review work, scaled to one accountable person working with agents. They are written down, enforced by checks where it matters, and adopted product by product.
The life of a change
- intent
Who needs what, and why now.
- context
What exists today, read from the source, and what constrains it.
- expectations
What we will observe when it works, and the failures that matter.
- spec
What should happen, written before the code and kept current with it.
- plan
The smallest complete slice, with the checks that will prove it.
- code
First a check that fails for the right reason, then the implementation.
- tests
The checks run on the exact candidate, and their output is kept.
- review
Every change closes on its evidence. A change to a sensitive area is also read by a separate agent that did not write it.
Then a release, which I decide. What is live is what production reports, not what the code says.
Who decides what
- Me
- I name outcomes and set the rules. I decide what goes live, what is spent, and anything legal or customer-facing. I read results in batches instead of approving every item.
- The building agent
- Shapes the work and keeps spec, design, tests and documentation in step. It proves behaviour with a check that fails first, and records exactly what ran and what it returned.
- A separate reviewer
- An agent that did not write the change. It reads the change against the original acceptance, not a summary, and looks for defects, not style.
- Automatic checks
- Where a product has adopted them, they refuse a change whose plan or evidence is missing, refuse a push to a sensitive area without its review, and generate plans and release notes instead of having them typed.
Five words for done
Done is five different states, each with its own evidence.
- implemented
The change exists and its checks ran.
- reviewed
A reviewer that did not write it has read it, and nothing is open.
- published
It is in the shared history, past every check.
- deployed
Production reports this exact version.
- accepted
The outcome it was for is confirmed, when that is in scope.
A status says which of the five it reached. Local success is never reported as shipped.
Four practices, one loop
Spec, design, tests and documentation are one loop, not four documents. The spec says what should happen; design resolves how it works, including its states and failures; a test that fails first proves the check can tell right from wrong; documentation is drafted early and followed at the end.
When reality disagrees with the spec, that is a defect or an explicit decision, never a reason to quietly rewrite what was agreed.
If we work together
- I show you the spec before the code.
- I have changes to sensitive areas reviewed by a separate agent before they are pushed.
- I tell you which of the five states something is in.
- I decide each release deliberately, and I read what is live from production.
- I change the documentation with the behaviour it describes.
The project brief asks the same three questions this method starts from.
Start with intent, context and expectationsMore on the method
One person, many agents, no approval queue
Agents make building fast, so the waiting moves to review. How I borrow separation of duties from engineering organisations instead of approving every change myself.
Five words for done
Implemented, reviewed, published, deployed, accepted. Five different states, each with its own evidence, and why collapsing them into one word causes surprises.