« All Episodes

Principles Oriented Thinking as a Durable Skill in an AI First World

Published 6/10/2026

The skills that survive every industry shakeup aren't the ones you can Google — they're softer, harder to name, and far more durable. In this episode, Jonathan explores principle-oriented thinking: the practice of stripping away the labels we attach to tools, roles, and even ourselves to see what something actually does at its core. It's the difference between handing your coding off to an agent and rethinking your entire workflow around what these new materials are truly capable of.

If you've been following along with our recent focus on durable skills, you know we've been hunting for the abilities that translate beyond this month, this year, or whatever AI does to our industry next. Today's skill doesn't have a tidy name you can search for — it's softer than that. Jonathan calls it "principle-oriented thinking": the habit of deconstructing the labels we put on things to understand their core components, properties, and capabilities. It's how NASA engineers turned a sock into a water filter on Apollo 13, and it's how forward-thinking engineers are reframing what AI can actually do rather than jamming it into a predetermined slot.

  • Labels Are Useful Shortcuts — Until They Aren't: Every label, from "software engineer" to "sock," carries baggage, heuristics, and presupposition. That's not a flaw — labels are how we move through the world quickly. But when a label is the only lens you have, it quietly caps how much value you can get out of the thing you're looking at.
  • The Apollo 13 Sock: When the crew needed to fix a life-threatening problem with mismatched parts, the engineers on the ground had to forget what a sock was for and ask what it actually is — a piece of cloth with tensile strength, flexibility, and filtering properties. Strip the assumption that it goes on a foot, and a whole new set of uses opens up.
  • Stop Slotting AI Into Old Roles: The common move is to take one responsibility — coding, debugging, refactoring — hand it to an agent, and keep everything else the same. That works, but it's low-leverage. The more powerful approach starts by asking what the agent is fundamentally capable of, then rebuilding the workflow around those raw materials.
  • See Things as Materials, Not Fixed Functions: When you deconstruct out from under a label, tools and concepts start to look like craftable raw materials. You can then combine them in new, valuable ways they haven't been combined before — alloying old methods with new capabilities to create properties neither had on its own.
  • Reason From Properties, Not Personas: Ask what the actual properties of an LLM are. Non-determinism isn't a bug to apologize for — it's a property you can exploit. The existence of many different models is a property too, which is exactly what makes adversarial review possible. That's principle-oriented thinking applied to agents.
  • Extend the Latticework: Charlie Munger talked about a latticework of mental models that weave together rather than sit in isolation. The durable skill isn't quarantining your concept of "AI" off to the side — it's grafting a new section onto the existing tapestry and letting it reshape everything you already understood.
  • Episode Takeaway: Look at how you spend your time and ask new questions of it. What is the material here? What kind of thinking does the agent actually do? What can a human do that an LLM can't — and the other way around? That's how you avoid believing a sock is only ever good for a foot.

🙏 Today's Episode is Brought To you by: Unblocked

Your coding agents have access to your code, your repos, and probably a pile of connected MCPs filling up their context — but access isn't the same as good context, and a bloated context window can actually degrade the very reasoning you're relying on. Agents don't know your architectural decisions, your team's patterns, or why an API was shaped the way it was, so they look in the wrong place and deliver bad outputs you then spend time and tokens correcting. ● Unblocked is the smart context layer your agents are missing. ● Instead of ingesting everything and getting lost, it builds reasoning over shared context. ● It turns code, docs, tickets, and conversations into actionable context — so engineers move faster, agents make better plans and write higher-quality code, and you burn fewer tokens and fewer correction loops. If you're running Claude Code, Cursor, or any agentic workflow, it's worth a look. A free three-week trial is available at getunblocked.com/developertea.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

🗞️ Subscribe to The Tea Break

We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review!

Transcript (Generated by OpenAI Whisper)

