Day 1 of 14 — Structure Over Vigilance. Pete Gypps, COR Intelligence.
Andrej Karpathy's got a line about why a language model writes better documentation than a person does: LLMs don't get bored, don't forget to update a cross-reference. He said it in passing. I've chewed on it for months, because it named a problem I'd been staring at from completely the wrong angle.
Here's the problem. If the machine doesn't get bored, doesn't forget the boring step, doesn't skip the tedious update — why do the systems we build with these machines still rot?
Because they do. You know they do. The config drifts out of sync with reality. The document you swore blind was the single source of truth quietly stops being true, and no alarm goes off, because a thing going stale isn't an event — it's the absence of one. The setup that was right on Tuesday is subtly, invisibly wrong by Thursday, and when you trace it back, nobody did anything obviously wrong. Everyone did their job. The system rotted anyway.
The reason is simple enough that it took me a while to trust it.
We keep putting the guarantee in the wrong place
Every reliable behaviour in a system is a guarantee — "the legal name is right everywhere", "secrets never reach the repo", "this document matches reality". And every guarantee has to live somewhere. The question nobody asks is: where?
Mostly we put guarantees in vigilance. In remembering. In checking. In "always make sure you…", in the discipline of the person doing the work or the process wrapped round it. The guarantee holds as long as someone keeps watching.
And vigilance always, eventually, fails. Not because people are careless — because vigilance is expensive, boring, and never finished. It costs attention every single time, forever, and it never gets to be done. Anything with those three properties gets skipped the moment there's deadline pressure, or a distraction, or a new hire who never heard the unwritten rule.
The alternative is to put the guarantee in structure — in the shape of the thing itself, so the right move is automatic and the wrong move is hard or impossible. Not because anyone remembered. Because of how it's built.
The secrets example, because it's the clearest
Almost every team has a rule: never commit secrets — API keys, passwords, tokens — to your code repo. Good rule. Also a rule living entirely in vigilance. Someone has to remember it, and enforce it, every single time anyone commits anything. Miss once and the secret's in the git history forever, which on a public repo means it's burned the moment it lands.
Now the structural version. Put your secrets in a folder that sits above the repo — outside its boundary entirely. The app reads them from there. But git can't see them, because they're not inside the thing git tracks. They physically can't be committed. Not "we've got a policy". They're on the other side of a wall the tool itself enforces.
Same guarantee — "secrets don't reach the repo" — done two ways. The first leans on every person, forever, remembering and not slipping. The second can't fail, because there's nothing to remember; the shape makes it true. That's the whole difference between vigilance and structure, in one example. And once you've seen it, you start clocking the vigilance-based version of everything, everywhere you look.
Why this matters more now, not less
You could fairly say none of this is new. Good engineers have practised versions of it forever — single source of truth, idempotency, information hiding, the Unix thing of small tools that each do one job. All true. So why bang on about it now?
Because AI changes the stakes in a specific way. Hand work to a human and they carry some of your intent for you. They notice the copied value looks off. They hesitate. They ask. That hesitation is a safety net you never designed but always quietly relied on.
Hand the same work to an AI agent and the net's gone. An agent has no memory of your intentions, no institutional knowledge, and an infinite willingness to do exactly what the structure tells it — including the wrong thing, at scale, without pausing, if the structure points that way. It doesn't hesitate. It executes.
Which means the structure is now the only thing carrying your intent. And here's the inversion most people miss: the more capable the AI, the more the structure matters. A smarter agent doesn't save you from a flawed structure — it follows the flaw into the wall faster and more thoroughly. The intelligence was never the risk. Intelligence sitting on top of vigilance-based scaffolding is the risk.
So the instinct people reach for — "we'll just watch the AI carefully" — is dead on arrival. It's vigilance again, and worse, it's vigilance against something that works faster than you can read. You can't supervise a system that outpaces your attention. The only move that scales is to build the structure so the AI can't do the wrong thing, and then stop watching, because there's nothing left to watch.
The frame
I call this structure over vigilance, because naming it makes it usable. Once you've got the phrase, you can point at any guarantee in your system and ask the one question that matters: is this held by structure, or by someone remembering? If it's the second one, it'll fail — you just don't know when yet.
This is the first piece of fourteen. Over the next couple of weeks I'll take it apart properly — the two laws underneath it, why connected and visible data is the terrain that makes it work, the ways I've watched it prove itself (including catching my own mistakes before they cost anything), and why a few people have landed on the same conclusion from completely different directions. There's a longer paper tying it together, linked from these.
But it all starts here, with one shift. Stop asking your people and your machines to remember to be reliable. Build the reliability into the shape, where it can't get bored and can't forget. I'm still sharpening this — expect it to move as the series goes.
Pete Gypps — COR Intelligence. Next: the drift law — why a rule you have to remember is a rule that's already halfway to broken.
