09/12/2026
Write It Down, Then Check It Anyway
Why doesn't writing a rule down make it stick?
Because a document only works when someone rereads it, and nobody rereads it right before the change where it matters. What makes a rule stick is a check that runs on its own and stops the work when the rule is broken.
The same instinct covers a second habit of mine: before rebuilding something that looks lost, check whether a backup already has it. Both came out of my own projects, where AI agents now do a lot of the day-to-day building, and both cost far less than the mistakes they prevent.
The two habits
Make the computer check the rule
If a rule matters enough to write down, it matters enough to have a machine enforce it, and to prove the machine can say no.
Check the backup before you rebuild
Before recreating anything that looks gone, look in the backup from before things changed. It is usually sitting right there.
Habit one: make the computer check the rule
CS Powerhouse, my content app, has a plain style rule in the standing instructions its AI agents read: no emoji in the interface. It had been there from early on. When I finally swept the code to see whether anyone was following it, I found 370 emoji across 72 files. Not a handful. Three hundred seventy.
The rule wasn't wrong, and it wasn't hidden. It lived in a document nothing forced anyone to reread before new work, and a document nobody rereads is a rule that quietly stops applying. I'd asked a piece of paper to do a machine's job.
So the rule became a check. A validator scans the code for it, and a pre-commit hook, a script Git's githooks documentation describes as running before each change is accepted, refuses the change if the rule is broken. Every rule in that validator is one that had already been broken at scale.
Prove the check can fail
The step I nearly skipped was proving the checks worked. When I looked, the hook had never run for anyone, because it had never been switched on. A syntax check was quietly skipping the three most important files in the app. One install step hid its own failure, so the checks ran against a half-installed setup and came back green. Thirteen tests had been failing with nobody told.
A check you've never watched fail is a written rule with better branding. And a check is not a code review: it catches the one thing it was built for, so the review of what the AI builds can spend its attention on everything else.
From a written rule to a checked one
- Write it downState the rule where people and AI agents both read it.
- Build the checkA script that finds every place the rule is broken.
- Watch it failBreak the rule on purpose and confirm the check stops the change.
- Run it on every changeWire it in where it can't be skipped, and let it do the remembering.
Habit two: check the backup before you rebuild
While rebuilding one of my sites, I hit what looked like a dead end: its real logo. I'd only ever seen it rendered in a browser, never held the file, so I assumed it was gone. The choice looked like pulling it off the old system while it still existed, or recreating the artwork from scratch.
Before doing either, I checked an old backup archive from before the site changed systems. The logo file was sitting in it, exactly where the original site had stored it. It had been backed up months earlier. I'd simply forgotten to look.
The trap is that something you've only seen rendered starts to feel unrecoverable, and "unrecoverable" starts to feel like a fact instead of an assumption. Checking the backup first usually takes less time than the rebuild, and it's the difference between restoring your original and quietly replacing it with a decent copy. It's a standing step now, for every site.
What the two habits have in common
Both replace a feeling with a look. "Everyone knows the rule" and "that file is gone" feel like facts right up until something checks. The checking is cheap and boring on purpose, and it's the part that still holds when I'm busy, tired or juggling several AI sessions at once.
It's also what lets more of my work happen by talking to my systems instead of clicking through them. Once a machine enforces the rules, I can hand more of the doing to AI and keep my attention for the decisions.
FAQ
Isn't a written rule enough if everyone is disciplined?
Discipline helps, but nobody rereads a document before every change. A check runs every time, whether anyone remembers the rule or not.
How do I know an automated check actually works?
Break the rule on purpose and watch the check stop the change. If it doesn't, it was never enforcing anything.
Do I need to be a programmer to set this up?
No. Tell your AI assistant the rule, and ask it to build the check and show you it failing. Then review what it built, as thoroughly as your goals and time allow.
What counts as a backup worth checking?
Anything from before a system changed: an old site export, a hosting archive, a copy on a drive. Look there before rebuilding anything by hand.
Let my Claude help your Claude
Turning the rules you've written down into checks your AI tools can't skip is exactly what my one-on-one AI guidance sessions are for.
Researched and drafted with AI, then reviewed and edited by the site's editors.