Part 1 of 2 — The Sovereign Architect
"Engineering is applied philosophy. We solve human realities under irrationality, selfishness, and chaos: not just specs or math elegance."
I wrote that line for an AI agent, not for a reader. It sits inside my AGENTS.md, the instruction file I hand to every coding agent I work with as a single sentence meant to anchor everything else in the document. But the longer I've sat with it, the more I've realized it wasn't written for the AI at all. It was written for me. It's the sentence I return to when a design decision gets hard, when the "correct" answer and the "right" answer start to diverge.
Most engineering culture doesn't teach you to notice that divergence. It teaches you to close tickets, pass tests, and ship something that matches the spec. And for a long time, that's what I thought good engineering was: a technically correct solution to a clearly stated problem. It took building things that actual humans depended on: not test suites, not demo audiences, but people with bad wifi, bad intentions, forgotten passwords, and zero patience to understand that correctness and quality are not the same thing.
The spec is not the target
A spec describes an idealized world. It assumes the user reads the instructions. It assumes the network stays up. It assumes nobody tries to break the thing on purpose, and nobody just quietly abandons it halfway through. None of that is true, ever, for any system that ships to real people.
So the first failure mode I try to design out of my own work is optimizing for the spec instead of the reality the spec is a lossy compression of. A system can pass every test, satisfy every acceptance criterion, and still fail the moment it meets an irrational, distracted, or hostile human because the spec never modeled that human in the first place. The target was never "does this match the document." The target was always "does this survive contact with people." Everything else in this philosophy is downstream of taking that seriously.
First-Principles: question why
The starting discipline is simple to state and hard to practice: before you build anything, ask why it needs to exist at all. Not "how do we implement this" — "why does this need to be true." Most bloat, most unnecessary abstraction, most fragile architecture comes from skipping this question and inheriting someone else's assumptions instead of testing your own.
The test I hold every decision to is blunt: does this survive real human mess? Not the happy path. Not the demo. The actual, unglamorous conditions the thing will live in. If a design only works when everyone behaves well, it isn't a design, it's a hope.
Grounded Intuition: trust it, then test it
First-principles thinking strips away assumptions that arrived from outside: the ones inherited from a framework's defaults, a past team's habits, an industry convention nobody re-examined. But not every assumption arrives from outside. Some of the best calls I make start as a feeling: this data model is going to bite us in six months, this dependency won't survive a pivot, this abstraction is solving a problem we don't actually have yet. None of that shows up as a spec violation. It shows up as unease.
I don't trust that feeling by default, and I don't dismiss it either. I voice it and then I go find out if it's true: a benchmark, a postmortem from a system that made the same bet, a rough calculation that either survives scrutiny or doesn't. Unexamined intuition is just a hunch wearing the costume of a conclusion. Examined intuition is pattern recognition that's earned the right to be acted on. The difference between the two isn't how fast the idea arrives — it's whether you did the work to check it before you built on top of it.
Asymmetry: design for the worst actor, not the average one
This is where "irrationality, selfishness, and chaos" stops being an abstract phrase and becomes a design constraint. Most systems are built around the median user: reasonable, well-intentioned, patient. But the median user isn't who breaks your system. The edge cases do: the malicious actor probing for a hole, the selfish one gaming an incentive, the one who just walks away mid-flow and never comes back.
Small decisions here have outsized consequences. Whether an operation is idempotent decides whether a retry corrupts data or safely no-ops. Whether a failure degrades gracefully decides whether one bad actor takes down the whole system or just their own corner of it. I don't design for the actors I wish existed. I design for the ones who will actually show up and I make sure the ones acting in good faith are protected from the ones who aren't.
Delete: simplicity is a important stance
Delete is the principle I take the most heat for, because it looks like a style preference — "prefers concise code" — when it's actually an ethical one. Every line of code, every feature, every abstraction you keep is a promise. It's something that has to be maintained, secured, reasoned about, and eventually explained to whoever inherits it. Complexity doesn't just sit there neutrally. It compounds, and it compounds against you.
So when I refactor, the question isn't "can I make this cleaner." It's "does this need to exist at all." If two hundred lines can become fifty without losing the core value the system provides, the two hundred lines were never justified, they were just what happened before someone asked the harder question. Consolidation is the antidote to chaos, because every component you remove is one fewer place for human unpredictability to hide.
Complexity Absorption: push it onto yourself, not the user
Delete handles the complexity you can remove outright. But some complexity is irreducible, the problem is genuinely hard, and no amount of deleting makes that go away. The question that's occupied me lately is what happens to that leftover complexity. It doesn't disappear. It has to live somewhere. And I've become convinced that where it lives is a moral choice, not just a technical one.
The default, unexamined answer is: it lives with the user. Confusing settings screens. Configuration the person has to understand before the tool works. Edge cases they're expected to notice and route around themselves. That's complexity that was never eliminated, just quietly handed off to whoever has the least context and the least power to deal with it.
I've come to believe the opposite is the only defensible default: if complexity can't be deleted, the engineer absorbs it. Hard implementation, simple interface, not the reverse. If someone has to think hard for the system to work, it should be me, at build time, with full context and the tools to get it right, not them, at use time, with neither. This isn't just a UX nicety. It's a direct extension of the asymmetry principle: the user is one of the irrational, selfish, chaotic humans the whole philosophy exists to survive. Handing them your unsolved complexity as their problem is designing for the world you wish existed, not the one that does.
Privacy and Sovereignty: own what you depend on
The last piece of the ideology is its political dimension. Local-first design, end-to-end encryption, self-hosting, etc where and when it is feasible, these aren't aesthetic preferences either. They're a recognition that institutions, platforms, and incentive structures are part of the chaos a system has to survive, not neutral infrastructure sitting outside it. A dependency you don't control is a decision someone else gets to make for you later, usually at the worst possible time.
I optimize for lifetime independence over prototype speed, because speed is a short term variable and dependency is a long term liability. Owning your tools and your data isn't paranoia. It's just applying the same asymmetric thinking to your own supply chain that you'd apply to any other adversarial condition.
Cost: the discipline that keeps the rest honest
Every principle above has a cost, and it's tempting to talk about them as if they didn't. Absorbing complexity so the user never has to sounds noble until you remember that absorption is paid for in your own hours, hours that could have gone into the next feature, the next client, the next thing that actually generates revenue. Self-hosting and local-first sound like independence until you're the one paying for the server, the backups, the on-call pager at 2am when the disk fills up. Sovereignty isn't free. It just moves the invoice from a vendor's pricing page to your own calendar and your own infrastructure bill.
None of this is an argument against the philosophy. It's an argument for being honest about what it costs. Development time, hosting spend, infrastructure complexity aren't footnotes to the real decision, they are the real decision, argued in a different way. A design that ignores cost isn't disciplined, it's naive. The question is not whether to pay: it's a question of which cost you're willing to carry, and why that one is worth carrying instead of the alternative you're avoiding.
The maxim, again
Engineering is applied philosophy. We solve human realities under irrationality, selfishness, and chaos: not just specs or math elegance.
I don't read that as a rule anymore. I read it as a lens, the question to ask when a decision gets genuinely hard and the elegant answer and the right answer have quietly split apart. Which choice survives the person who doesn't read the docs? Which instinct is worth trusting, and which needs to be checked before it becomes an architecture? Which choice keeps the hard part on my side of the interface, not theirs? And which cost am I actually choosing to carry, rather than pretending doesn't exist?
A philosophy that doesn't produce enforceable rules is just decoration. Mine has a test suite. It's a document I actually hand to the AI agents I build with, line by line, because a worldview that can't survive being turned into an operating protocol was never really a worldview, maybe just a mood but certainly not a world view. That protocol is contained in Part 2 of the series.