How I build with AI agents

I do not write the code. I decide what gets built, set the rules and red lines, and require proof that can fail. The agents write, test and release. This page is the method that grew out of more than 100 work packets, one failure at a time.

Three roles, fixed

• An architect model in chat writes each work packet and reads the report that comes back.
• A coding agent on the work machine implements, tests, releases and reports.
• I set direction and decide business rules, and anything that touches money, permissions or production.

A question I ask the architect gets an answer, not a changed packet. Nothing is done without being asked for, and a packet only says "Vincent decided" next to my own words.

Outcomes, not steps

A packet states the goal, why it matters, what done means, and every red line with its reason. The agent owns the how.

• If a premise turns out false, the agent stops only the item that depends on it. Everything independent keeps going.
• A premise about today's code names the file and function, and the first agent proves or refutes it before anyone builds on it.
• A sent packet is frozen. A change is an addendum that names exactly what changed, never a second version.
• The agent never stops to ask in chat. A step only a person can do goes into a list for me, and the next independent task runs.

The cost of a mistake picks the model

Every packet's first line names its run class. The class sets the model, the effort, the agent budget and the review.

The agent may raise a class when a trigger appears: a false premise, an unknown cause, a change that touches the judgment list, a major review finding, or a second failure at the same tier. It never lowers one. A cheaper model only gets work whose mistakes a higher layer will catch.

A different model reviews

A model checks what it already thinks matters. So the reviewer is a different model from the one that wrote the code: read-only, one pass, no sub-agents.

The reviewer does not write code. When it finds a problem, it writes the fix: which file and function, the failing test that must go green, what done means. A cheaper model carries it out, and the reviewer checks once more. In one packet the review and the re-check together cost less than the mid-tier executor that applied the four fixes, each one red first.

An adversary goes first

Before any code is written, a fresh agent that inherits nothing gets a brief written into the packet. It reads only the packet, the previous reports, the rules and the code, and its job is to make the packet fail. In one hotfix it found 15 points, including two blockers, and overturned my own guess about the cause, for about 3% of the packet's cost.

Proof that can fail

• Red first. The test is written and seen failing before the fix. A red run must reach every assertion, or the fixes after the crash were never seen red.
• A positive control behind every "nothing found". A "0 differences" compare is trusted only after it reports differences on a deliberately altered copy.
• A response code is a claim. A write is not stored until it is read back. A call once answered 204 and changed nothing.
• Every role shape, on the installed build. Admin-only proofs hid a slow path for a week.
• Performance three ways: a fixture, a copy of real data with the real code, and production before and after.
• A skipped branch fails. A copied test fixture once skipped eight checks without a word.
• A check never calls the code it checks. For money, recompute from the system of record's read-back.
• The checker suites are part of green. They have found real faults that builders, reviews and re-checks all missed.

Diagnose before changing code

• Write each hypothesis next to the run that would disprove it. Then read the logs.
• Instrument first. Per-job counters at 0.2% overhead turned "it feels slow" into a ranked list, and the fix worked on the first try.
• A bug report is a premise, and so is my own guess about the cause. Both get re-read against the data before anything is built.
• Find the cause one step before the symptom. A display bug turned out to be a flag set before any data was read.
• Locate an outage without credentials. Failed sign-ins count toward a lockout, so the first probe carries none.

One release per packet, gated

Every suite green, a signed bundle, every desk updated within the hour, my own desk included, so I see every change in daily work. Nothing ships half-done.

• The gates refuse a release that drops an earlier one, a failing smoke test, a reused version number, and a background-service change under an old version.
• Every release smoke test runs against the candidate before the release window, because the release costs a sign-in and stops at the first red.
• "Not released" is an allowed answer. A deadline is a sum of measured durations: full suites about 95 minutes, the release about 23, the end-of-run steps about 15. The day it mattered

Know what the bill is made of

Cost is context × turns × agents, not thinking. 89–96% of tokens are cached context read again; output is under 1%. So: clear the context per packet, send long output to files, let scripts wait for locks, and fan out only when the same check runs over many objects. The audit behind it

Parallel sessions, kept apart

Several sessions can run at once, each in its own working copy. Lock scripts let only one heavy test run use the machine at a time, and a session that needs the shared test desk messages the other first. A session that finds another has released merges and takes a higher version, because a version number names one build. The locks held with six packets running at once.

One fact, one field, one function

• A display rule lives in one function that every view calls. A list that applied a rule view by view missed the fifth view.
• A permission is one function that the page and the server both call.
• A sentence takes all its parts from one read. "X has had this since T" once took X and T from two different reads.
• A value that has not been read says so in words. It is never drawn as a guess, a dash or a zero.

Every rule has one home and a source

The rules live in one rulebook and a set of agent skills, each rule with the decision or measurement behind it. A replaced rule disappears from every document, and the history lives in a changelog. A rewrite moved 171 rules with a script proving every one arrived.

Lessons I bring to any system

• "Nothing found" is not a finding until a positive control shows the probe could have found something.
• A failed query is not an empty answer. Collapsing the two is how a status machine quietly goes wrong.
• Hiding data on a page is decoration. If a role must not see it, the server must not send it.
• A write is not stored until it is read back.
• The same fact kept in two places will drift. Give each fact one home.
• A deadline is a sum of measured durations, not a feeling about the size of a change.

How the method evolved

1. 2025First steps with AI in chat: procedures, spreadsheets, SQL
2. Mar 2026First automation inside the office suite
3. Jul 2026First four agent skills; an intake prototype with a copy-only extraction rule
4. Aug 2026A coding agent on the work machine; a resident service replaces two browser extensions
5. Sep 2026Work packets and reports; the platform goes live on 28 September
6. 1 OctToken audit; the cost rules
7. 13 OctParallel sessions, kept apart by lock scripts
8. 14 OctFour run classes replace one model for everything
9. 18 OctThe reviewer model only reviews; its fixes go to a cheaper model
10. Late OctA fresh adversarial agent tries to break each packet before code is written
11. Nov 2026Measure a machine with a read-only probe before setting anything up