> An aggressive first principles approach often leads otherwise well-intentioned technologists into strategic / ideological dead-ends

First principles are an illusion. Good engineers make strategic choices of the supposed "first principles" they apply, and on a particularly difficult problem, they may iterate through multiple options before discovering the "first principles" that yield a good solution.

Engineers that take first principles seriously and try to use them to guide their decisions discover that correct-sounding first principles tend to work in some contexts and fail in others. Then they go one of two ways responding to these failures.

One way is to blame the context. My favorite example of this is a project where a consultant writing a Java web service struggled for months to get Hibernate to emit queries than ran efficiently on the company's Oracle database. Pressed by management to write the queries by hand, the consultant insisted that using Hibernate was a non-negotiable "best practice." Eventually the manager grepped the logs, identified twelve distinct queries that the service needed, and tasked the Oracle admin with optimizing them, which took less than an afternoon. The consultant still pushed back against using the hand-tweaked queries, saying that if the answer emitted by Hibernate didn't run efficiently, then the database schema was wrong and needed to be fixed. This was not the right response when the database in question was the beating heart of a hundred million dollar tech company and was optimized to handle massive transactional workloads, and the consultant was struggling to write a simple web service for internal users.

The second way is to push your first principles to higher and higher levels of abstraction to make them less context-dependent. They update "Use Hibernate for database access" to "Use whatever database library or framework makes it possible to achieve the best results with the least developer effort" and eventually resort to something like "do whatever achieves the best outcome measured by its impact on what is important to you at the time."

I think a better approach is to collect a toolkit of potentially helpful principles and develop understanding of when each principle tends to be helpful.

First principles thinking often leads to treating human beings as spherical cows.

Working backwards from the customer is first principles thinking.

They don't seem at odds to me, just two ways of looking at a problem.

Your last sentence says it all. Just get good at first principles thinking. Higher order thinking is first principles thinking when applied to first principles thinking.

And who should first principles focused on? Your customer, your manager, your company, yourself? All of these are valid and often give competing answers!

> Higher order thinking is more important and rare.

Is it?

> In lieu of intentional higher order thinking, simply working backward from your customer on a regular basis will generally accomplish the same outcomes.

And here I thought we were discussing something important!

What is the difference between first principles and higher order thinking?

I would stick to parallelizing first principles. The issue you're describing is when individuals cannot offload responsibilities to agents and other humans because of humanistic ideals. First principles are by definition axioms, and this is the only way to build. It's amazing how quickly heuristics are conflated with first principles when efforts are spread thin.

I completely disagree. Are you going to operate from principles or from conventions?

Higher order thinking is actually substantially more common, like overwhelming so. Higher order thinking is the application of known patterns, such as frameworks and common tools. Many people often dismiss doing the right thing for matters of convenience, which is the basis of tech debt.

First principles are not elusive. State your goals and limitations first. Then proceed accordingly.

I tend to find this part of the work enjoyable. It is just a faster and more productive version of what I would do with any engineer working for me who owns a large feature. I barely have to hint at my concern or drop the right keyword and the agent (Fable/Astra) will immediately understand.

"Couldn't this be stateless?" "Do you have a plan to be able to shard this?" - We will almost always pivot from the agents initial design but the agent is able to easily understand the reasons and benefits and align quickly.

If I was writing the code myself, I'd often have to make compromises between the ideal architecture and the level of effort required to implement it - now I can just always have the ideal architecture.

> 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

I feel the opposite, like if I go to an agent without first knowing what I want to build, I'll never figure out what I'm doing or why and it'll run away from me.

I pretty much always go back and forth and have the agent write out a plan to a file and review it myself in my text editor. I still sometimes end up with surprises I disagree with, but I don't really find it to be true that the LLM ends up trying to "drive all of the thinking".

When I'm thinking through an architecture, I not only instruct it to refrain from writing any code, I don't even necessarily tell the agent what I'm trying to build.

This is one thing I actually do with a chatbot, instead of an agent. Voice mode even.

I start talking to it while doing menial tasks like cleaning or doing the laundry, and I discuss the architectual decisions and options until I come to some resemblance of a plan.

Good side of this approach is that I can't just "skim over" or "copy paste" things - either I understood them and can repeat them myself, or I can't. It takes more time than /grill-me and similar approaches, but it's the only approach that doesn't make me want to claw my brain out.

> I'm really struggling to see how to make architectural decisions with an agent.

I walk to work and home with ChatGPT Voice and AirPods. I ask it to be Socratic and I just start rambling the top of thing on my mind. After 20 mins of back-and-forth it's usually teased an answer out of me or I've teased an answer out of it.

Sometimes it's easier for me to scaffold the architecture (in real, working code) and then let the agent fill in the implementation. And I make the agent document the architecture and have it refer to the documentation when coding. When I review agent code, I focus only on architecture (is it following existing architecture? is it introducing new structures, dependencies, etc.?)

