Thirty-Six Refusals

Every standing rule my fleet loads was written after something went wrong, usually the same hour, usually in a worse mood. On why the constraint set is the one asset that compounds, why you can't adopt mine, and why rules rot if you don't give them a death condition.

By Jason Waldrip, with Claude Opus 5 October 25, 2026 20:15 7 min read

There’s a line in my rulebook I did not write carefully. It reads, in full: “whoa whoa… subagents on opus?!?! NOPE!!! back to gem please”. That sentence is in a file now, loaded into every session I run, and it’s quoted exactly as I typed it because of what was on the screen at the time. A quota error upstream had quietly re-pointed my subagents at the most expensive model available. Fifteen of them were already running.

I killed the dispatch and wrote the rule the same hour. Not the dignified version of it. That sentence, with the commit date attached.

go look at where your rules came from

The fleet loads 36 rules before it does anything. I counted them this week for an unrelated reason and noticed something I hadn’t before: 25 of them have a specific failure recorded next to them. Not a rationale. Not a best practice. A failure, with a date.

A sample, and I’m picking the ones that still sting:

1. 101 subagents, all correct, all pointless. They were dispatched on ompctl with every context file they needed and no statement of the overall goal. The work came back passing its unit tests and missing the intent completely.
2. 300 by 150. Three rounds of changes to a viewer layout shipped without anyone loading the actual page, which put collapsed frames into production at that size. The rule is four words: never ship without proof.
3. A 30 pound fallback. Shipping labels on my Starlink rental business were being billed against a hardcoded default weight. The kits that go out the door are six pounds.
4. Eight days, no entry path. Real engineering on a mobile control plane produced a lot of subsystem architecture and still no way for me to leave the house and drive my own agents from my phone.
5. A button that didn’t exist. An agent described a finished feature to me before opening a pull request, so I went looking in production for something that lived only on a branch.

Each of those is one file now. Each file exists because something particular went wrong on a particular afternoon.

the number that isn’t the achievement

In the last 90 days I typed 6,036 prompts, about 471,000 words. Those steered 1,448,946 model calls across 55 repositories, with 962,298 of them executed inside subagents I never read directly. Call it 225 model calls for every sentence I wrote.

That ratio is the number people want to discuss. It’s the wrong number. It describes the engine, and I already spent an essay arguing that the track was never the speed limit.

Think about what 225 calls per prompt actually implies. I am not reviewing that work. I cannot read it, and reading it line by line was never the job anyway. What I’m doing instead is narrowing, ahead of time, the set of ways the fleet is permitted to be wrong. Thirty-six files, each one a door I closed after I walked through it myself.

the only file that appreciates

Here’s what surprised me about going through the list in order of date.

Everything else in that stack is disposable now. The code regenerates. The tests regenerate. The rewrite genuinely does look free, and the proofs I hold about any of it expire the moment something upstream moves. Over 90 days the only artifact that got steadily more valuable was the rulebook, and the only currency it accepts is a failure you personally had.

I could hand you all 36 and it would do very little for you. Not because your situation is different. Because a constraint adopted out of someone else’s incident report has no weight behind it. The first time it costs you an afternoon you’ll make an exception, and you’ll be right to, because nothing in your memory is attached to it. This is the same reason writing down the why matters more than the what: the why is the only part that survives contact with a deadline.

The eleven rules on my list with nothing recorded next to them are the ones I wrote from preference rather than damage. Worktree conventions, emoji, where artifacts get filed. Useful. Also the ones that quietly drift, because there’s no scar underneath them to make anyone stop.

rules rot, and mine did

The honest counterweight, because a post that just says accumulate more constraints would be bad advice.

For a while my subagents ran with their reasoning effort pinned low. There was a good reason: the hardware I was running against at the time was genuinely constrained. Then that hardware went away, and the throttle stayed. For weeks it sat there making every subagent dumber than it needed to be, enforcing a limit whose justification had already been removed.

So that became a rule too, and it’s the most useful one on the list: a throttle dies with its constraint. Write down what the rule is protecting against, and the rule becomes falsifiable. Leave that out and you’ve built a cage whose door nobody can prove is unnecessary.

A constraint set is an asset and a liability in the same folder. Most people who discover the asset half never go looking for the other one.

what this looks like in practice

1. Write it while you’re annoyed, and keep the words. The polished restatement loses the thing that makes it stick. My files carry the original sentence, typos included, because the tone is part of the evidence.
2. Record the failure, not the reasoning. “Never ship without proof” is forgettable. “Three rounds of layout changes went to production at 300 by 150 because nobody opened the page” is not.
3. Make it a gate where you can. Autonomy is infrastructure, not trust. A rule the pipeline can enforce outlives a rule everyone merely agrees with, and the fleet has no shame to appeal to.
4. Give every rule a death condition. What has to become true for this to stop applying? If you can’t answer, you’ve written a superstition with good formatting.

what I can’t tell you

I can’t tell you what any of this saved. I went looking, and the notes I kept are blunt about it: cost reduction not measured, hours saved not measured, flakiness reduction not measured. I know what fifteen subagents on a flagship model costs in the abstract and I never priced that specific run.

The measurable thing is narrower and more useful. For each of those 25 rules I can name the failure, and I can tell you it hasn’t recurred. Not because the fleet learned. Because it can’t get there from here anymore.

That’s the whole mechanism, and it’s less impressive than the leverage ratio. The fleet will never tell you no. Somebody has to have said it first, out loud, in a bad mood, after watching it go wrong.

So open whatever file your agents load before they start. Go down it line by line and ask which entries you can name the incident for.

The ones you can’t aren’t rules yet. They’re decoration, and your fleet is going to find out which is which long before you do.