There's something interesting about named principles. Someone watches a pattern repeat for years and distills it into a sentence. Then someone else attaches a name. Conway didn't call it "Conway's Law" — others did. Chesterton was just writing an argument in a book; later readers extracted the fence and named it. The observation is individual. The naming is collective — an act of community compression. After that, the name is the concept. "Chesterton's Fence" carries an entire philosophy of caution in two words. "Goodhart's Law" compresses a thesis about measurement corruption into four.
I think of these as human-language embeddings. A name gives a complicated observation a small, portable handle; someone else can use it without retelling the whole story. The comparison to a model's embeddings is a metaphor, but the lossiness is real. We remember the sentence and forget the conditions that made it useful. There's a kind of Begrifflichkeit to it — forming concepts that give thought something to hold onto. Or an echo of kotodama, the Japanese idea that words carry spiritual power. Naming changes what we can call into a conversation.
Some of these I keep coming back to. Some I just find interesting. This is a living reference — mostly for me, partly to see what patterns connect. The engineering and agent examples are my applications of the principles, with all the room for error that implies.
#The Laws
#Chesterton's Fence
Don't remove something until you understand why it was put there. The fuller version is worth hearing:
"There exists a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don't see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'"
This might be the single most important principle for the agent era. Claude Code will happily "clean up" a function that looks redundant but exists because of a bug discovered at 3am two years ago. The agent optimizes for local cleanliness without historical context — it can't see the scar tissue. And in a world of increasingly AI-generated codebases, the fence signal gets noisier — there's less "someone stayed up till 3am" human scar tissue and more pattern-matched output. Chesterton's Fence becomes a guardrail we have to deliberately apply when reviewing AI changes, not just human ones.
I've hit this three times recently, and the shape was different each time. Once I blew past it — we were migrating from Jenkins to ArgoCD, and I labeled a Jenkinsfile as a straggler, confirmed the GitOps manifests existed, and deleted it. Thirty minutes later: the service was still serving live traffic in production, but nothing in the new system was actually managing it.
The Jenkinsfile hadn't deployed in over a year — but it was the only record of how that service got into production, and nothing else had picked up the slack.
Once I caught myself just in time. I had repos queued for retirement because they hadn't been pushed recently, and mid-planning I stopped and thought: wait, those could still be in active production use. Last-commit-age isn't the signal that determines whether the fence matters. Live deployments, healthy services, DNS still pointing at it: those are reasons to investigate.
And once I removed correctly — traced the actual dependency, proved nothing was attached, then removed. Same discipline, different outcome.
The pattern I'm taking forward: the fence isn't the code or the label or the file. The fence is whatever invariant the past version of the team relied on that you can't see from the current state. The job is to surface the invariant, verify it, then decide whether to remove it.
Naming it "Chesterton's Fence" turns vague caution into a portable, high-fidelity reminder — exactly the kind of human embedding that agents still struggle to internalize without explicit scaffolding.
I went deep on that one because I lived it recently. The rest are shorter, mostly things I've internalized into abstractions. The vivid memory faded; the instinct stayed. That's kind of the whole point of named things.
#Conway's Law
Systems tend to reproduce the communication structures of the organizations that design them. Melvin Conway submitted the argument in 1967; it was published in 1968. Your microservices architecture starts to look suspiciously like your team structure.
Multi-agent systems can recreate this quickly. Define a "frontend agent" and a "backend agent" and you've already made an architectural suggestion, whether or not that boundary fits the problem. Splitting by role can help: a planner and a worker can share the same domain. But they still have a communication structure, and their handoff can become a constraint of its own. Renaming the agents doesn't get us out of Conway.
#Goodhart's Law
Once a measure becomes a target, optimizing it can break its relationship to what you cared about. The familiar wording compresses an observation Charles Goodhart made about monetary policy in 1975.
Benchmark gaming. School ratings. Code coverage as a quality proxy. Any time someone says "we improved X by 15%" — ask what X stopped measuring when they started optimizing for it.
#Hyrum's Law
Given enough users, someone will depend on every observable behavior of your system, including the ones you never promised. Hyrum Wright's observation grew out of infrastructure migrations at Google. If your endpoint happens to return results sorted alphabetically, someone will eventually depend on that.
This is why "just refactor it" is never just. Agents need to understand implicit contracts as well as explicit interfaces. The invisible dependencies are the ones that bite.
#Gall's Law
"A complex system that works is invariably found to have evolved from a simple system that worked." John Gall, 1975. I read this as a demand for a working starting point. A grand design doesn't get to skip contact with use.
The context engineering stack formed bottom-up from pragmatic layering. That's the useful instruction I take from Gall: keep something working while you discover what else it needs.
#Brooks's Law
"Adding manpower to a late software project makes it later." Fred Brooks, 1975. Communication overhead grows faster than productivity gains.
The agent version: adding agents to a bad architecture makes it worse faster. More agents ≠ more progress.
#Jevons Paradox
Making a resource more efficient to use can increase total consumption if the resulting demand grows enough to outweigh the savings. William Stanley Jevons, 1865: more efficient coal engines made new uses economical. Efficiency per use and consumption overall can move in opposite directions.
My bet is that cheaper software production gives us more software to tend. The cost of producing a feature falls; the surface area we're responsible for grows. Whether that creates more demand for engineers depends on what happens to the cost of tending it, too.
#Lindy Effect
For some things that don't wear out like a physical object does, a long past can be evidence of a long remaining future. SQL. Unix. Git. HTTP. grep. When someone says "X will replace Y," check how long Y has existed, and what keeps renewing the reasons to use it. Age alone won't save a tool whose environment has disappeared.
#Postel's Law (Robustness Principle)
"Be conservative in what you send, be liberal in what you accept." Jon Postel, 1980. Strict output schemas. Tolerant input parsing. The constraint layer is conservative in what it sends. The prompt layer is liberal in what it accepts.
This one fights with Hyrum. Quietly accepting a malformed input can teach someone that it's valid, and now the workaround is part of the interface. RFC 9413 describes that failure mode. I want tolerance for how someone expresses an intent, with explicit validation before that intent turns into an action. Silently guessing at a broken contract is a different bargain.
#The Razors
#Occam's Razor
Prefer the explanation that accounts for the evidence with fewer unnecessary assumptions. "Fits the evidence" does most of the work. Deleting the inconvenient evidence doesn't make an explanation simpler.
#Hanlon's Razor
Never attribute to malice what's explained by a stale cache, a race condition, or a misconfigured env var.
My engineering translation. Check the ordinary failure before building a theory about someone's intentions. It tells me where to start investigating; it doesn't require me to ignore what the investigation finds.
#Hitchens's Razor
"What can be asserted without evidence can be dismissed without evidence." Useful for evaluating AI hype.
#The Numbers
#Dunbar's Number (~150)
A proposed rough scale for stable social relationships, often repeated as a hard human limit. The precision is contested. I keep the coordination question and hold the number loosely: when does a group get large enough that remembering who knows what stops being a workable system?
#Miller's Law (7 ± 2)
The memorable number from George Miller's work on memory and information processing. It isn't a universal allowance of seven things: chunking and the task matter, and Nelson Cowan's later review argues for about four chunks under more controlled conditions.
The question I care about is how many parallel agent tasks I can track before I lose the thread. A context window doesn't tell me that. Nor does a tidy number from a different task.
#The Deeper Ones
#Ashby's Law of Requisite Variety
A regulator needs enough possible responses to counter the disturbances that matter to the outcome it's trying to preserve. The engineering translation: the constraint layer needs enough expressiveness to handle the variation we care about. If my design tokens cover color and spacing but leave typography open, valid colors can still arrive with garbage type. I left that freedom in the system.
#The Anna Karenina Principle
When success requires several conditions to hold together, failure can come from any one of them. Borrowed from Tolstoy's opening about happy and unhappy families. A deployment might need correct code, valid credentials, reachable dependencies, and enough capacity. Passing three checks doesn't compensate for failing the fourth. The useful part is the conjunction; there are still plenty of different ways to build a working system.
#Wittgenstein's Ladder
Near the end of the Tractatus, proposition 6.54, Wittgenstein asks the reader to get beyond his propositions, like throwing away a ladder after climbing it. I'm borrowing the image more loosely here. Maybe these named principles are the ladder — you learn "Chesterton's Fence" as a rule, internalize it as intuition, and eventually stop naming it. The compression becomes invisible. That's one kind of expertise: named principles that have dissolved into judgment.
The thing that strikes me about this list: every one of these is someone compressing years of observation into a sentence. Axioms, a CLAUDE.md, the constraint layer — each tries to make some of that judgment portable enough for a machine to carry.
The name makes the judgment portable. It can also make it feel settled. That Jenkinsfile already looked redundant. A name can remind me to look again; it can't tell me what's still depending on the thing I'm about to delete.
Living document. Adding as I encounter them.