Other times, I let the agent create a black box with a well-defined interface contract. I don't care about the architecture inside the black box.

Agents are the greatest rubber ducks ever created.

Another perspective is that this isn’t a new problem. Every dev manager or team lead with very strong direct reports has this problem. They don’t lose the ability to reason, they strengthen their ability to reason more quickly, and know when to trust the expert and when to poke holes.

How much scope do you give it? I find it's easier to stay in control when you give it scope down the chunks of work you give it.

I have had really good experiences with designing architecture with agents. It is much much better than humans and frankly, if my colleagues had used agents to design their new services, we'd have been in much better place.

I have found autonomous agents to be pathetic at architectural decisions.

Architecture has remained so far to be one of those domains where skillset dwarfs everything by comparison.

Treat the final "here's what you should do" summary as just another intrusive thought.

Why would you care about architecture? It was an issue when humans were writing code so architecture mattered in the sense that you needed a sweet spot between current requirements and future extensions.

The agent can rewrite half your codebase in one day, so architecture stops mattering for the most part.

The best engineers don't aim for "designing something ambitious", instead they come up with the simplest possible design

These are orthogonal.

A lot of the dissonance on HN appears to come from two groups of people talking past each other:

a) developers working at some corporation they hate vs.

b) developers working for themselves or somewhere they don't hate

You apply first principles thinking, but also be mindful of your role in the team.

When you say something isn't warranted because it takes too much time, it isn't valuable: you're still thinking about what it is you're doing (working), what tools you have (your team, people), to create value (your product or service).

It's the measurement of value part that's tricky. Who determines value? Sometimes it's the customer, sometimes it's just you.

It's about perspective, and seeing where you fit in the picture. Apply the principles from there. Nobody says you have to be a jerk about it, that's up to you and how you wish to apply the output of the first principled thinking.

> However, I think sometimes we overvalue thinking from first principles

The problem isn't the thinking though, but the lack of grounding.

You don't have a problem with people coming up with a technically better solution. Your problem is with the people not realizing that they exist in reality and not in a vacuum.

Please don't question the act of thinking itself. It is the wrong target.

I mean that's always been the paradox that good devs need to live in, and I often go backwards and forwards on the scale between technically pure, and straight up problem solving.

Fundamentally software we create exists to solve problems, if bad code solves the problem is it bad code? Counter to that is we are engineers and it's our job to design systems that mean problems can be solved safely and effectively.

Like most things in life the truth lies in the middle

> When you truly understand what you’re trying to accomplish, it’s easier to take a small step...

I think they're describing an approach to decision-making in the context of agents.

Engineers encountering LLMs for the first time think the problems they encounter are entirely novel, but really we are rehashing old lessons which Fred Brooks wrote about half a century ago, but in new jargon.

The essential difficulty of specifying what you actually want remains the same and nothing I've seen from LLMs will change that.

I think it's saying you need to go back and think harder about the problem instead of putting all your effort points into a solution.

"First principles" is just the latest expression ruined by SFBA posers like "orthogonal" and "non-trivial" before it.

Very confusing indeed. Is the core idea to read the picture as a flow from left to right? Or some people go down and left, but you need to first go right and iterate. Then go left and put it in a box. and then... dunno, lost track of thought, did AI or someone who is very new to Consulting write this?

> occasionally we brainstorm.

Seriously, how do you brainstorm with an entity that would 180 if pushed a bit..How can you take anything it say at face value?

I've been on a similar path, and I used to put time in high level design, as it was basically required in some cases. But not a lot of time, because smaller agents research, perform small tests, whatever to inform the high level design. Working incrementally seems to help, maybe prompting a bit more often, but the same can be accomplished with well defined checkpoints.

Then generalize + standardize that process, get an agent to replace you as high level designer so you can manage a team of high level designers, etc etc

“first-order approximation” is pretty different from first-principles thinking in my opinion.

Yea I agree. Thinking from first principles is a valuable skill in general.... but certain areas have received so much attention/work and are highly developed. It's not impossible to develop something new by thinking from first principles, but when I see it I often interpret that as either 1) lacking awareness towards the sophistication of the domain, or 2) arrogance.

Thinking of your customers is first principles thinking.

given how the term is used lately, your questioning just means you're not insane yet, so I wouldn't worry too much.

> Sadly people from the academia [...] equate [first principles thinking] with exam based memorization or delegation to authority.

In what departments and at what universities? The term "first principles" comes from academia. I think you'd be hard pressed to find a faculty member in any philosophy department doesn't understand what reasoning from first principles is. I'd be surprised if any working mathematician thinks of "memorization" or delegating to authority rather than axiomatization. What experiences led you to say this?

And it's a skill that you'll use in other contexts. Over too learn and practice it in IT/physics, and you find out that you can use it to psychology, humans around you are dealt with another depth and different outcomes become possible

Sorry, I think I'm being dumb, but where is the "first principals thinking" in your example?