If you've been listening to Developer Tea recently, you know we've been focused on skills that are going to be durable. Skills that are going to translate beyond this month or even this year. That are going to be important for you as you continue to grow in your career. despite whatever is happening in AI, despite whatever's happening in the industry more broadly. These are skills that I believe are durable beyond all of those major changes, major shakeups that we're seeing in our previous kind of valuable skill set. And this is something that I think is on a lot of people's minds. It's something that I think is a really hard question to answer. What is the job of tomorrow? What is the job of next year and beyond for the average software engineer? And while I don't have great answers for you, I don't know what software engineering is going to look like in a year from now. What I do know is that there's a lot of things that humans are pretty uniquely good at. And it is likely, as likely that the skills that we've been talking about on these episodes, So skills like providing solid feedback that actually is action oriented and that understands how other people receive feedback. This is going to be an important skill in the future if you're working with humans at all. And everything that you do in the future, whether you're working with AI or not, will also depend on your ability to work with other humans. And so this is where a lot of these skills are going to centralize and focus our ability to understand, communicate, to work well with other human beings. Hopefully this isn't surprising to you. In today's episode, we're going to take a slightly different look at a skill that I think is really critical. And what's interesting about a lot of these skills is that they don't really follow the same structure that maybe in early in our careers, we would have been able to Google a particular skill or google a particular domain and learn about that particular thing these skills are a little bit softer by nature the durable skills we're talking about here don't really have a single name right so for the sake of this episode i'm going to talk about this from the perspective of principle oriented thinking principle oriented thinking so what What is principle-oriented thinking? How is it useful? What can you do with it? Why is this durable? That's what we're talking about in this episode. Principle-oriented thinking has gained a lot of interest over the years. I'm not sure who it was originally who coined this term. And really, it's not even a term. It's just a definition. The basic idea behind principles-oriented thinking is to deconstruct our assumptions about something based on the labels that it has. That's the starting point. So what does that mean? If you, for example, let's say that the label that you have about your job is software engineer. Okay. And so along with these labels, because this is how our brains work, along with these labels comes a lot of presupposition, a lot of baggage, maybe if you want to look at it from a negative angle, but also comes with a lot of shortcuts, a lot of heuristics that we attach and the meaning that we attach to these labels. So a software engineer, for most people, you hear this and you you think, oh, that's somebody who knows how to code. That's somebody who, you know, is adept with computers. It's somebody who understands data structures or understands algorithms. Depending on your personal experience as software engineers, you may assume that they follow a certain set of personas, for example, right? That there's, you know, they lean towards more scientific thinking, possibly, right? These are, you know, we start to layer in things like stereotypes when we use labeling. And there's nothing necessarily wrong with this. I just want to kind of, you know, dispel the idea that labels are bad. It's not necessarily true. We use labels all the time. Labels are a fundamental part of our language. They're a fundamental part of how we We navigate the world around us, right? We use labels to quickly communicate meaning and to quickly understand, you know, one thing from another. And labels can become overloaded, but a lot of the time they're just useful shortcuts, right? Imagine if you went to the grocery store and instead of seeing the name of the thing on on the box, it told you, I don't know, the chemical composition of the items in the box, or it was overly detailed about, you know, exactly how many, you know, macaroni noodles were in that box, rather than giving you labels. These are abstract concepts, and we build abstractions on abstractions. And so, or, you know, if we were to break it down to no labels at all, then you would have nothing on the box because everything, even names of chemicals, these are labels. These are things that carry meaning that we've evaluated and we've built our language. And now that language helps us kind of move through the world quickly. Okay. So what's principles-oriented thinking and how does it kind of, you know, juxtapose to this label-oriented thinking. Principles-oriented thinking is still going to use labels. I just want to kind of get that out there. We're not just thinking in abstract. Our thinking can still attach words and concepts to things when we're engaging in principles-oriented thinking. But instead of relying on the base label and the assumptions that go along with it, the the baggage or the history or the experiences that we have going with that, we tend to deconstruct out from under that label and understand the core components of a thing, the core concepts, the core capabilities, for example, right? I recently re-watched the movie Apollo 13. If you You have never seen it. I highly recommend it. It's a great movie from the 90s. And I won't go into detail about the story. But one of the critical moments in the film, the crew that's on the spaceship, maybe mild spoiler warning. Hopefully, if you wanted to see this without spoilers, it was about 30 years ago. But the crew that's on the ship, they encounter kind of a challenging and life-threatening event, right? And they're working with Houston Center. They're calling back on the radio trying to figure out what to do about this. What do we do about the fact that we have this component of our ship that is broken? And it's life-threatening. And the people on the ground had duplicated all of the items that were on the ship. And this is a typical thing for NASA to do. They have a perfect clone of whatever is in space. They have perfect clone, perfect simulation of that on the ground. And so the scientists on the ground had to get in the mindset of principles-oriented thinking in order to cobble together a solution. This is a thing that won't fit. We have to make it fit. and some fundamental characteristics of these things. We need to take advantage of the fundamental characteristics of these things. Again, not to spoil the story, but as an example, one of those items that they used to fix the ship was a sock. It was like a sock, like a sock you would put on your foot. but the principles-oriented thinking here takes away the label of sock. It takes away the presupposed idea that this is something that is supposed to go on your foot. Right? This is something that covers your foot and keeps it warm. It protects your foot, whatever. Right? Let's take that away. What is this actually? What is the fundamental thing that we're looking at here? From a principal's perspective, a sock just so happens to be a sock. From a principal's perspective, this is a piece of cloth. In fact, breaking it down further, it's got certain tensile strengths and some flexibility. It has some characteristics that, for example, if you were to use it to filter water, you could use a sock to filter water. water. All right, so this is one part of principles-oriented thinking that you have to break things down in order to understand how to fit them into your mental models. What does this thing actually do? What is it at its core? What are the aspects that actually control what this thing is? If I can take away the assumption that the sock is a thing that goes on on your foot, what else can it do? What other parts of my assumptions about this thing, if I were to take them away, what else could I use this for? Right? And so this principles-oriented thinking, once again, it's going to shift your worldview about a particular thing. Now, it's something you can engage in intentionally, or it's something that you can kind of build a a habit around. If you think this way, then things become less specified and become more like materials. Why is that important? We're going to talk about that right after we talk about today's sponsor. You have coding agents most likely. They have access to your code base. They have access to your repos probably more. You've probably connected a bunch of NCPs filling up your context but it's not easy to keep up with everything. The access that they have to your context is not necessarily good. You haven't necessarily shaped that access, right? You haven't shaped the context. In fact, if you're filling up your context window window, that context itself may be degrading. Agents can't reason across MCPs very well, especially when the context starts to get big. They don't know your architectural decisions, your team's patterns, or why the API was shaped the way it is. So agents end up looking in the wrong place and they'll deliver bad outputs. Then you end up spending time and tokens trying to correct what the agent did. Unblocked is the smart context layer your agents are missing. Instead of just ingesting tons of data and getting lost in a gigantic context window, Unblocked builds a reasoning over shared context. Unblocked turns code, docs, tickets, and conversations into actionable context. So engineers move faster, agents make better plans, write higher quality code, use fewer tokens on bloated context, and require fewer correction loops. And connection loops, by the way. if you're running Clog, Code, Cursor or any agentic workflow Unblocked is definitely worth a look go and check it out a free week a free three week trial man they really try to trip me up with that one a free three week trial is available at getunblocked.com slash developer T that's G-E-T unblocked.com slash developer T thank you again to Unblocked for sponsoring today's episode of Developer T Okay, so principles-oriented thinking has broken things down. We've deconstructed. We've removed labels. We're looking at kind of the core characteristics of a thing, the core characteristics of a software engineer. How did you become a software engineer? What kinds of learning? What kinds of mindset did you have to have? What kinds of fundamental understanding do you have? What kind of experience do you have that is unique to your situation? Instead of abstracting that and just saying software engineer. Right? So we understand kind of the core principles of what something is constructed of, of what a person's experience is constructed of. of what that sock on Apollo 13 was able to do, right? Not what it was intended to do, not what it was designed to do, not what the book says it's supposed to be able to do, but what it can actually do, okay? And so we start to see things as materials. We see things as, and when I say materials, I mean craftable, kind of raw materials. And this is important and it's part of our fundamental skills going forward. It's a durable skill for this reason. As we begin to see the materials laid out before us, we can begin to combine them in new and exciting and valuable ways that they haven't been combined before. So here's a differentiator that I'm seeing right now. For more senior engineers, for more forward-thinking, innovative engineers, the folks who are really kind of on the forefront of the industry, they aren't slotting AI, agentic coding, into a predetermined slot. lot. The opposite of this is somebody who says, okay, the coding aspect of my job, now I hand it to an agent, but everything else stays the same. The coding aspect or the debugging aspect or the refactoring aspect, I'm going to take this one really specific responsibility. Remember this word because we're going to come back to it. This one role, this one responsibility, and this one one label, and I'm going to hand it to a different process now. And so the same things are happening. We're just kind of shifting lanes. We're using a different method to achieve the same outcome. Now, this isn't necessarily wrong. Of course, an agent can plug into your same method. it. And of course, we can get some kind of value out of that, right? If your old process was working and this new process also works, then certainly you're not going to hear that that's useless. That would be, I don't think that's true. What I do think is true is that a more powerful way, a more kind of leverage, high leverage way to think about agentic coding, to think about AI, to think about agent-driven workflows, is to understand at a more fundamental level, what are the principles of this agent? What is the agent capable of first? And now we look at this broad set of materials and we begin to think about the way that we accomplish something, the way we used to accomplish it versus the way we could accomplish it with these new materials. When I said we're going to come back to the role, responsibility, and labeling language, a lot of times what people will do, The error that I think is in this is looking at any tech or any person, any role, any material even, right? Material, conceptual material or physical material, whatever, and slotting it into a predetermined role. Right? So quality engineer is a good example of this. So an architect would be another example of this for the role, the people side. And in many ways, this is exactly what we do. This is saying that a sock really only fits on a foot. The problem is that when we can only see something through the lens of a narrow deployment, let's say, of a narrow use, then the multiplicative value of understanding that thing of understanding the principles of that thing the multiplicative value of that is limited drastically right so how this all comes together if we were to go back to what Charlie Munger said about the lattice work of mental models what he was talking about there is The fact that none of these are really isolated. These mental models, they weave together. And when you learn one concept and you learn another concept, you actually get to learn a myriad of complex interactions between those concepts as well. This is the latticework he's talking about. so instead of isolating and quarantining our concept of what an agent is instead of quarantining our concept of what we are in the world of ai the durable skill is recognizing how to graft a new section onto the tapestry tree, right? How to extend the lattice work. How does that new thing change all of your existing lattice work? How can we use the principles, the core components of the incoming concept of this new material? How might we alloy that, right? Take in metal, metallurgy, I guess is is what it's called i'm not sure um mixing metals right you create an alloy and the properties of the new alloy might be uniquely useful to you whereas the the properties of either one of the previous metals may have been uh that you may have generated a new set of properties with the alloy okay what well how are we thinking about what the new materials are coming from AI tooling. What are the new principles that we can take advantage of for software engineering? How does that work into the latticework? How does it change our set of available concepts so that what previously we understood as our latticework man, we have a whole new section that can grow and change and bolster and adjust our previous understanding. Right? So how this actually plays out is, you know, in practice, you may be sitting there thinking, this all sounds good in theory. How do I change the way I think about this? And I think in practice, you begin to look at the way that you spend your time, the way you accomplish some need. You might start to ask new questions about what part of the agent workflow could fit in here, right? Right? What principle components, what is the material here? What kind of thinking does the agent do? Right? And here's the interesting thing. One of the interesting things is that people who are not thinking through the principle components and the actual kind of properties, right? And this is another very important word when you're talking about principles-oriented thinking. It's the properties of a thing. Because if we can find, you know, you can think about properties as capabilities, right? What is the properties of the thinking of an agent? Can an agent think in a bulletproof manner? No. One of the properties of LLMs and agent-based thinking is non-determinism. How can we take advantage of non-determinism? How do we take advantage of the properties of an LLM. One of the properties is that there are many different models to use, right? There's many different trained models and not all of them are going to be good at the same stuff, right? And so you could, for example, right, you could use this property of of LLMs, of the proliferation of many different models of LLMs, there's a core property there that allows you to create systems that can argue with each other, right? Adversarial review would be an example of a principles-oriented way of thinking about agents. If we were to not understand those properties, then we might imagine that, you know, an agent, the best thing an agent can do is to try to coach our team for us. Right. So and understanding that, OK, well, this is just like we're we're we're labeling an agent like a human. We are we are using this very broad label of this is a brain. Right. And instead of inspecting, well, what are the properties of a human brain that we're now assuming can overload the properties of the LLM brain? In other words, are we assuming that the LLM can act like a human? What parts of human does the LLM actually accomplish? What kinds of things does a human do that an LLM can also do? and and importantly what are some things that the llm can do that the human can't do and vice versa this is how we get to principles oriented thinking this is how we understand the core components the core capabilities and we avoid falling prey to thinking that a sock is only useful on a foot thank you so much for listening to today's episode of developer t i hope you we enjoyed this episode. Hopefully these episodes about these durable skills and how we're going to push through as an industry, what is the forward thinking, the optimistic thinking that you can have during this time as a software engineer? We all can see that our jobs are changing. We all can see that this very well will leave a lot of people without a job or Or many people, their job will change enough that they're not really sure how to orient to it. And that's really why I'm doing these episodes is to help people like you kind of work through that, find clarity, perspective, and purpose in your careers. That's been our mission for like 10 years on this show. So hopefully this episode has done just that. Thank you so much for listening. Thank you again to today's sponsor, Unblocked. You can get three free weeks at getunblocked.com slash developer T. That's getunblocked.com slash developer T. If you enjoyed this episode, consider subscribing. We have YouTube. We have a podcast. Of course, podcast is the longest running thing. So you probably are already subscribed if you listen to the show regularly. But if not, please consider subscribing and subscribe on YouTube. We've been doing YouTube videos now for something like a year. I'm not sure exactly how long it's been. and so that's a new channel for us and it's an exciting opportunity to expand the reach of the show and speaking of, the reach of the show is the way that we keep it going. If we don't have people listening, then it becomes really hard to keep the show going because it's hard to have advertising. That's a very simple model. It hasn't really changed very much in many years. It's kind of always been the model of Developer Tea. We are ad supported. so if you thought this episode was useful if it was useful to you it was free for you please share this episode with somebody that you think would also find value in it thank you so much for listening and until next time enjoy your tea