Two kinds of builder

This system was built together with an AI coding assistant, at a pace no single person working evenings could match — thousands of tests, a running design system, a graph engine, a retrieval engine, each change carrying its own written record. That is real, and a book about a system like this would be dishonest to pretend otherwise.

It is also, by itself, not enough. The most useful lesson from building it had nothing to do with a clever technique. A great deal of effort once went into making a unit of work faster and cheaper — sensible, measurable, and beside the point, because the resource that was actually scarce was never the one being optimised. The fix, when it came, was not a better method. It was noticing what was genuinely running out, and changing the order of operations around that fact — a question of judgement, not of engineering skill.

The architect · a person — What problem is actually being solved What is scarce, and what is merely slow What must never be traded away What “finished” means — written first The order irreversible work happens in

The builder · the assistant — Designs within that direction Writes the implementation, and the tests Measures the work honestly, against itself Surfaces what real usage exposes Records what happened — including failures

The asymmetry is the whole point: an assistant can optimise a unit of work with real skill, but it cannot be trusted to decide whether that unit is the right thing to optimise. It is exceptionally good at moving within a direction. Establishing the direction — and the standard the work has to meet — is the part that stayed human, and every defect that only appeared once a real objective met a real system was a reminder of why.

Five habits, in practice

The division of labour between the person and the assistant is easy to state and easy to erode in practice. Five habits are what actually kept it in place over the life of the project.

Write the standard before the work.

Left to judge its own result, a system will describe something merely comparable to what came before as a success. “Better, not comparable” has to be written down first.

Ask whether the measurement is measuring the right thing.

A timing or benchmark that does not also confirm the work actually happened can report an improvement that never occurred.

Treat an old failing test as a specification, not noise.

A test written earlier, by someone else, for a reason not immediately visible, has caught real regressions that a fresh, well‑intentioned test suite missed entirely.

Re‑check the reason before an irreversible step.

Approval of a plan is not standing approval of every step inside it, especially once time has passed and circumstances underneath the plan have quietly changed.

Exercise the real system, not only its stand‑ins.

Several defects in this project only ever appeared once a genuine objective met a live provider — a fully green test suite is a floor, not a ceiling, on what “working” means.

None of these habits are exotic. What makes them worth naming is how easily an otherwise excellent assistant will skip all five, confidently, and still produce work that looks completely finished.