many of the questions that we have about our careers right now feel existential in nature and so many of the episodes that we've been doing recently and that we'll probably continue doing for some time are about preparing for this and how do you deal with this changing industry? How do you prepare for that? What skills do you need to have? What mindset is going to work in this changing reality? And we've talked a bit about the idea that your ability to update your mental models and your thinking is a critical skill. And in today's episode, I want to expound on that a little bit and talk about some specific kinds of models that are very popular or were very popular in software engineering, some thinking models that deserve scrutiny. They deserve potentially to be thrown out entirely or at least replaced by something better. And some of these models will be familiar. Some of them, we're not going to talk about a ton of them. We're going to talk more thematically about this idea that some of our assumptions that are really hard to let go of should be challenged. They should be challenged. And so if you think about from a systems perspective, if you think about what is happening, we've talked a little bit about the economics, kind of the microeconomics, what happens on a given project. As a result of agentic coding, what happens to a feature as it flows through your organization, through your team, through the different functions in the company that you run. And of course, this is challenging a lot of our kind of pre-existing beliefs about our roles and about what engineers are, what our job is. And you've probably seen, you know, product managers who are producing pull requests. And you've probably seen engineers who are making product decisions. And because as these more generic tools, these agents become more available to us, our ability to abstract increases. This is nothing. especially new. If you look at how, for example, how the computer impacted office jobs, knowledge work was able to wield in a lot of different places that previously it was not, you know, particularly effective or required more specialization, right? So now, you know, a pre-calculator, it would take a mathematician to work out a particularly complex problem, but now, you know, with a calculator or Wolfram Alpha, of course, certain LLMs have parts and pieces of really complex math that they can do right at your fingertips, and no longer does it take specialization to work out even complex, you know, calculus problems anymore, right? Similarly, you know, we see things like accounting, ledgering being largely, you know, commoditized in a way by spreadsheet applications, and this kind of abstraction into a tool that makes something a little bit more accessible, right? It makes it easier to grasp, and so we see this revolution of coding being more accessible, and like in all of the other applications, you know, all of those other situations, the abstraction leaves something to be desired, right? The quality of code that an agent might produce may not necessarily be to the same level of quality that a staff engineer with tons of experience writing code by hand, you know, arduously over the course of many months, it's not necessarily going to be a one-to-one match, but that's pretty much all that's going to happen. So, you know, I think that's a really good point. I think that's a always true with abstraction, right? So, this is the economics of the situation. Basically, the losses that we experience, and most of these cases are acceptable to the gains that we experience, right? Or comparatively to the gains that we experience. So, in other words, the speed, you know, as one, you know, potential gain, the speed of being able to deliver something that otherwise would have taken weeks, even if it's not a hundred percent, but it's still a lot of time, it's still a lot of time to deliver, you know, some feature, for example, with a few more bugs, but twice as fast or three times, four times as fast. And so, the economic picture here starts to make sense. The typical argument against agentic coding from an engineering perspective is that this is going to produce a lot of quality issues, but most people making these decisions about whether or not should we buy into agentic coding are accepting... ... act that there will be quality issues. And so our job as engineers is to move past these kind of surface level questions onto the so what questions. So what do we do about this? So how do we engage with this new set of tools? Or how do we engage with this new economic reality that we're facing as engineers? And some of this is about kind of challenging those pre-existing models. And we're going to talk about some of those models in this episode. In particular, if you've ever looked at a project and, you know, somebody was telling you to move faster, and you pointed to, you know, a specific model that we're going to talk about right after we talk about today's episode, we're going to talk about how to move faster. And so we're going to talk about today's sponsor. This episode is kind of tailor made for you, especially those of you who have been doing this a long time. You have wisdom that has been bought through tons of blood, sweat, and tears, and many nights and weekends possibly of learning how to do this stuff. You know, many failed projects that you have, kind of that you carry with you. You are the people who have the wisdom that I'm asking you in this episode to consider challenging. We're going to talk about that right after we talk about today's sponsor, Unblocked. Your coding agents have access to your code base and probably much more than that. Maybe you've connected other tools via MCPs or skills or something, but it's not easy to keep up with everything. And access doesn't necessarily, wait to context engineering. Agents aren't really great at reasoning across MCPs. They don't know your architectural decisions, your team's patterns, or why the API is shaped the way it is in the first place. So agents look in the wrong place and they deliver bad outputs. Then you end up spending time correcting or wasting time and tokens. Unblocked is the smart context layer your agents are missing. Instead of just ingesting tons of data and getting lost in gigantic context windows, Unblocked builds reasoning over shared context. Unblocked turns code, docs, tickets, and conversations into actionable context. So engineers move faster and agents make better plans, write higher quality code, use fewer tokens, and require fewer correction loops. If you're running clogged code, cursor, or any other agentic workflow, Unblocked is worth a look. Get a free three-week trial at getunblocked.com slash developer T. That's G-E-T, Unblocked. Unblocked.com slash developer T. Thank you again to Unblocked for sponsoring today's episode of Developer T. So we're talking about mental models that are fundamentally challenged in this new paradigm. And let me take a step back and say that this is a skill that will serve you regardless of whether you buy into agentic coding today or not. There's plenty of people listening to this right now. You may disagree with me steeply about how useful AI is in your workflows. And I think you all know my opinions on this. I try to avoid being too opinionated on this show, but I do think that this is a coming revolution. And everything that we do, if you haven't already been hit by that wave, then you almost certainly will. But even if you don't believe that, even if you're saying, oh, this is mostly hype, and Jonathan has been infected by the hype, fine, fine. This skill of being able to challenge your pre-existing models is a critical skill. It's a critical skill, especially, and this is kind of the key, is like, as you get more seniors, you're going to be able to challenge your pre-existing models. If you can't do this, you're going to hit a ceiling, right? You're going to hit a ceiling because you're going to keep doing the thing that always worked for you. Because it was born by a lot of experience, a lot of what feels like wisdom. And in many cases, it is wisdom, right? These models served you well, and they were valid for a long time. But the truth of the matter is, models are an approximation of the reality that's around us. That's the whole point of a model, is to approximate reality in a way