I ship a data product on my own. AI sessions do most of the typing. This is a map, not a manual:
three parts, one idea each. Each has a deeper post coming.
What changed for me: the bottleneck stopped being how fast code appears, and became whether I can
trust what appeared. All three parts are answers to that.
1. Context — what the model always sees
Everything in the model's reading room is paid for on every request and competes for attention with
everything else. So I keep two piles.
Always loaded: who this session is, where we are, and the handful of rules where being wrong is
expensive. Plus a one-line index of everything else, and two pieces of pure orientation: which
station of the cycle we're on, and who else is in the room — chiefly the notary, the program
that inspects every commit and refuses the ones that break a rule. A session that doesn't know the
notary exists will write around it by accident and then be surprised.
The library: 26 books, each on one subject, pulled only when a task needs one. A book read once
a month shouldn't be paid for a thousand times. The always-loaded pile carries the index; the books
themselves stay on the shelf.
What decides the pile isn't size, it's cost of not knowing it.
Two ceilings, on two different clocks:
| charged | ceiling | today | |
|---|---|---|---|
| the always-loaded pile | once, at session start | 10,000 tokens | ~7,000 |
| the rules re-injected on every message | every turn, forever | 1,000 tokens | ~600 |
The second one is the dangerous one, because it never stops being charged.
And the mechanism I'd copy into any project: the always-loaded pile has a ratchet that turns one
way. It can only shrink — a new rule enters only if an old one leaves. Without it, that pile grows
forever, because every lesson feels important the day you learn it.
2. Harness — what the model can reach, and what stops it
Harness is everything around the model that isn't the model. Mine, counted today:
- 20 written procedures it invokes by name — "run the night ritual", "attack this design cold", "plan an unattended window". Files, versioned, improved when they fail.
- Workers with deliberately different tool sets. The one that writes code gets its own copy of the repo and cannot touch the main branch. The one that measures something is denied read access to our design documents — so it can't agree with us by contagion. That denial is a program that refuses the read, not a line in a prompt.
- 11 automated checks, three of which fire before a tool call runs and can refuse it. The model doesn't decide whether an action was allowed; it finds out it wasn't.
I counted all of that for the first time while writing this. Nine of the twenty procedures are
dead — six never invoked once, three abolished by a decision I signed myself and never removed.
And counting turned out not to be enough: five of the dead ones are the only written charter of a
department that is still busy, so unused and safe to delete are not the same thing.
The ladder
The ladder isn't machinery. It's one question, asked of every rule you write: if this gets
ignored on the worst day, what actually stops it? There are only four answers.
① a sentence in a document the model may or may not follow it
② a program on my machine runs on save; I own the off switch
③ a program on a server runs after the work leaves me; no off switch
④ a capability that doesn't exist not a rule — the action is impossible
Every rule sits on exactly one. That turns "I have a rule about that", which can't be checked, into
"that one sits at ②", which can.
Then I asked the next question — which of my ③s has a test proving it actually refuses? — and
three came back with none. They were the three that run where I can't see them: inside a subagent,
and overnight. A gate you never watch is a gate you never proved.
3. The Round — and the three decisions inside it
Work runs in rounds. A round isn't a sprint: it's a loop that always opens the same way, and it
has decision points that send it down different paths.
Three things in it are worth stealing.
- Station 2 is the point. Every Round opens by measuring what the last one predicted against what happened — from the written estimate, not from memory.
- Two diamonds refuse to go forward. Work that overran doesn't get extended; it dies and has to win the next round. A plan that isn't worth arming goes back to design — including when it's too empty, because starting a run costs the same either way.
- The last diamond picks the shape. Fits in one context → one session that runs to completion. Doesn't → a chain of fresh ones: costlier per link, but it survives its own context filling up.
Either shape includes a redteam pass: a reviewer that gets the artifact and the repo and
nothing else, because explanation is what makes a reviewer agree with you.
And the unglamorous half
Three of the nine stations aren't work — they're bookkeeping, and they're the ones that get left
out of diagrams. They maintain the service files: the dashboard, the law (one line per decision,
never re-argued), the plan, the verification records, the library index.
I finally measured what that costs: 58% of my commits touch one of those files, and they are 8.9% of the lines changed. Very high frequency, almost no mass — so the thing to defend against isn't cost, it's noise, which is what the ratchet is for.
In three sentences
- Context — keep orientation permanent and knowledge on demand, and put a one-way ratchet on whatever is always loaded, because that's the pile nobody ever shrinks.
- Harness — give the model real equipment, then ask of every rule which rung actually stops it.
- The loop — open every round by measuring the last one, let work that overran die instead of drift, and arm anything unattended before it may start.
Deeper posts on the way: the equipment, tool by tool · the nine stations in practice · how an
unattended run is armed, unit by unit · and what happens when a warning nobody reads finally gets
teeth.
Top comments (0)