If you're a software engineer, you may feel, like many other software engineers feel, that your world is changing overnight. And in today's episode, we're going to talk about this kind of discontinuity between the software engineer's experience and what the kind of bigger picture is saying, specifically about how AI is changing software engineering. And if you're listening to this in the future, then a lot of this stuff has probably been talked about in circles over and over, and there's probably books about it, about how these principles and behaviors are changing and how we should think about working with software engineers. This is a seismic change, agentic flows, agentic work. The fact that, for the most part, many software engineers who are listening to this right now are writing half or less the amount of code that they wrote even a year ago, less than a year ago. This is a... This is a absolutely groundbreaking shift in the industry. And it's groundbreaking for a lot of reasons. You know, this isn't just as simple as we've changed how we write code, right? That would be, you know, the same kind of thing as if a new language came out that made a bunch of things easier. And those changes in the past have been pretty significant. For example, when we introduced object-oriented programming versus just imperative, you know, C, for example. Those were major shifts as well. But this is a fundamentally different shift for a handful of reasons. It's not making us incrementally more productive. It is making us significantly, potentially exponentially more productive in some ways. At least that's the big picture. The big picture is that what used to take hours could take minutes now. Sometimes less. And a lot of the kind of mundane problems in computer science, a lot of the simple problems in software engineering, software development are essentially gone. But nothing comes for free. Of course, you know, there's many costs in this picture. But I want to talk about a handful of the ones that are going to affect you in your day-to-day. Because I've talked to a lot of people who are working in the industry now. I'm working in the industry now. I'm observing this myself. While the large picture is exciting, there's a lot of energy. There's a lot of excitement. There's a lot of energy. There's a lot of energy. There's a lot of energy. There's a lot of energy. There's a lot of possibility. There's a lot of people are building tools every single day. New things are coming on the market. New announcements are being made. If you search forums, people are creating agent management systems overnight. And this huge explosion of possibility, this newness, can give us the feeling that things are progressing. It gives us the feeling that things are getting better, that everyone around us is moving faster than us. It can give you the feeling that you're falling behind. It can give you the feeling of pure, unadulterated chaos. And this slide from exciting to chaotic can happen very quickly. Because for the average person, for the average engineer, you're not adopting even a percentile, even a tenth of a percentile of the tools and patterns and best practices that are emerging so quickly on the market now. You're adopting the things that you have to. You're adopting the things that you think are going to work well. If you're on the bleeding edge, maybe you are pushing forward something that's going to work well. Maybe you are setting an opinion. Maybe you are setting an opinion. But ultimately, the vast majority of what's happening around you is going to pass you by. And so because of all of this energy, we feel the need to respond with energy. We feel the need to respond with speed, with ultimately what we end up doing is multitasking, trying to adopt. We feel the need to respond with everything that we see that looks good. In the meantime, in our workplaces, we're also becoming increasingly chaotic and spinning up a new work tree, spinning up a new agent and working on a different ticket, while agent number one and agent number two and agent number three, agent number 56, they're all working on their own tickets. And now our job has become almost entirely some new form of context switching. This is going to have an impact on us. And really, the people who are going to survive and thrive through these changes, the people who are going to come out on the other side, helping define the best practices. They're the ones who are going to learn the core skills here, which are mostly about managing ourselves. We'll talk more about that after we talk about today's sponsor. Today's episode is sponsored by SERP API. No matter what you're building, SERP API is the web search API for your needs. If you're building an application that needs real-time search data, whether that's an AI agent like we've been talking about, an SEO tool, a price tracker, anything else that you have that needs to know what's happening on the web right now, SERP API is the web search API that handles it for you. You make an API call and you get back clean JSON. It's that simple. There are 50 or 60, they have a ton of APIs. It may even be up to 80 or something now. They're announcing new APIs all the time. So this is probably out of date by the time you hear it. They deal with the proxies, the captchas, the parsing, all the scraping. These are headaches that you don't want to think about with your live search APIs. They support dozens of search engines and platforms. They're fast and they've been doing this long enough that companies like NVIDIA, Adobe, and Shopify are already relying on them. There's a free tier to get started so you can build and test your application before you commit to anything. And by the way, if you're building with AI, SERP API has an official MCP. That's the official MCP. To make getting up and running a simple task. If your app needs to search the web in real time, check out SERP API. So we're talking about today, we're talking about this idea that our work is changing and that we have this big picture and really the, what we've been sold is the idea that everything in the pipeline is just going to move faster. The AI equals velocity. And at first glance, this makes some sense. There's a step in the process, the coding step, and maybe some ancillary steps, some testing, maybe a little bit of planning, maybe some architecture refactor. But overall, it's part of the software development workflow, the software development lifecycle, and some of the handoffs from other functions as well. So product or design or data modeling. There may be a business function that is using AI to increase their velocity, right? So there's many different types of steps that can improve, but the major improvement from a marketing standpoint has been, or from a market standpoint, has been that LLMs can learn how to code. And this is different than, you know, the kind of thing that you would get if an LLM was just focused on writing. Because writing on its own may be good for, you know, improving a business process workflow or improving product, but you have have to to to have to so, the might be might be increase the velocity of the upstream or increase the number of sources that we're getting our work from. And all of this could be true in some ways. Of course, if you increase the speed of the bottleneck, then the overall pipeline does get faster. This is important and it is true. But we need to look at the effects when you increase speed through a particular bottleneck. Because it's not as simple as everything else is equivalent and you're just getting faster code. That's not true. Because engineers are fundamentally changing what they do. And so our context shifts. Software engineering, if we're changing what we do, we introduce new workflow, we introduce new risk profiles, we introduce a new type of context switching and task overload. So if you are one of these people who is opening up multiple work trees and you're allowing all these parallel agents to work together, maybe they're going to coordinate some work together, maybe one agent is arguing with another agent about what is the best coding approach, and then you are the facilitator of all of these agents. And this is a fundamentally different thing than what most engineers are used to doing. Compare and contrast this to if you were only working with one agent at a time, which is still a valid workflow, by the way. There may be people listening to this right now and you said that that's your preferred workflow. And if that's the case, then there's still some things to consider. But largely, the effect that this revolutionary technology is having on our workflow is that we are trying to do more in the same amount of time. And usually we're trying to parallelize a lot of the work that we are responsible for in the same amount of time. So this means that we're context switching, but we're not just context switching in order to learn enough back about that context to reload that in our working memory in order to build something. We're reloading context, and then we're managing some other kind of building agent. So we're thinking about, okay, what is it that they have built? And how can I review what they've built? How can I validate that what they're building is in the right direction? And this is a, you know, multiple new types of skills. Are being practiced. So it makes sense for us to take a step back and think about what is fundamentally happening to the person in all of this. Because if you're increasing your context switching, then you're going to reduce your cognitive ability in any given individual context, any given interaction that you're having with one agent or review that you're performing. And so, you know, if you were to try to gain some kind of lesson from past events that are similar to this, most of this pattern looks like, it starts to shape up like managing, right? A kind of management flow. And in this sense, I mean more like a process management, like a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, management or a assembly line management. And we're using this only as a metaphor, not to say that, you know, code coming out is like on an assembly line that, that would defeat kind of the, the unique position that software has in our lives. But instead to think about ways of working as an emerging, you know, agent manager, right? If you're, if you're to think about what is your job from day to day, if you are considering yourself, an agent manager, then you start to think about what processes enable a management mindset, right? Rather than thinking about yourself as the software engineer, and you're employing an agent to do that work for you. And then you have to essentially sign off on everything they're doing. A agent manager, is going to look at, systems of management. So for example, anomaly detection or standardization of output and, you know, automatic validation of those standard outputs, right? So, so what this starts to look like is quality control checks, right? These are things that, you know, management chains for a very long time have developed these kinds of methods because it would be absurd for a manager, to go down to the line and look at every single item that comes out of, out of the, the assembly line, right? It would be, it would be incredibly expensive. And in fact, that's also not even true of the people doing quality control checking. They're in almost every case, unless the, the item going off of that line is incredibly large. In most cases, they're doing things like spot checks, right? And you've probably heard this language because it's long, long running. And it's something that we've adopted some of this in software engineering, but it's very likely that we're going to continue adopting more because a lot of the kind of ergonomics of managing agents will feel like managing machines and we're managing the machines output. So we're looking for, you know, these, these old school methods in some ways, right? Old school management methods to evaluate outputs, both quality and quantity. So, you know, we're trying to do a lot of the work upfront. So, you know, another emerging pattern here that you're going to see is that you're doing more of the work in the specification phase and in the planning phase. And you're trying to create guardrails early on, right? And you're doing a lot of this kind of upfront specification and context, context building and context shaping. These are all things that we're trying to do. And we're trying to do a lot of the work upfront. So, you know, we're trying to do a lot of the work upfront. These are all things that are, you know, you know, the terminology that if you're working with LLMs, then that means a lot more to you if you're paying close attention to that. But even if you're not working with LLMs, that all of these same language pieces, same, same kind of labels we could have used talking about, you know, a prototype manufacturing, setting the context, setting the guardrails, setting up the specification, you know, setting up the prompt, you know, the, the concept or the input, the request that we're building with. And so ultimately these are not new concepts, but they're new to this person. They're new to you as a software engineer. And if you just keep trying to treat this like a very smart autocomplete, if you just keep trying to treat this like a series of to manage your tickets for you that take a lot of the work out, but you still have to do mostly the same stuff. If you're still doing the same job, then you're going to burn out from enormous amounts of context switching. You're likely to see quality issues. You're likely to see your ability to focus on any one thing is going to be diminished, right? And so all of the things that we've learned before are still true. Limiting your own work in progress. So how can you do that when you have multiple agents running? You have to change the work itself. You have to change the nature of the work itself. And that's what I'm suggesting that you pay close attention to. All of the principles still hold. All of the principles of limiting work in progress are still true. And so all of the things that we've learned before are still true. Work in progress, focusing on finishing rather than starting, right? So if you have something that's in progress, finishing the thing that's in progress before you start something new. These are things that can reduce your cognitive burden. But that doesn't mean that you have to reduce the total amount of things that get done, right? Because we have new tooling, because we have a new context that we're working in, it means changing the way that you work, changing the work itself. What? Is your work in progress? That's the question that I'm going to send you home with. This is homework. What is my work in progress? Am I actually doing these tickets or am I managing processes that produce quality ticket work? The second is where you are likely going to trend if you're a successful engineer in this new paradigm. Thank you so much for listening to today's episode of Developer Tea. Thank you again to SERP API for sponsoring today's episode. If you're a developer, if your app needs search, if it needs to search the web in real time, then SERP API is your API. Go and check it out. SERPAPI.com. That's S-E-R-P-A-P-I.com. Thank you so much for listening to this. If you haven't subscribed in whatever podcasting app you're currently using, go and do that. If you haven't subscribed in YouTube, you can subscribe right now in YouTube. We're doing all of our, at least our monologue episodes. And eventually, if we do interview episodes, we're hoping to release those on YouTube as well. So go ahead and subscribe so you don't miss out on that. We release shorts sometimes that come from these episodes. So you can check those out there. And then finally, we're working on developing a new newsletter. All right. So go and check that out. It's called the Tea Break. It's on developertea.com. You can enter your email address directly on developertea.com. And when we release the Tea Break newsletter, when we start that, you will be the first in line to receive it. Thanks so much for listening. And until next time, enjoy your tea.