When I trained with Udi Dahan in Advanced Distributed Systems Design in 2013, the thing that shifted most for me was not a set of techniques. It was a question: what is the intrinsic nature of this problem?
Not: what does this domain typically look like in software? Not: what does the framework suggest? What is the actual nature of the problem — independent of how it has been solved before?
That question sounds straightforward. In practice, it is genuinely difficult to answer, because arriving at the right answer requires stripping away a layer of assumptions that are so embedded in how we think about software that they no longer feel like assumptions at all.
The accumulated layer
Consider something as apparently simple as the question of where data should live. In most systems I encounter, data residency has not been deliberately decided — it has been inherited. The ORM suggested a schema, the schema implied ownership, the ownership was never questioned, and now it is load-bearing. Change it and you change everything.
Or concurrency. Most systems treat concurrency as a technical problem — something to be managed with locks, queues, or eventual consistency patterns. But the right answer often depends on what the data actually represents and what business rules govern it. Those are not technical questions. They are domain questions that have technical answers once you understand them clearly.
Getting to those answers requires starting from the problem, not from established patterns. It requires understanding the domain well enough to distinguish between constraints that are intrinsic — genuinely non-negotiable properties of the problem — and constraints that are merely inherited from how similar problems have been solved before.
Why this matters more now
The case for first-principles thinking has always been strong. The case for it now is particularly strong.
AI coding tools do not start from the intrinsic nature of a problem. They start from patterns — the aggregate of how similar problems have been solved historically. When those patterns are good, the results can be good. When they are not, the tool faithfully reproduces the flaws along with everything else.
This is not a reason not to use these tools. It is a reason to be deliberate about what you use them for. First-principles thinking — understanding the problem clearly enough to know what shape the system should take — has to happen upstream of the tools, not inside them.
Once you know what you are building and why it should take a particular shape, the tools become genuinely powerful accelerators. But they cannot substitute for the thinking that determines what to build in the first place.
The discipline it requires
There is a reason first-principles thinking is not universal: it is uncomfortable. It requires sitting with uncertainty long enough to actually understand the problem, resisting the pressure to produce something immediately, and being willing to arrive at conclusions that are inconvenient — that the system needs to be shaped differently from how similar systems are usually shaped, or that the existing structure needs to change before new features can be safely added.
That discomfort is load-bearing. The discipline that produces it is what separates systems that age well from those that do not.
It is the thing I try to bring to every engagement: not a set of preferred patterns or a methodology, but a consistent willingness to start from the problem and follow the reasoning wherever it leads.
Weighing up what to build?