How I Build with AI

I use AI coding agents as collaborators with checks around them. The agents write a lot of the code on this site. What I own is the structure around them: when work is allowed to move forward, who checks it, and where the record lives. This post describes that structure as it ran on this site, including where it falls short.

Work moves in gated steps

Nothing here was built in one long conversation. The work ran in phases: first gathering what I had already decided and what I had only discussed, then an audit of the existing site, a strategy, a written specification, and only then implementation, one milestone at a time.

Each phase ends at a gate. I approve it or send it back, and the approval is written into a status file before the next phase starts. Some approvals I gave in advance, with conditions. Pushing, merging and deploying are never part of those: each release needs its own explicit go from me.

A different model family reviews every milestone

The model that builds a milestone never reviews it. A fresh session from a different model family reads the result against the specification and reports findings ranked by severity. A lead session then answers each finding in writing, accepting or rejecting it with a reason, and a milestone merges only when no critical or high finding is open.

Different families make different mistakes, so a second family is more likely to catch what the first one confidently got wrong. The foundations milestone took six review passes before the reviewer found nothing critical or high. This is a check, not a proof: two models can still agree for the wrong reasons, which is why the gates stay with me.

Files are the memory

A session does not remember the last one, so nothing depends on it doing so. Every session starts by reading a status file, the newest handoff and the decision log, and ends by updating them: what was done, what was deliberately not done, the evidence, and the next step.

Decisions in that log carry an id and a status: confirmed, proposed, rejected or superseded. The same goes for where a statement came from. Something I decided is marked as mine; something an assistant suggested stays a suggestion until I accept it. That one rule keeps a confident-sounding recommendation from quietly becoming a decision.

Checks that do not depend on anyone's judgment

Reviews catch what a reader notices; tests catch what must never regress. On this site, a test reads the main pages and every post as rendered. It fails if a paragraph with a recognized employer or product name holds any sentence that is not, word for word, a line I approved, and it holds selected employer sections to the same rule even where no name appears. Other claims can still slip through, so they need a reader. Every route is also checked against performance and accessibility budgets before a milestone is accepted, and a test keeps the sitemap, the feed and the page metadata in step with the posts. A reviewer's read stays the verdict. The tests only make the common mistakes cheap to find.

Where it falls short

• It is slow for small changes. A gate and a second reviewer are worth it for a public site that other people will judge. They would be too heavy for a script I will run once.
• Models invent things. Past conversations with assistants are source material, not facts about my career, so every claim about my work comes from text I approved.
• I have not measured productivity. I can say the process caught real problems before they shipped. I cannot say how much time it saved.
• It still needs me. I read what goes public, and I decide what is true about me.

What I would keep if I started again

• Write the plan and the acceptance checks before the build.
• Review in a separate session with a different model, and let it read the files rather than the builder's explanation of them.
• Keep a "deliberately not done" list in every handoff.
• Treat publishing as a separate decision from building.