The last thing you need is another engineering leader, another engineering manager, someone who seems out of touch with your day-to-day work, telling you that you need to pick up AI, that you need to use agents more. And so I'm going to avoid doing that today. And instead, I want to talk about a little bit of history, a little bit of history that might be helpful. Um, if you have found yourself in a place where you think that we're in a, uh, a fundamentally unique scenario, uh, this might be some useful background on scenarios that kind of looked a little bit like what we're going through in the industry today. And, uh, hopefully this can provide some kind of useful thought for you if you're struggling with what it means to, um, to adopt AI. Today, there are a couple of stories that I think are relevant. One is if we rewind back to the 1950s, um, the development of Fortran, and we're not going to go through every point in the history there, but Fortran is widely considered to be the first high-level language. Uh, if you were to go read it now, it may not feel high level, but at the time, um, the alternative was essentially assembly code. It was direct, management of, uh, of memory, et cetera. And Fortran was not too far abstracted from that low-level thinking, but it did generate, um, machine code for you. Now, of course, there was a lot of skeptics of this. Um, for example, and this is only anecdotal, there's not proof that, um, that this quote actually occurred, but, um, it captured, captures the spirit of some thinking at the time. Uh, the great mathematician, John von Neumann, um, mentioned that he didn't understand the value of using this highly scientific machine that should be crunching numbers, that should be doing math, really serious work, and instead tasking it with clerical work. At the time, this seemed rational. It seems kind of odd to waste the machines, time, uh, to task it with something that more or less is, is above its pay grade or below its pay grade, uh, doesn't really fit the machine. Um, similarly, a lot of people believed that they couldn't trust the underlying generated code because who knows what that assembler is doing. Now, the interesting thing, um, about this is that eventually we start to see that it's not just a simple, um, underlying assemblers almost entirely. Now, not as a, you know, a discipline that doesn't exist anymore. Of course it exists, but much of what we argue about in computer science has nothing to do with assemblers at all. So what happened? Well, interestingly, the critics were kind of right. At first, the quality of whatever was produced by the assemblers was not very good. It produced things that needed a lot of massaging, a lot of work, a lot of adjustment. And so the team working on Fortran, they put more time into it. They put more time not into moving backwards and picking back up the old way of doing things, but instead improving this new way of thinking, improving the assembler. So the interesting part that I want you to focus on here is that the problems, the criticisms of this new way of thinking, of this abstraction, drove the improvement of the abstraction. So instead of it being right or wrong, instead of seeing this problem and then moving backwards, it's actually improving the assembler. So the team working on the abstraction, the team working on this forward-thinking tool, they pushed through it and they improved the thing. There's a similar story in a completely different field. You all who have listened to the show for long enough know that I have my pilot's license. I've been flying for most of my life. And you may also know that, air travel, especially commercial travel, is considered to be possibly the safest form of travel, especially per mile of all forms of travel. Incredibly safe overall, but it wasn't always this way. It took a lot of work to get there. One thing that has made airline travel very safe, incredibly safe, all things considered, is automation. In particular, autopilot. One thing you may not know about autopilot is that autopilot has been around in some form almost since the beginning of aviation. You can look this up. Autopilots have been around long before we had jet engine airplanes. So it's not a new thing, but it became popularized and then especially commercialized at a later time, around the world. So it's not a new thing. It's not a new thing. It's not a new thing. Around the 70s, 80s, I believe. Somebody can fact check me on this. It's not incredibly important to the story. The important thing is there were interesting effects that occurred as a result of this shift towards automation in particular. And it kind of is shaped like when we go on autopilot mode with quad code, for example, sometimes we may trust that thing and then our skills may degrade. This happens, with pilots in some cases. There was an article that came out sometime around 2000, I believe. And the article was titled Children of the Magenta Line. If you're not familiar with what the magenta line is, on a GPS, in the airplane I fly, the GPS that I use, there's a magenta line. And this magenta line is what you're supposed to fly along, right? This is, you know, how you're tracking, you know, using GPS, right? It is kind of the GPS track. And what happened was there was an aviation accident. And the accident was attributed to the automation failing. So the GPS and the autopilot, these systems failed. And the pilots were not very skilled at the manual flying that they were then tasked to do. To respond to this failure. So this is instructive for a lot of reasons. One, it would be crazy to throw out the baby with the bathwater, so to speak. It would be crazy to say that we should just take all of the GPS and autopilot away because the skills of these pilots degraded and it presents a new risk. This new risk is relatively, relatively small, it's extreme, but it's small. So what this looks like is we get drastically safer flights because a lot of the cognitive overload that you otherwise would have put on a pilot is relieved. And that pilot has a lower likelihood of making mistakes, right? This is cognitive saturation is something that is deeply studied in aviation. And the lower the cognitive saturation, the more capable the pilot is with dealing with new things. That's the thing that's come up and they can evaluate new information a little bit easier. If they're holding the yoke, then it's harder for them to think about something else entirely. It's harder to do math, for example, that they might need to do to fly to a particular fix point. It's harder to listen to the radio. It's harder to diagnose a problem with an engine, right? Because their brain is kind of like partially working on something else. And so if we relieve the cognitive saturation, then the pilot is freed up to work on these other things. And so if we relieve the cognitive saturation, then the overall, these other things come up a lot more often, right? In fact, every flight, now we have this benefit of reducing cognitive overload. This cognitive saturation is reduced. And so now we have a new like kind of safety margin that's added to every flight, right? Except, except when we need the manual flying skills. In the rare case, in the rare case that this automation stuff fails, then the pilot has to fall back on this old knowledge, right? This, this, this pre-existing manual flying knowledge. And so we have much safer on average flights with a few situations where the pilot could have probably saved the, the, you know, the plane from disaster, but their skills had atrophied and therefore disaster occurred in that particular flight that sparked this article. So what can we learn from this? Of course, you know, there's, there's a lot that we could, you know, instructively, we could learn that, well, maybe we should practice these manual skills from time to time. If you are using Claude code, maybe it makes sense for you to dive into your code base, AI assistant free on occasion, right? Maybe it makes sense to engage with elite code, even though you may never actually do that in your job again, only to keep your skills sharper. That might, be a strategy that you take. That's an instructive thing that you could take away from this, but that's not really the point of what I'm trying to convey in this episode. What I really want you to take away is that we have to think about this, the shape of this new problem or these new problems, these new dynamics as not all one direction or the other. They present new challenges that are fundamentally shaped differently that are multi-dimensional, right? There's, new harder things and new easier things. There's more safety, more quality, and then there's also new risks against our quality. There's the potential for our skills to atrophy. And now there's also potential for us to focus on entirely new things and deliver more, right? So there's a lot of dynamic emergent reality here. And it is a mistake. I would say, especially for those of you who are leading teams, who are trying to, make decisions about agents in your, in your ecosystem. It's a mistake to try to shove this thing, this, this new component into your existing workflow as if it's just an accelerant, right? As if it's just a component that you can add. That's a mistake. Another mistake is to imagine that it is either taking you in a good direction or in a bad direction, right? This is a dualistic way of thinking. And overall, I would say, you know, put this in your back pocket, AI or not, whenever you find yourself creating duality or imagining a duality existing, you should take a step back and ask whether that dualism is just your brain trying to make things easy to understand. Most of the time, this is the case. The dynamic nature of this thing doesn't just create only good effects or only bad effects. It creates new effects that are across, that spectrum, right? So we have a higher likelihood of skills atrophying and which we would maybe agree that that's not what we necessarily want, or, you know, at least it's a dynamic that we need to pay attention to that we have to prepare for that creates new risks. We have to pay attention to as well, but it also frees us up to think about totally new stuff, right? And so that's a new opportunity. That's not, not necessarily, again, not necessarily good or bad. But perhaps it's something that creates a, you know, it might draw, for example, it might draw completely new candidates to the table that previously were not interested in engineering. Now they are because they get to think about a new set of problems. Similarly, we may be driving engineers who really loved doing this job five years ago. They may be driven away from the industry. They may not enjoy the job that is emerging. And so we have to think about all of this. And the same way that if you were writing a simpler code in the 1950s, as the sixties and seventies and eighties rolled around, your job looks completely different, right? And so it's not all one direction or the other. It's not all good. It's not all bad. And it's not really, you know, a useful mental model to say, the moment I see something bad, I'm going to regress. I'm going to remove all of the good to avoid the one bad. Right? Similarly, similarly, if we see something good, if we see an opportunity, we shouldn't ignore all of the bad that comes along with it, all of the negative effects, all the risks that come along with it. We should be able to look at this from a multi-dimensional perspective, recognize the new dynamic situation that is emerging rather than trying to judge it in one direction or the other. The fact that we have these forcing functions, we are kind of in this new kind of emergent age where we have basically Fortran again, we have this fundamentally new technology that people are advancing very quickly. It's changing in quality. It's changing in shape. And, and a lot of opinions are emerging. You probably have one, if you're listening or watching this right now, that is nuanced and it's based on your experience and it's based on the experiences of a lot of other people, but it's in a deep state and these things will likely, if, if, if this plans out like most, um, uh, you know, technological revolutions from the past, a lot of this stuff is probably going to level off in some way. It'll change, it'll change shape, but it won't have the same accelerant or accelerated pace forever. Most likely, we don't know when that will end, but the accelerated pace will change in some way. And so we'll have some kind of stabilization. If this is shaped like most technological revolutions, we'll be able to level off in some way. And so we'll have some kind of technological revolutions in the past. So we'll kind of level out and then, uh, there will be, you know, most likely there's going to be, um, you know, a latent adoption, uh, once these tools stabilize. And a lot of these questions that we had about whether this was, you know, a reliable technology or not, the, the fact that it's unreliable today, most likely will drive future reliability if it's shaped like most technological revolutions. A lot of what we can learn about this. Um, I don't want to dismiss the fatigue that the people who listen to the show probably have talking about this subject. We all know because we've been saying it for this whole year, at least, um, we're coming up on a year since things really kind of shifted into high gear for us as engineers, um, coming up on multiple years for me, uh, in, in engaging with and understanding how agents change my work. The fatigue is real and you have to pay attention to what that's doing to your mindset. And, uh, it's useful to take a step back and to think about these dynamics and to frame this, this moment in history through previous moments in history. What has this looked like before? And what can I learn from that? Thank you so much for listening to today's episode. I've developed a team. If you enjoyed this episode, go and leave us a review in iTunes. You can also find us on YouTube. Now we've been doing YouTube now for, I guess, a year and a half, something like a year and a half. Um, and that channel is growing and you can subscribe to that. And, uh, if you, if you are on YouTube more than you're doing podcasts, then that's a great place to watch the show as well. Thanks so much for listening until next time. Enjoy your tea.