these might be some of the biggest changes in our industry's history and it's up to you to figure out what that means for your career no one else can do that for you and in today's episode we're going to talk about how the industry is changing how it's going to affect from a macro perspective most organizations and where do we fit in all of that as software engineers my name is jonathan cuttrell you're listening to developer t and my goal on the show is to help driven developers like you find clarity perspective and purpose in your careers we're talking about ai everyone is talking about ai and it's not because it's a buzzy topic it's because it is genuinely changing what we do it's changing how we perform our jobs but it's not just changing the practice of writing code of course it's not of course you know that this is changing much more than that but in today's episode i don't want to just talk about how much faster you can go or how cool agentic flows are or how likely it is for ai to produce a bug and we're not also not going to talk about the latest models or anything like that uh instead i want to talk about how we can change the practice of writing code some of the impact that this core capability shift uh you know first of all what is the capability shift and and from a business perspective and how does it change business how does it change most organizations and how they operate and what will it do to your to your role what will it do to your team to your uh to your career okay uh so we're going to talk about this bigger pattern um you know one one important driver for for what's going to happen organizationally as ai continues to make a huge impact on our world so i want to kind of go back in history um i was alive for this many of you may have been as well um the early days of uh of of personal computing and specifically i'm thinking of like windows 95 right uh in the mid 90s you would see windows 95 on a shelf and in fact you'd even see um you know aol hours on a disc on a shelf as well but uh thinking of of something like an operating system and if you just think about what that implies shipping software was in in many respects a very important part of the system and i think that's what's really important to us is to be able to use the internet to deliver data to us uh you know you can update that software you could release a patch for example but uh certainly not everyone even had the internet uh had access to the internet if they did they probably had very limited uh access to um to fast enough internet to download an entire os might take days uh patches with a lot of data might take days to deliver data to us so i think probably not necessarily auto download so you'd have to choose to uh to go and get the patch probably all right it was unlikely that it was like a call home or something and these early versions and uh you know so so for this reason iteration and you know iterating in public or iterating post delivery was not a simple task and so you can imagine that every bug fixed before delivery was the leagues uh cheaper was significantly cheaper to fix that bug than if it was uh if it was found post delivery and probably most bugs found post delivery never got fixed right because it was just the roi of even fixing that bug trying to distribute that software again uh was probably enormous uh in favor of not fixing in most cases right so maybe high severity bugs or something you could imagine but um you know it's unlikely that people even had this conceptual model at the time because they just bought a completed product and most of the time when you buy a completed product you expect it to work as it was intended and so the market at the time and the the! economics of software delivery at the time preferred a lot of testing and a lot of risk mitigation far more than what we have uh what we have had for many years right so you know front loading all the testing uh you know going above and beyond on on this test delivery because if you were to think about and the reason i compare this to the mars rover is because once the rovers are ready to go they're going to be able to do a lot of testing and they're going to be able to do a lot of things so that's why i wanted to make that point that once the mars rover is delivered sure you could send a patch but it's not easy in fact uh it may even be easier to patch the mars rover than it would be to patch windows 95 i don't know exactly what those numbers would net out to but they're certainly similar in terms of difficulty of dealing with you know issues after the fact right and so there's something about the shape of that delivery pattern or or you know the way the market was shaped, the way the underlying technology, what it enabled, what it restricted, some of the actual logistics that shaped the industry that changed the decision making for the pipeline of software delivery for companies like Windows in the mid 90s. All right, for companies like Microsoft, building Windows in the mid 90s. So, you know, of course, if you fast forward, even 10 years later, things had changed drastically. We were delivering software updates, you know, as often as daily. Websites, more broadly speaking, were constantly updated. Sometimes, you know, every load that you would load a website, you might get something different, right? And so software was no longer stuck. In the physical delivery realm, because access to the Internet, especially on personal computers, became essentially ubiquitous. We no longer have to worry with sending physical disks, you know, CDs, hard disks, floppies. Those don't have to go out. We can just send a patch and the person is going to update all their software. And in fact, you know, culturally speaking, we've gotten to the place where updates are. Most people have things set to automatically update now anyway. So whether you're talking about web application delivery, which people don't even explicitly have to say that they want to update, or native software, as a broad generalization, sending updates for that software is very, very simple. The actual update, you know, release process is fairly cheap. So. This changed the market. It changed the way that we think about delivering software. And specifically what it changed was there was less, you know, risk and less cost in shipping a bug. Right? If you think about what this really means, it means that bugs become cheaper. Okay? Bugs become cheaper. Now, you probably wouldn't phrase it. You might think, well, really all it means is that we can deliver software easier. Yes. But if bugs become cheaper, that means that the ROI of trying to eliminate all of the bugs early or before you release that ROI equation changes as well. Right? You know, and when I say bugs, I don't just mean, you know, bad software. It could also mean software. Software that the market doesn't like as much as you hope. Right? A feature that doesn't land well. That also becomes cheaper. The failure risk becomes cheaper because the delivery process of software, that particular part of the bottleneck, right? The pipeline of delivery, that particular bottleneck of getting the software onto our customers' computers, onto their machines, onto their devices. That bottleneck was lifted, essentially. Right? It's essentially gone. You know, maybe it still provides some friction in some cases, but drastically better than it was in the mid-90s delivering Windows. So, because the fundamental pipeline changed, the calculations changed. That means that a... That means that a intelligent business owner would change the way they make decisions. Where previously they would have invested in, you know, copious large numbers of QA engineers, for example. They may have invested in much longer timelines. They may have even invested in a lot more marketing for the release itself. Okay? Think about how all of those decisions, they shift. They shift, and now you can do soft releases. You can do beta releases. You can release partial features. You can release whatever you want to, almost whenever you want to, to whoever you want to. And so, all of the decisions around building up to a single large release, they change. Now, it doesn't mean that people don't benefit from doing a market push. That's not what I'm saying. It also doesn't mean that people don't benefit from having a QA team. I want to be clear that I'm not calling for... You know, the eradication of QA teams. And by the way, all of what was going to happen in this particular shift in the industry has essentially already happened. But this shift caused the decision-making frameworks to change. Now, I'm going to talk about the most recent shift and how it's going to change decision-making right after we talk about today's sports. This episode of Developer Tea is sponsored by Unblocked. Your coding agents have access to your code base and probably more. Maybe you've connected other tools via MCPs. Maybe you can push up to GitHub or something, and it can pull down changes and read that stuff. But it's not easy to keep up with all of those. And access doesn't just translate directly into context. Agents can't reason across MCPs very well. They don't know. They don't know. They don't know your architectural decisions, your team patterns, or why the API was shaped the way it is. So agents often look in the wrong place and end up delivering bad outputs based on bad assumptions. Then you spend time correcting, wasting time and tokens. Unblocked is the context layer your agents are missing. It synthesizes your PRs, your docs, your Slack messages, and your JIRA issues into organizational context that agents actually understand. So they make better. So you can use your PRs to make better plans, write higher quality code, use fewer tokens, and require fewer correction loops. If you're currently running Clogged Code, Cursor, or any other agentic workflow, Unblocked is worth a look. Get a free three-week trial at getunblocked.com. That's getunblocked.com. Thanks again to Unblocked for sponsoring today's episode of Developer Tea. Unblocked is the context layer your agents are missing. Unblocked is the context layer your agents are missing. Unblocked is the context layer your agents are missing. Unblocked is the context layer your agents are missing. Unblocked is the context layer your agents are missing. Unblocked is the context layer your agents are missing. Unblocked is the context layer your agents are missing. Unblocked is the context layer your agents are missing. Unblocked is the context layer your agents are missing. actually the cheap part, right? That it's easy to talk about ideas. It's cheap to talk about ideas. It's cheap to put them on, you know, a brainstorm board, but it's very expensive to actually execute and deliver and, you know, put all of that stuff into production. It's expensive to maintain that code. And so we want to do as little of that as necessary to continue to function as a business. The more code we have, the more liability we have. The more code we have to write, you know, generally speaking, the more expense we have in paying engineers to write that code. And the expense also comes in terms of risk. It comes in a lot of other factors as to why engineering would, generally speaking, would be considered a costly step in this process, right? And so, again, a lot of our processes were optimized for eliminating work as early as possible in the funnel so that it never hit engineers' plates in the first place, okay? It's unclear, and it kind of depends on your business and how you operate for your specific pipeline, whether engineering is still the bottleneck for you. It may not be. But it is less of a bottleneck, right? It is becoming less expensive to engage in engineering, at least in the early kind of evidence that we have. A lot of the things that previously may have taken significantly more time, the timelines are shorter. There's a lot of effects that would lead people to that conclusion, that engineering is less expensive. Okay. So as we release this bottleneck, what happens? What are businesses going to do? You might think, okay, well, it just means we're going to deliver more, right? And while that's kind of partially true, it's actually one part of it that we're going to talk about. It's not the main effect. The main effect in a well-oiled machine, a business that has kind of built its pipeline around the engineering bottleneck, is that the pipeline is going to... break in some way first. And usually what happens with bottlenecks, if you release a bottleneck, you find a new one, right? This is actually very typical. It's kind of like a long running, you know, if you read The Goal, for example, they talk about this specific pattern of once you release one bottleneck, you're going to then find a new bottleneck and then your problems will shift and change shape, right? And so... depending on how well, you know, sized all of your other functions are, when your engineering function suddenly increases capacity and throughput potential, then the rest of your bottlenecks or the next, you know, smallest bottleneck is going to become more visible. Now, this is especially important if your other bottlenecks are upstream of you, right? So in that funnel, if suddenly something above you in that funnel becomes slower than then the throughput that you have, then you're going to end up as an engineering team waiting, you're going to end up waiting on whatever is upstream. So the early effect here is most likely that teams are going to recognize that there's an upstream bottleneck. And also, the naive thought is that, that engineers should be delivering more. And so you're going to have engineers who are asking, what exactly are we supposed to be delivering here? Because the upstream of our funnel is not giving us anything to work on. It's unclear exactly what we're supposed to do with all this new firepower that we have, right? So that's an early effect that will happen. But eventually, that pipeline bottleneck will move and attention will move, and then the pipeline will get redesigned, right? So what will happen is, most likely, if it's upstream, engineers and other people upstream are going to change the way they work so that more can flow through. Now, what does this actually mean for delivery? It means that, very likely, those functions that were being served upstream to mitigate risk as much as possible, now we either have to figure out how to mitigate the same amount of risk faster, right, more throughput, or if we shift our thinking to avoid optimizing for the wrong things, in other words, if previously we were trying to mitigate risk because engineering is so expensive, now engineering is less expensive, then our previous assertion, that risk mitigation was important because engineering is expensive, is no longer valid, right? So now, do we still need to mitigate as much risk? What can we do? What might we change about our strategy? And very likely, most organizations, what's going to happen, you're already seeing this happen, by the way, most organizations are going to lessen the criticality of risk mitigation. Okay, what does that actually mean in practice? that are less likely to succeed. They're going to ship products that have a higher likelihood of a bug. And the reason for this is because the volume increase that they get by removing some of these more expensive new bottlenecks, by the way, more expensive risk mitigation strategies, that's how they're going to relieve that bottleneck. The volume increase is going to, in most cases, make up for, it's going to make up for the potential loss that you could see from a feature that was delivered that just kind of flopped. We should be very clear here and be very careful that there are some versions of this that end in bugs that are catastrophic, that might cause a huge data breach, for example, or loss. So if you're looking at a pipeline that's shaped in a different way now, we should be looking at that pipeline for a new type of risk. The risk profile changes, right? But it's not, it's unlikely that things will stay the same and suddenly engineering is just faster, right? If we are indeed looking at a pipeline that's shaped in a different way now, we should be looking at that pipeline for a new type of risk. So that's why we're looking at that pipeline. If we are indeed seeing things like 50% improvement or even 100% improvement on throughput for engineers, then it's likely that, you know, those, the things that kind of got shelved or fell below the line, the cut line in product, now those things are going to get a green light, right? The other potential here is that the pipeline will change entirely so that the only source, the only source point for work shifts to multiple source points. Most likely the person who is driving the agentic, you know, machine, whatever that is, is going to have more decision power. So this person may be able to make decisions on the fly to improve the quality of product in a way that is more responsive and iterative than going back to another human, right? And trying to improve it with that, you know, with that other human. This is, you know, one of the effects that you see in early startups where the person who's building the product is also the person who's making all the decisions about that product. And they're very in touch with, you know, what the product needs to be, or they're very in touch with the stakeholders. They're playing multiple roles. Well, there's little translation for, you know, moving from one phase to the next phase in product development. It's all kind of one effort. And we are likely going to see more of that, you know, we're going to see more of that kind of effort from software engineers who are using, who are given a little bit more latitude, right? Latitude to make decisions on the fly. You're probably going to see, you know, pair coding sessions, but it's going to be between a product manager, a designer, and an engineer. And the engineer is producing, prompting, or they are collectively prompting the machine and looking at outputs and, you know, driving things from that angle as well. So the big shift here is the pipeline though. And I think that's the important thing, the mental model for you to carry forward is what happens when this bottleneck shifts and how can I be ready for higher volume throughput, right? How can I kind of reacquaint or reconfigure my mindset to avoid believing that engineering is the most expensive step in the process. And now consider it, consider optimizing for something different than just risk mitigation. You know, we may be optimizing, for example, for decision speed, right? How quickly can we make decisions? If we consolidate the decision-making into fewer people, for example, that's very likely to be, you know, a much faster decision-making process. And you're probably going to deliver significantly more. And now your pipeline starts to, you know, start to be more efficient. It starts to get balanced again, right? You're able to make faster decisions upstream of engineering at that point. Overall, I think it's important for us to maintain our engineering mindset throughout all of this. Engineers think in systems. Engineers think in terms of how our changes affect the system, not just a single component, right? If you approach this new, kind of, we could call it a new era for software engineers, approach it with the mindset of an engineer. Coding is not what makes you an engineer. Reviewing code is not what makes you an engineer. You know, in the same way that punching cards didn't make people engineers, in the same way that knowing how to manage memory manually and garbage collect is not the one thing that makes you an engineer. Your way of approaching problems is what makes you an engineer. And I know this is a time when anxiety is high for all of us because our jobs are changing and with change comes anxiety. But I encourage you to take a step back and look at this like an engineer and then decide how you're going to engage with this. How you're going to engage. Thank you so much for listening to today's episode of Developer Tea. I hope you're encouraged by this. I hope you're challenged by it. I hope that you can go and talk to your product partners, talk to your teammates, talk about how this is changing your career and what to do about it. Don't just sit back and, you know, and let it all hit you. Be in the driver's seat and take control of the career that is only your to drive. Thanks so much for listening and until next time, enjoy your tea.