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.
> 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.
From my experience I have not experienced customer feed / customer thinking spiralling towards drugs and gambling tips.
Then also, companies are guided by some mission / values which might prevent you from going into that direction, unless you are working for an online gambling company
They're not so much at odds, but the emphasis is very different and therefore the failure modes are. First principles thinking emphasizes the principles, and so that's why there's an ideological trap; all you need to justify a given direction is some rationale from first principles, and that's often good enough.
The problem is... which first principles? Say your goal is to get to the moon, and the principle you use is to minimize the distance, and you choose to do this in a greedy fashion. This will have you climbing ladders, trees, buildings, and mountains, and you will record that as progress justifying the approach. But you haven't reasoned far back enough to figure out just greedily minimizing your distance to the moon is never going to get you there, no matter what. Choosing the wrong principles can lead to local extremes which can be a lot harder to see in cases less obvious than going to the moon.
Could you please explain what the difference is between first principles and higher order thinking?
Based on the moon example, it seems you define it as a set of principles you can base your decisions on? E.g. to get somewhere, you must minimize your distance. What makes something a first principle?
I'm asking because my understanding is that "reasoning from first principles" is just taking a step back, asking yourself what's really the goal and reasoning backwards. But it seems like you've got two different concepts (first principles and higher order thinking), which makes me think you've got it figured out more than I do.
First principles are not an ideology; they are more like laws of nature. Due to that, they are great both for reformulating a problem, and checking solutions.
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!
First order thinking works really well when dealing with spherical cows and ignoring air resistance. Once nuance and the fractal complexity of the real world come into play factors come into play, empirical phenomenon and experience become much more important. How much weight you gove to first principles depends on how theoretical or practical your domain is, e.g. science vs engineering.
I think I'll stop commenting in this thread as it seems like no two people in this thread are using compatible meanings of "first principles" thinking. Forget about equivalent meanings of it.
"First order" thinking from my knowledge is an entirely different concept.
> 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!
> Higher order thinking is more important and rare.
I was just talking with a friend the other day about how many problems and issues would be solved if people were more conditioned to asking, "...and then what?"
This is a classic for the people who dream of interstellar travel. Okay, you figure out the problems (good luck) and after some 40-400 years land on some dead rock in the Alpha Centauri system. Congratulations! Now what?
And then you start colonizing? You take the supplies out of the generation ship you took to get there and then build housing and then farms. You build up industry and have lives until there's civilization and you can send messages back to Earth to share what life is like on Alpha Centauri. You and your children make art and music about your new planet, same as people did on the old one.
Yet another incompatible definition - here first principles thinking is define as "how do reach a solution?". If that were true, then it wouldn't be any different from "problem solving".
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'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 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.
Now you have what you think is the ideal architecture. Since you didn't implement it, you didn't discover it was not the ideal one mid way into the implementation.
May be it is too complicated, but you wouldn't know, because LLM is doing the implementation. If you did implement it yourself, you might have spotted a critical point that might simplify the whole thing...
There is a difference between LLM-generated code that somebody merged essentially unseen and LLM-generated code which a human then looked at carefully and massaged until they were happy with it.
The first version can hide a lot of crap. All you see is the end-to-end functionality and there can be corner cases or scenarios which you have not tried and in which it is terrible or plain incorrect.
The second version hides just as many issues as human written code.
Unfortunately, the debate that our field has about LLM-generated code mixes both quite freely even though they are quite distinct.
Jodie Foster did make an amazing discovery that way in the movie Contact, that is true. "Why build one when you can have two at twice the price?" would be my engineering takeaway from that movie though.
> 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 do the same, but without AI in the loop. Just me and my thoughts while cleaning or doing laundry or going for a run. The best designs and architectural choices and algorithms I've come up with in my carreer were developed and/or refined that way.
It's very enlightening, though it requires being comfortable with being alone with ones thoughts. It seems to me many people are not and need constant distractions and/or dopamine kicks.
Thinking alone about fundamentally deep problems can be poweful, but most software problems are not that deep, they follow a pattern, and it's only a question of discovering them. Doing that alone is inherently slower and less efficient than discussing it with a colleague.
AI just serves as a substitute - an artificial conversational partner.
I feel like you consider yourself more virtuous for not using AI for discussion. Would you consider people who don't talk to colleagues at all, but do all the work themselves more virtuous in an analogous manner?
> 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.
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.
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.
Why try to make things that are good? Why care about anything? Why not just turn our minds over to the machines, and let them rock us to sleep like babies?
Possibly because the goal is the end product that serves a purpose and has value, not the process.
If you can make your product, make the customer happy, and make your money to enjoy your life and secure your families future… why care who or what or how (as long as it’s ethical obviously).
Every choice has a cost. The question comes as to when you pay it. Your idea of an end products behavior, and the end products behavior when it interacts with reality may differ significantly.
For example is unknowingly writing a security flaw ethical, when you could have used a set of processes to reduce them before release that would have make the entire thing take longer and cost more. Seems like programmers need a lot more ethics classes as ethics are part of any large scale process.
I agree with most of what you are saying, but I believe that this view on people's ethics is a little naive. Remember that we are talking about AI contexts here. Everything it infects has a questionale track record w.r.t. ethics on many levels.
Besides, ethics come from upbringing and social influences, not from attending a mandatory ethics class.
> Possibly because the goal is the end product that serves a purpose and has value, not the process.
This is not true for everybody or for every project. Sometimes it’s about the code and not about what it does. Sometimes it’s about learning. Sometimes it’s about the fun of creating. “Only the end product matters” is a narrow view of the world of software development.
Because even if the rewrite worked, and worked perfectly, you've (a) lost a day, and (b) there's no guarantee that you won't have to do that all over again in a few days' time, because you're still not thinking about the architecture.
But if the codebase is large enough, and if you don't have tests for everything, you'll likely lose stuff along the way. So you'll then spend at least another day tidying up the rewrite, just getting it back to where you were two days ago.
Does that sound like fun? Wouldn't it be easier to just plan it correctly the first time?
I think the argument is that there won't be a reason to read the code. If you want a change, just let the agent change it.
Similar to the output of a compiler. Nobody (with very few exceptions) reviews its machine code output. No reason to do that. If you want to change it, just recompile.
(I don't share this view, but I think a substantial and growing fraction of folks does.)
Yes, I think you're right. It could be I haven't experienced the cutting edge of AI, but it a) doesn't seem there yet, and b) goes off on tangents assuming outcomes of decisions and needing to rewrite things a lot. So I quite like reading the output.
Mhh I've tried one-shotting double buffered IO a few times and it just can't do it. Maybe it's a prompting issue, maybe LLM's have a hard time with thinking about parallel processes.
I'll create a simple "framework" of what I know works. After that's there the LLM is fantastic.
LLMs benefit from abstractions for the same reasons that humans do. More information in the same amount of text. Fewer working parts to juggle so fewer ways to make mistakes.
Why would you care about architecture? Ability to implement the current feature, ability to implement future features, maintainability, and (at least sometimes) performance.
But why would you care when an AI can just rewrite it? Yes, but can it rewrite it to a good architecture? Or just to a different one?
Does a good architecture make code easier for an AI to maintain? I don't know, but I think it's at least not proven that it doesn't.
It’s important for separation of concerns, which is important for maintenance and future iteration on features and bug fixes. If you don’t have separation of concerns, every change to anything is essentially a from scratch rewrite of the whole thing. That’s also incredibly inefficient in token usage.
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 am going to solve a complex problem" is a better goal. If you start with the goal of designing something ambitious then the design will likely end up more complex than necessary.
It might be because of happiness, ego, persona, and humility. All are very important factors we consider in establishing our identity, our self.
But because of time, we all have to consider the value of our own time. AI forces you to look in the mirror, and reflect.
Don't be afraid to change: use first principles thinking and broaden your perspective about yourself. Your station, your position in your own mind has changed due to AI. It's easier to think AI will just go away: and our egos and personas can remain unchanged. We'll be back to where we were, and everything we knew about value will be right where it was.
It usually doesn't work that way, and you usually don't do yourselves any favors in being so rigid and stuck in the old way of thinking about yourself. Keep up with the times, but balance your health and happiness.
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.
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.
Whatever it is you are doing, consider the very basic reason for doing it. And then, build your solutions from there from what is available. Examine the first principles of whatever it is you're doing.
You are working, and you are building things, to create value.
What are the tools you use to move about your environment and create your product, your value? Your knowledge, your training, your time.
If you examine the first principles of whatever it is you're doing, you should realize: you must keep your toolbox open and ready to swap new tools in and out in order to keep up with the time and manage yourself effectively.
AI is a tool, learn to use it as a tool and stop 'fighting the times' so much. All of your criticisms are valid, and you are correct: but everyone still wants to save time, and so you must keep up.
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?
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
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
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 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.
my gut reaction was to argue over semantics with you but no, you're right they are different. I don't think it's been the case in the overwhelming majority of my cases but you aren't wrong.
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.
Sure. You're spending your time doing something. That's probably to produce a product, or service, for someone else. In this case, it's the customer. So you put them first and foremost in your mind, and then work backwards to identify whatever process is suitable to create the product or service that meets their expectations. This ensures what you deliver is valuable. When we do this, it reinforces our own sense of value. We're helping someone.
You put the customer first, that's first principles thinking. You adjust the way you spend your time, according to your customer's needs.
Also agree with this. It's filtering work and priorities through the customer's lens instead of jumping right away to building. As in asking yourself first, why is this important, what does the customer want to accomplish, are there more of them who experience this ... feels in one way similar to the data-driven philosophy.
> 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.
As an engineer who grows into their career, the key insight I have found is the ability to think from first principles.
Finding key projects that impact your organization; being the first to dive into toughest operational challenges and finding non-linear solutions are also great ways to grow in your career.
> Approaching it from first principles means starting with what we’re trying to do and asking how AI could help
I’m not sure why would you want to think about how an AI would help. If you understand what you need to do and you understand the capabilities of the tools available you run the coding / learning loop. If you think you should use AI then you are solving the how to use AI problem, which just adds to the complexity. Orthogonal to first principle thinking, just a workflow issue.
I'm glad to have read this just to bring visibility to "the senior engineer death spiral". That was really helpful to me, it's something I am more or less experiencing myself due to this agentic era.
Now about this article, idk, maybe i'm just jaded on what engineering has become. My gut reaction is agentic engineering feels wrong.
Getting that on-call incident for a piece of code I own, when i've lost the mental map of what the black box does, it keeps me up at night.
Is the solution really going to be, "use ai for that!". Ugh.
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.
> 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?
Its so ubiquitous, you can pick random folks from most academia and see it first hand.
If this comes as a shocker to you, then I should be the one to enquire as to how you managed to stay blind in the face of the obvious.
Just strike up a discussion on some complex topic, and you can see many people resort to "because the author here in this book said" or "we are taught so and so".
A first principles reasoning can show you the steps that lead to a specific conclusion without invoking any author, teacher or course.
A specialist discussing a complex topic uses that as shorthand based on shared context. Nothing would ever get done if every conversation required starting from "first principles" whether inside or outside academia.
What's missing in your claim is evidence that people in academia often mischaracterize this style of discussion from accumulated knowledge and shared context as "thinking from first principles". I don't see any plausible rationale for why they would.
Otherwise, using their typical mode of interaction from outside observations to infer they misunderstand first principles is not a standard anyone doing specialized work inside or outside academia would ever be able to meet.
The private sector would grind to a halt if discussing a specific IEEE 802.11 protocol implementation with a fellow SME required a lengthy preamble of networking first principles before answering in order to be epistemologically sound.
Similarly, using a conversation overheard at a conference to infer the experts lack first principles thinking would not be reasonable just because they appealed to IEEE documents instead of rearticulating the underlying decisions made by the standards committee.
Your reasoning that first-principles results in inefficient communication is false. It is a common misunderstanding.
You can always breakdown one layer on demand. And you only need to drop down as far as the other party insists.
My example was about striking up direct conversation with someone and not overhearing.
If someone pointed to IEEE protocol and I asked "but X, so why?" and if the answer is still IEEE protocol again, then the person does not have "first principles".
That is the test. It exposes the shorthand user from the legit first-principles capable user.
Knowing what first principles reasoning is isn't the same thing as being willing to re-teach a discipline from the ground up for a stranger rather than first pointing to the existing literature that, perfectly or imperfectly, already addresses a topic.
You don't acquire it by learning or teaching about it. You don't acquire it from literature or lectures. You acquire it by being forced to do it. It requires wrestling with the problem domain.
And as you said, pointing to literature just "addresses" a topic. Obtaining it is a different matter altogether.
You're describing the kind of first principles thinking that gave us the Tesla car door handle. It's Silicon Valley, tech bro, smarter-than-everyone, nothing-to-learn-from-anyone bullshit.
Complex topics are built on history, on those who came before us, on attempts and failures and successes. Ignoring it is garden variety stupid.
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
I don’t know what principles this kind of thinking falls under, but one useful approach is to know clearly what you’re trying to do, achieve, or understand. Know your assumptions and be honest about them, acknowledge that they can fail and challenge them when they carry critical weight in your reasoning, and keep peeling back those assumptions until you reach a point where their correctness rests on obviously reasonable facts or axioms that you no longer need to unpack.
Also, in my limited personal experience so far, the people who relentlessly talk about and evangelize first principles thinking (mostly highly self-confident tech bros and big-tech veterans) are often the ones who fail most absurdly at actually doing it.
It reminds me of the exchange attributed to Robert Surcouf: when an English officer supposedly told him, “You French fight for money, while we English fight for honour,” Surcouf replied, “Each man fights for what he lacks.”
P.S I don’t have any stance on the French-English conflict in the anecdote above.
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.
> 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.
This is a nice anecdote about Hibernate, but in the world does it have to do with "first principles" thinking?
First principles thinking often leads to treating human beings as spherical cows.
Working backwards from the customer is first principles thinking.
If you do that you'll quickly pivot to selling drugs and gambling tips.
From my experience I have not experienced customer feed / customer thinking spiralling towards drugs and gambling tips.
Then also, companies are guided by some mission / values which might prevent you from going into that direction, unless you are working for an online gambling company
I sincerely do not follow how you get to drug and gambling when you think about being customer-first, what am I missing?
The idea is to be honest with ourselves. Once you start there, solutions arise.
They don't seem at odds to me, just two ways of looking at a problem.
They're not so much at odds, but the emphasis is very different and therefore the failure modes are. First principles thinking emphasizes the principles, and so that's why there's an ideological trap; all you need to justify a given direction is some rationale from first principles, and that's often good enough.
The problem is... which first principles? Say your goal is to get to the moon, and the principle you use is to minimize the distance, and you choose to do this in a greedy fashion. This will have you climbing ladders, trees, buildings, and mountains, and you will record that as progress justifying the approach. But you haven't reasoned far back enough to figure out just greedily minimizing your distance to the moon is never going to get you there, no matter what. Choosing the wrong principles can lead to local extremes which can be a lot harder to see in cases less obvious than going to the moon.
Reasoning backwards has its own traps as well.
Could you please explain what the difference is between first principles and higher order thinking?
Based on the moon example, it seems you define it as a set of principles you can base your decisions on? E.g. to get somewhere, you must minimize your distance. What makes something a first principle?
I'm asking because my understanding is that "reasoning from first principles" is just taking a step back, asking yourself what's really the goal and reasoning backwards. But it seems like you've got two different concepts (first principles and higher order thinking), which makes me think you've got it figured out more than I do.
> ideological trap
First principles are not an ideology; they are more like laws of nature. Due to that, they are great both for reformulating a problem, and checking solutions.
> they are more like laws of nature.
That's the ideology.
That sounds like more like "sticking with the first idea no matter what" than like reasoning from first principles.
yes that's the failure mode if one of your first principles is not to continuously reevaluate your first principles.
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!
First order thinking works really well when dealing with spherical cows and ignoring air resistance. Once nuance and the fractal complexity of the real world come into play factors come into play, empirical phenomenon and experience become much more important. How much weight you gove to first principles depends on how theoretical or practical your domain is, e.g. science vs engineering.
I think I'll stop commenting in this thread as it seems like no two people in this thread are using compatible meanings of "first principles" thinking. Forget about equivalent meanings of it.
"First order" thinking from my knowledge is an entirely different concept.
> 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!
> Higher order thinking is more important and rare.
I was just talking with a friend the other day about how many problems and issues would be solved if people were more conditioned to asking, "...and then what?"
This is a classic for the people who dream of interstellar travel. Okay, you figure out the problems (good luck) and after some 40-400 years land on some dead rock in the Alpha Centauri system. Congratulations! Now what?
And then you start colonizing? You take the supplies out of the generation ship you took to get there and then build housing and then farms. You build up industry and have lives until there's civilization and you can send messages back to Earth to share what life is like on Alpha Centauri. You and your children make art and music about your new planet, same as people did on the old one.
Rebuild civilization while avoiding the mind worms.
someone walked 14 years in minecraft. now what?
"Compared to what?" is another good one.
What is the difference between first principles and higher order thinking?
First principle: How can we accomplish X?
Higher order: What if we accomplished X?
Thinking from first principles would likely start with “Do we need X?”
Fair point, I'm skipping over the need itself. The titular first principle.
First principles: "We need X, how can we accomplish that?"
Higher order: "We need X, what would accomplishing that do for us?"
Yet another incompatible definition - here first principles thinking is define as "how do reach a solution?". If that were true, then it wouldn't be any different from "problem solving".
That's more-or-less the definition, no? First principles thinking and higher order thinking are both methods of problem solving.
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'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 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 can just always have the ideal architecture.
Now you have what you think is the ideal architecture. Since you didn't implement it, you didn't discover it was not the ideal one mid way into the implementation.
May be it is too complicated, but you wouldn't know, because LLM is doing the implementation. If you did implement it yourself, you might have spotted a critical point that might simplify the whole thing...
If you did implement it yourself, you might have spotted a critical point that might simplify the whole thing...
This is the "Jodie Foster in Contact listening for the SETI signal with headphones" theory of how production software systems work.
There have been multiple points in my career where I framed a problem as simple in my head, and it mostly was.
But then, one small detail changed everything. And it wasn't something I'd have thought of until I was writing the code.
I shudder thinking about the number of these issues hiding in LLM-generated code.
> hiding in LLM-generated code.
There is a difference between LLM-generated code that somebody merged essentially unseen and LLM-generated code which a human then looked at carefully and massaged until they were happy with it.
The first version can hide a lot of crap. All you see is the end-to-end functionality and there can be corner cases or scenarios which you have not tried and in which it is terrible or plain incorrect.
The second version hides just as many issues as human written code.
Unfortunately, the debate that our field has about LLM-generated code mixes both quite freely even though they are quite distinct.
And yet, continuing your analogy, she made an amazing discovery this way.
Jodie Foster did make an amazing discovery that way in the movie Contact, that is true. "Why build one when you can have two at twice the price?" would be my engineering takeaway from that movie though.
Only if you are a government contractor...
This has been my experience as well. LLMs know the patterns but often need to be nudged into choosing the proper one.
> 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 do the same, but without AI in the loop. Just me and my thoughts while cleaning or doing laundry or going for a run. The best designs and architectural choices and algorithms I've come up with in my carreer were developed and/or refined that way.
It's very enlightening, though it requires being comfortable with being alone with ones thoughts. It seems to me many people are not and need constant distractions and/or dopamine kicks.
Thinking alone about fundamentally deep problems can be poweful, but most software problems are not that deep, they follow a pattern, and it's only a question of discovering them. Doing that alone is inherently slower and less efficient than discussing it with a colleague.
AI just serves as a substitute - an artificial conversational partner.
I feel like you consider yourself more virtuous for not using AI for discussion. Would you consider people who don't talk to colleagues at all, but do all the work themselves more virtuous in an analogous manner?
+1. I have found that most coding harnesses are too focused on the doing that using a Claude/chatgpt chat gives me a lot better quality.
> 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.
What kind of discussions/thoughts is this about?
And do you feel comfortable with the setting that a corporation has a detailed log of your deepest thoughts?
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.
Almost all scalability and performance optimization is architectural in nature. AI writing the code doesn't eliminate this concern.
Some apps don't care about scalability and performance but many do. Ignoring architecture all but guarantees inefficient, wasteful software.
Why try to make things that are good? Why care about anything? Why not just turn our minds over to the machines, and let them rock us to sleep like babies?
Possibly because the goal is the end product that serves a purpose and has value, not the process. If you can make your product, make the customer happy, and make your money to enjoy your life and secure your families future… why care who or what or how (as long as it’s ethical obviously).
Every choice has a cost. The question comes as to when you pay it. Your idea of an end products behavior, and the end products behavior when it interacts with reality may differ significantly.
For example is unknowingly writing a security flaw ethical, when you could have used a set of processes to reduce them before release that would have make the entire thing take longer and cost more. Seems like programmers need a lot more ethics classes as ethics are part of any large scale process.
I agree with most of what you are saying, but I believe that this view on people's ethics is a little naive. Remember that we are talking about AI contexts here. Everything it infects has a questionale track record w.r.t. ethics on many levels.
Besides, ethics come from upbringing and social influences, not from attending a mandatory ethics class.
> Possibly because the goal is the end product that serves a purpose and has value, not the process.
This is not true for everybody or for every project. Sometimes it’s about the code and not about what it does. Sometimes it’s about learning. Sometimes it’s about the fun of creating. “Only the end product matters” is a narrow view of the world of software development.
Sorry, I thought we were talking about programming as a profession in the context of products and revenue generation.
[dead]
An agent can rewrite a small codebase in half a day, I have millions of lines of code - it can't rewrite that in half a day.
Because even if the rewrite worked, and worked perfectly, you've (a) lost a day, and (b) there's no guarantee that you won't have to do that all over again in a few days' time, because you're still not thinking about the architecture.
But if the codebase is large enough, and if you don't have tests for everything, you'll likely lose stuff along the way. So you'll then spend at least another day tidying up the rewrite, just getting it back to where you were two days ago.
Does that sound like fun? Wouldn't it be easier to just plan it correctly the first time?
How are you going to read the code if it's not structured in a way you understand?
I think the argument is that there won't be a reason to read the code. If you want a change, just let the agent change it.
Similar to the output of a compiler. Nobody (with very few exceptions) reviews its machine code output. No reason to do that. If you want to change it, just recompile.
(I don't share this view, but I think a substantial and growing fraction of folks does.)
Yes, I think you're right. It could be I haven't experienced the cutting edge of AI, but it a) doesn't seem there yet, and b) goes off on tangents assuming outcomes of decisions and needing to rewrite things a lot. So I quite like reading the output.
I've been of similar opinion but since Opus it is there, here and right now.
I haven't tried Opus, so perhaps I'm living in ignorance!
Mhh I've tried one-shotting double buffered IO a few times and it just can't do it. Maybe it's a prompting issue, maybe LLM's have a hard time with thinking about parallel processes.
I'll create a simple "framework" of what I know works. After that's there the LLM is fantastic.
Abstractions. They make it easier for a human to understand. We need abstractions to fit systems into our working memory. Agents dont.
Agents don’t have infinite working memory…
LLMs benefit from abstractions for the same reasons that humans do. More information in the same amount of text. Fewer working parts to juggle so fewer ways to make mistakes.
seriously? i truly hope this is not a common mentality in organizations these days.
I'd be sad working with someone who approached their work like this.
Why would you care about architecture? Ability to implement the current feature, ability to implement future features, maintainability, and (at least sometimes) performance.
But why would you care when an AI can just rewrite it? Yes, but can it rewrite it to a good architecture? Or just to a different one?
Does a good architecture make code easier for an AI to maintain? I don't know, but I think it's at least not proven that it doesn't.
It’s important for separation of concerns, which is important for maintenance and future iteration on features and bug fixes. If you don’t have separation of concerns, every change to anything is essentially a from scratch rewrite of the whole thing. That’s also incredibly inefficient in token usage.
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...
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
"I am going to solve a complex problem" is a better goal. If you start with the goal of designing something ambitious then the design will likely end up more complex than necessary.
Ambitious doesn't mean complex. Where did that idea even come from? I don't see this connection being introduced properly in this thread?
As an example, heliocentrism was profoundly ambitious yet devastatingly simple compared to geocentric formulae.
It might be because of happiness, ego, persona, and humility. All are very important factors we consider in establishing our identity, our self.
But because of time, we all have to consider the value of our own time. AI forces you to look in the mirror, and reflect.
Don't be afraid to change: use first principles thinking and broaden your perspective about yourself. Your station, your position in your own mind has changed due to AI. It's easier to think AI will just go away: and our egos and personas can remain unchanged. We'll be back to where we were, and everything we knew about value will be right where it was.
It usually doesn't work that way, and you usually don't do yourselves any favors in being so rigid and stuck in the old way of thinking about yourself. Keep up with the times, but balance your health and happiness.
Orthogonal does not simply mean different.. simple and ambitious designs often run askew of each other but they can also share the same line.
Orthogonal means independent. One doesn’t inherently affect the other.
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.
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.
Thinking is great. I am arguing that “first principles “ is one tool - and it may not deserve the primacy that its advocates propose.
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
Lots of words, not a lot of meaning. What is this post about?
> 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.
Whatever it is you are doing, consider the very basic reason for doing it. And then, build your solutions from there from what is available. Examine the first principles of whatever it is you're doing.
You are working, and you are building things, to create value.
What are the tools you use to move about your environment and create your product, your value? Your knowledge, your training, your time.
If you examine the first principles of whatever it is you're doing, you should realize: you must keep your toolbox open and ready to swap new tools in and out in order to keep up with the time and manage yourself effectively.
AI is a tool, learn to use it as a tool and stop 'fighting the times' so much. All of your criticisms are valid, and you are correct: but everyone still wants to save time, and so you must keep up.
Original author here. ^ bingo.
"First principles" is just the latest expression ruined by SFBA posers like "orthogonal" and "non-trivial" before it.
Tangentially related, but this seems directionally correct!
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?
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
> 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
what plan level are you on
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 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.
“first-order approximation” is pretty different from first-principles thinking in my opinion.
my gut reaction was to argue over semantics with you but no, you're right they are different. I don't think it's been the case in the overwhelming majority of my cases but you aren't wrong.
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.
Care to elaborate on this? how is this statement true?
Sure. You're spending your time doing something. That's probably to produce a product, or service, for someone else. In this case, it's the customer. So you put them first and foremost in your mind, and then work backwards to identify whatever process is suitable to create the product or service that meets their expectations. This ensures what you deliver is valuable. When we do this, it reinforces our own sense of value. We're helping someone.
You put the customer first, that's first principles thinking. You adjust the way you spend your time, according to your customer's needs.
Also agree with this. It's filtering work and priorities through the customer's lens instead of jumping right away to building. As in asking yourself first, why is this important, what does the customer want to accomplish, are there more of them who experience this ... feels in one way similar to the data-driven philosophy.
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.
given how the term is used lately, your questioning just means you're not insane yet, so I wouldn't worry too much.
> 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.
As an engineer who grows into their career, the key insight I have found is the ability to think from first principles.
Finding key projects that impact your organization; being the first to dive into toughest operational challenges and finding non-linear solutions are also great ways to grow in your career.
> Approaching it from first principles means starting with what we’re trying to do and asking how AI could help
I’m not sure why would you want to think about how an AI would help. If you understand what you need to do and you understand the capabilities of the tools available you run the coding / learning loop. If you think you should use AI then you are solving the how to use AI problem, which just adds to the complexity. Orthogonal to first principle thinking, just a workflow issue.
I'm glad to have read this just to bring visibility to "the senior engineer death spiral". That was really helpful to me, it's something I am more or less experiencing myself due to this agentic era.
Now about this article, idk, maybe i'm just jaded on what engineering has become. My gut reaction is agentic engineering feels wrong.
Getting that on-call incident for a piece of code I own, when i've lost the mental map of what the black box does, it keeps me up at night.
Is the solution really going to be, "use ai for that!". Ugh.
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.
> 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?
Its so ubiquitous, you can pick random folks from most academia and see it first hand.
If this comes as a shocker to you, then I should be the one to enquire as to how you managed to stay blind in the face of the obvious.
Just strike up a discussion on some complex topic, and you can see many people resort to "because the author here in this book said" or "we are taught so and so".
A first principles reasoning can show you the steps that lead to a specific conclusion without invoking any author, teacher or course.
Cheers. Hope it helps.
A specialist discussing a complex topic uses that as shorthand based on shared context. Nothing would ever get done if every conversation required starting from "first principles" whether inside or outside academia.
What's missing in your claim is evidence that people in academia often mischaracterize this style of discussion from accumulated knowledge and shared context as "thinking from first principles". I don't see any plausible rationale for why they would.
Otherwise, using their typical mode of interaction from outside observations to infer they misunderstand first principles is not a standard anyone doing specialized work inside or outside academia would ever be able to meet.
The private sector would grind to a halt if discussing a specific IEEE 802.11 protocol implementation with a fellow SME required a lengthy preamble of networking first principles before answering in order to be epistemologically sound.
Similarly, using a conversation overheard at a conference to infer the experts lack first principles thinking would not be reasonable just because they appealed to IEEE documents instead of rearticulating the underlying decisions made by the standards committee.
Your reasoning that first-principles results in inefficient communication is false. It is a common misunderstanding.
You can always breakdown one layer on demand. And you only need to drop down as far as the other party insists.
My example was about striking up direct conversation with someone and not overhearing.
If someone pointed to IEEE protocol and I asked "but X, so why?" and if the answer is still IEEE protocol again, then the person does not have "first principles".
That is the test. It exposes the shorthand user from the legit first-principles capable user.
Knowing what first principles reasoning is isn't the same thing as being willing to re-teach a discipline from the ground up for a stranger rather than first pointing to the existing literature that, perfectly or imperfectly, already addresses a topic.
You don't acquire it by learning or teaching about it. You don't acquire it from literature or lectures. You acquire it by being forced to do it. It requires wrestling with the problem domain.
And as you said, pointing to literature just "addresses" a topic. Obtaining it is a different matter altogether.
You're describing the kind of first principles thinking that gave us the Tesla car door handle. It's Silicon Valley, tech bro, smarter-than-everyone, nothing-to-learn-from-anyone bullshit.
Complex topics are built on history, on those who came before us, on attempts and failures and successes. Ignoring it is garden variety stupid.
According to you, demonstrating steps that lead to a specific conclusion was only used in Silicon Valley to just build Tesla door handle.
Your first principles reasoning must then be deference to authority and course. Good to know.
> Complex topics are built on history, on those who came before us, on attempts and failures and successes
Tell that to Alan Turing, Godel, Tarski, Aristotle and a lot of other first principles thinkers.
> Ignoring it is garden variety stupid.
Bro, What about ignoring the original comment.
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
Agreed. The skills at sufficient depth are increasingly transferable accross domains.
The tech bro culture of believing their thinking is kind of special is embarrassing.
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
I don’t know what principles this kind of thinking falls under, but one useful approach is to know clearly what you’re trying to do, achieve, or understand. Know your assumptions and be honest about them, acknowledge that they can fail and challenge them when they carry critical weight in your reasoning, and keep peeling back those assumptions until you reach a point where their correctness rests on obviously reasonable facts or axioms that you no longer need to unpack.
Also, in my limited personal experience so far, the people who relentlessly talk about and evangelize first principles thinking (mostly highly self-confident tech bros and big-tech veterans) are often the ones who fail most absurdly at actually doing it. It reminds me of the exchange attributed to Robert Surcouf: when an English officer supposedly told him, “You French fight for money, while we English fight for honour,” Surcouf replied, “Each man fights for what he lacks.”
P.S I don’t have any stance on the French-English conflict in the anecdote above.
<wrong thread>
Sorry, I think I'm being dumb, but where is the "first principals thinking" in your example?
“First principles thinking” is a Silicon Valley cliche. It is a tell for me
[flagged]
[flagged]
[flagged]
[dead]