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.

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).

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 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.

Lots of words, not a lot of meaning. What is this post about?

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.

<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.

[dead]

[flagged]

[flagged]