Index  /  Working With AI  ·  Sheet 10 of 11

Working With AI

Roles · Specs · Standing rules

The AI & Philosophies sheet is what I believe. This sheet is what I actually do — the procedure that survives contact with a Tuesday. It reads like a shop practice because that is exactly what it is.

Three seats, not one assistant

The biggest single upgrade in how I work with AI was not a prompt trick. It was admitting that “the AI” is not one job. There are three seats at this bench, and the work went wrong for exactly as long as I let one chair try to hold all of them.

The Architect is me — final authority on structure, priorities, and what gets built. The seat that says no. The Documenter frames options, surfaces trade-offs, and writes everything down; it is explicitly barred from writing code. The Implementor writes all of the code, against a spec, and sees only what the task requires.

That last clause sounds like distrust. It is the opposite — it is signal hygiene. An implementor that cannot see the strategy cannot be biased by it, and when its bounded view produces a question the strategy can’t answer, that question is outside review I did not have to pay for.

SeatOwnsExplicitly barred from
Architect (me)Structure, priorities, the binding noBlaming the other seats for decisions this one made
DocumenterOptions, trade-offs, the recordWriting code
ImplementorAll of the code, to specStrategy — it sees the task, not the campaign
ARCHITECTdecides · the binding no DOCUMENTERframes · records · no code IMPLEMENTORall the code · to spec intent spec strategy stops at this line THE RECORDdecisions · failures · rules what happened what to decide next
Spec before code

A wish is “make it handle errors better.” A spec is the list of errors, what each one means, and what the machine does about each — written well enough that a capable stranger couldn’t misread it. AI made that distinction expensive to ignore, because unlike a person it will not stop to ask. It will confidently build the wrong thing at production speed.

So big work starts with alignment, not typing. Propose the shape, argue about it, revise it, and only then hand it to the seat that types. The arguing is not overhead — the arguing is the work. Code is what falls out the bottom when the argument is finished.

One clause in the procedure came from a scar: findings travel into a spec verbatim, never paraphrased. I watched a paraphrase of a review finding drift a few degrees from the original words, and the build followed the drift. Quotes are dimensioned features now. Paraphrase is a sketch, and nobody machines from a sketch.

Diagnosis before fix

When something breaks, the expensive reflex is the fix that arrives before the diagnosis. It compiles, it ships, and it quietly treats a symptom while the mechanism keeps running. So the protocol is mechanical: reproduce it, name the actual mechanism, and only then touch anything.

The same discipline applies when a tool hits a wall: name the wall, sort it — configuration, scale, or fundamental — price the fix against the bypass, and if I take the bypass, write down what didn’t get fixed. A bypass you forgot about is a fault you scheduled.

The standing rules

Pushback, not derailment

The calibration line, stated to the machine in the middle of an argument: I want pushback, not outright derailment. Bring the counter-argument, keep pulling on the rope. The best sessions have friction in them; this rule keeps the friction useful.

The transparency model

I tell the machine what I’m looking for. Always. I never trick it with a test, because an instrument calibrated on dishonest inputs is not calibrated. If I’m probing something, I say so — and I expect the same disclosure back.

Test the claim, keep the result

Any capability claim — memory, file access, retrieval — gets tested directly before I rely on it. A failed test is not a disappointment, it is data, and it goes in the record with the passes.

Quote, don’t paraphrase

Findings, rulings and requirements move between documents in their exact original words. Drift ships. This rule has a scar for a citation, which is the best kind of citation.

One tool per cycle

Map the structure, build the base, add one meaningful tool, refine it until it works as intended, then take the next one. Scope is a tolerance, and stacking ten loose ones guarantees the assembly doesn’t fit.

Ask the record first

If the logbook can answer it, ask the logbook — one query beats ten greps and an hour of re-deriving. Nothing should have to be learned twice. That is the entire point of keeping one.

The loop that pays for it

Every session ends by writing to the record: what was decided, what failed, and why. That is not paperwork — it is ore. Corrections that recur get promoted into standing rules, and then the rules do the correcting so I don’t have to. Nothing in the table above was designed on a quiet afternoon. Every rule was drafted mid-argument and earned its place by coming up twice.

How it all got this way is its own story, told in eras on the next sheet: the timeline of the black box.

Working tolerance

This procedure is rev-controlled like anything else I run. When a rule fails, the failure gets written down and the rule gets revised — in the open, as its own entry, never by quietly rewriting history. A procedure that can’t cite its own scars is a poster, not a practice.

← Process ControlThe Black Box →