Method
Agents do the typing. Principals answer for it.
AI agents write, test and review most of our code. That is why we are fast. The method below is why you can trust the result.
Five steps
Spec
We write down what the system must do, from the running product and from you. You sign it.
Plan
The spec becomes milestones. Each milestone has checks a machine can run and a price.
Build
AI agents write, test and review the code. A principal directs them and makes every judgment call.
Prove
A model from a different vendor tries to break the work. The checks run. The principal reads and signs.
Hand over
You get the code, the evidence file and the decision log. Nothing depends on us staying.
The loop every change goes through
One ticket at a time. The same path for a one-line fix and a six-month rebuild.
- Spec
Exit checks a machine can run. Signed by you.
- Agents author
Implementer and test author work one ticket at a time, in a branch.
- Review lanes
Architecture, security, accessibility, performance, types, contracts. One narrow brief each.
- Adversary
A model from a different vendor is told to refute the pull request’s claims.
- Checks run
Lint, types, tests, budgets, parity. Pass or fail in CI, not in a status report.
- Principal signs
A person reads the diff, the checks and the log, and puts their name on it.
Who does what
Each agent gets one narrow brief and nothing else. The brief is a file in your repository, so you can read it, change it and keep it.
| Role | Brief |
|---|---|
| Spec writer | Turns the running system and your answers into a spec with exit checks. |
| Implementer | Writes the change in a branch, one ticket at a time, inside the spec. |
| Test author | Writes the tests the spec asks for. Separate from the implementer. |
| Review lanes | Architecture, security, accessibility, performance, types, API contracts. Each a separate reviewer with a narrow brief. |
| Adversary | A model from a different vendor, told to refute the claims in the pull request. |
| Principal | A person. Directs the agents, makes every judgment call, signs the milestone. |
Eight rules
We hold ourselves to these on every engagement. You can hold us to them too.
- 01
Spec before code
Nothing is built until what “done” means is written down and you have signed it.
- 02
Machines run the checks
A check is a command with a pass or fail result. It is not an opinion in a status report.
- 03
Nobody grades their own work
The model that wrote the code does not review it. A model from a different vendor tries to break it before a person reads it.
- 04
A principal signs every milestone
A named senior engineer reads the diff, the checks and the decision log, and puts their name on the result.
- 05
Every claim cites its evidence
A file, a command or a record. If we cannot show it, we do not say it.
- 06
Decisions are written down
Each trade-off gets a short record: the options, the choice, who signed.
- 07
The last payment waits for the checks
Part of each milestone is due at its start. The rest is invoiced only after its checks pass.
- 08
Nothing depends on us
The code, the accounts, the documents and the checks are yours from the first day.
What you can open at any time
- The spec, with its change history.
- The plan: milestones, checks and prices.
- The check results for every milestone.
- The decision log.
- The record of which parts agents wrote and who reviewed them.
Where the time really goes
With agents, code arrives in weeks. The slow parts are proving the new system matches the old one, getting decisions made, and switching over without losing customers or search traffic.
So we plan those first. Every quote names who decides what, and how long a decision can wait before the schedule moves.
See the method applied to this site.
The build record is measured from the files your browser just downloaded.