An aggressive first principles approach often leads otherwise well-intentioned technologists into strategic / ideological dead-ends.
Do we do things because it's the "right thing" to do in the moment, or because of the final outcome that will eventually result?
The most ideal answer is somewhere in the middle. I am far more interested in the total area under the curve than a single instant in time.
In lieu of intentional higher order thinking, simply working backward from your customer on a regular basis will generally accomplish the same outcomes.
show comments
flowerlad
From the blog he linked to: "I’m going to try designing something way more ambitious."
This is how you end up with unnecessary complexity [1]. The best engineers don't aim for "designing something ambitious", instead they come up with the simplest possible design. They take something that seems complex and make it simple.
Unfortunately that's not how engineers are evaluated [2].
I'm really struggling to see how to make architectural decisions with an agent. It's great when you're at a total loss for ideas, but when you already have some of the pieces it ultimately wants to drive all of the thinking and takes over. Then it just feels like you're deferring your experienced judgement. I've seen colleagues lose the ability to reason any more without asking the agent to do it for them, because they inherently don't see the point if the agent is going to end up doing the whole piece (and probably auditing/overruling anything they came up with on their own).
show comments
sajithdilshan
> I’ve been lucky to work with and manage a lot of great senior engineers. When I think about what made them great, I keep landing on the same thing: they seemed to know what needed to be done. There’s an intuition there that I’ve always admired.
This is so true. Every senior engineer I've worked with knew what needs to be done regardless how big a particular initiative/project was. Most of the time they even had a hunch or a vague idea on how to do it as well, but they were so good at breaking things into smaller parts and get the important things done first.
Recently with AI I've realized how easy it has become to figure out how to do something as well. I can just play around and explore a solution and ask the LLM to code it in the code base and then I can actually go through the solution on high level and see how it would work/not work without doing brain gymnastics trying to figure it out all in my head because I'm obviously too lazy to write any code just to experiment.
cyclopeanutopia
Lots of words, not a lot of meaning. What is this post about?
show comments
coolfox
I use the whole "first principles" thinking as a litmus test for bad engineers, if you're emphasizing first principles all the time you're probably a bit of a naivie person, to put it as nicely as possible. subtraction is a great skill to apply to a great many things we do and when people say "first principles" this is actually what they mean but sometimes things are complicated and a first order approximation is not enough.
show comments
ebiester
I think I need to write a full blog post on this.
While I think there are better introductions to "first principles thinking" than this post, the idea of "...When I step back and ask what we’re actually trying to do, why it matters, and how the pieces connect, I usually find more ways forward than I expected."
That's an important skill to have.
However, I think sometimes we overvalue thinking from first principles when it isn't warranted. I've seen times in my career where first principles thinking led to a solution that ignored key non-technical constraints. (For example, it would require a full re-architecture of the system and require deferring all feature work for a year. Another example: the proposed solution breaks Conways law in a way that would require a reorg that would break other organizational constraints.)
Sometimes, we need to recognize our constraints. Spend the time to question them when appropriate, but realize that there are other tools that are more appropriate in some cases -- such as anthropological thinking.
show comments
Animats
Real "first principles", going back to the underlying physics, is rare. Feynman was noted for that. Jeri Ellsworth thinks like that. Maybe John Carmack and Dean Kamen, although I haven't met either.
ripvanwinkle
I've been using codex to design and build a product that is a fairly conventional looking app - think of a gmail like experience - with some delicate synchronization across devices.
I find that I need to invest a whole lot in high level design myself to get Codex to create a suitable architecture and make the right tradeoffs. It's more like I am designing and Codex is reviewing and occasionally we brainstorm. When I tried having it design based on requirements, it went wild with an unsustainable design / architecture.
And I use things like plan mode etc. My experience is unlike what I read in most vibe coding exploits.
I wonder if I am doing something wrong. Is there a good canonical example of a project built with Codex or even Claude Code that shows how the human and AI interact that I could use as a reference
show comments
Hasz
more time in plan mode, less time in build mode. This is true regardless of whether an agent does it or you do it.
h02
Common sense is not so common
jdw64
Sometimes I don't understand what "first-principles thinking" is, or what exactly you have to tolerate in code for it to count as first-principles.
biophysboy
“First principles thinking” is a Silicon Valley cliche. It is a tell for me
mlmonkey
<wrong thread>
show comments
elendilm
This is one of those things where one can throw around the term "first principles thinking" with relative ease.
To actually do it is different and usually comes from having to wrestle with a problem.
Sadly people from the academia and the public at large has a hard time understanding what this even means.
They equate it with exam based memorization or delegation to authority. Funnily they even think first principles reasoning is an improved version of doing the same.
But this is a blessing in disguise as it gives those who wrestle with real problems a unique skillset that can be advantageous.
Higher order thinking is more important and rare.
An aggressive first principles approach often leads otherwise well-intentioned technologists into strategic / ideological dead-ends.
Do we do things because it's the "right thing" to do in the moment, or because of the final outcome that will eventually result?
The most ideal answer is somewhere in the middle. I am far more interested in the total area under the curve than a single instant in time.
In lieu of intentional higher order thinking, simply working backward from your customer on a regular basis will generally accomplish the same outcomes.
From the blog he linked to: "I’m going to try designing something way more ambitious."
This is how you end up with unnecessary complexity [1]. The best engineers don't aim for "designing something ambitious", instead they come up with the simplest possible design. They take something that seems complex and make it simple.
Unfortunately that's not how engineers are evaluated [2].
[1] https://goomics.net/316
[2] https://terriblesoftware.org/2026/03/03/nobody-gets-promoted...
I'm really struggling to see how to make architectural decisions with an agent. It's great when you're at a total loss for ideas, but when you already have some of the pieces it ultimately wants to drive all of the thinking and takes over. Then it just feels like you're deferring your experienced judgement. I've seen colleagues lose the ability to reason any more without asking the agent to do it for them, because they inherently don't see the point if the agent is going to end up doing the whole piece (and probably auditing/overruling anything they came up with on their own).
> I’ve been lucky to work with and manage a lot of great senior engineers. When I think about what made them great, I keep landing on the same thing: they seemed to know what needed to be done. There’s an intuition there that I’ve always admired.
This is so true. Every senior engineer I've worked with knew what needs to be done regardless how big a particular initiative/project was. Most of the time they even had a hunch or a vague idea on how to do it as well, but they were so good at breaking things into smaller parts and get the important things done first.
Recently with AI I've realized how easy it has become to figure out how to do something as well. I can just play around and explore a solution and ask the LLM to code it in the code base and then I can actually go through the solution on high level and see how it would work/not work without doing brain gymnastics trying to figure it out all in my head because I'm obviously too lazy to write any code just to experiment.
Lots of words, not a lot of meaning. What is this post about?
I use the whole "first principles" thinking as a litmus test for bad engineers, if you're emphasizing first principles all the time you're probably a bit of a naivie person, to put it as nicely as possible. subtraction is a great skill to apply to a great many things we do and when people say "first principles" this is actually what they mean but sometimes things are complicated and a first order approximation is not enough.
I think I need to write a full blog post on this.
While I think there are better introductions to "first principles thinking" than this post, the idea of "...When I step back and ask what we’re actually trying to do, why it matters, and how the pieces connect, I usually find more ways forward than I expected."
That's an important skill to have.
However, I think sometimes we overvalue thinking from first principles when it isn't warranted. I've seen times in my career where first principles thinking led to a solution that ignored key non-technical constraints. (For example, it would require a full re-architecture of the system and require deferring all feature work for a year. Another example: the proposed solution breaks Conways law in a way that would require a reorg that would break other organizational constraints.)
Sometimes, we need to recognize our constraints. Spend the time to question them when appropriate, but realize that there are other tools that are more appropriate in some cases -- such as anthropological thinking.
Real "first principles", going back to the underlying physics, is rare. Feynman was noted for that. Jeri Ellsworth thinks like that. Maybe John Carmack and Dean Kamen, although I haven't met either.
I've been using codex to design and build a product that is a fairly conventional looking app - think of a gmail like experience - with some delicate synchronization across devices.
I find that I need to invest a whole lot in high level design myself to get Codex to create a suitable architecture and make the right tradeoffs. It's more like I am designing and Codex is reviewing and occasionally we brainstorm. When I tried having it design based on requirements, it went wild with an unsustainable design / architecture.
And I use things like plan mode etc. My experience is unlike what I read in most vibe coding exploits.
I wonder if I am doing something wrong. Is there a good canonical example of a project built with Codex or even Claude Code that shows how the human and AI interact that I could use as a reference
more time in plan mode, less time in build mode. This is true regardless of whether an agent does it or you do it.
Common sense is not so common
Sometimes I don't understand what "first-principles thinking" is, or what exactly you have to tolerate in code for it to count as first-principles.
“First principles thinking” is a Silicon Valley cliche. It is a tell for me
<wrong thread>
This is one of those things where one can throw around the term "first principles thinking" with relative ease.
To actually do it is different and usually comes from having to wrestle with a problem.
Sadly people from the academia and the public at large has a hard time understanding what this even means.
They equate it with exam based memorization or delegation to authority. Funnily they even think first principles reasoning is an improved version of doing the same.
But this is a blessing in disguise as it gives those who wrestle with real problems a unique skillset that can be advantageous.