If you are a manager, this episode is made primarily for you. If you are a lead engineer, if you are in a senior role at all, then this is also for you, especially if you are growing in your career, if you want to continue to be held responsible, get more responsibility in your role. That really is the path of growth for an engineer. And I want to give you one simple bit of advice. This is kind of a throwback style episode of Developer Tea. And we're going to keep this very short today. I want to explore one idea with you. And the idea is especially pertinent for engineers right now who have heard in the past week, why can't this go faster? This is something that we've heard over and over and over in our careers. And that knob has been turned up even louder. And it probably has made a lot of engineers frustrated in the past, but even more so frustrated about the current environment. The, if you are a manager or let's say you're a product leader and you're listening to this, I want you to listen to this part very carefully because you are risking the culture of your engineering team if you are banging the doors down about going faster. And in particular, there is a this pattern keeps happening where some new capability is introduced into, you know, into the environment. So if we rewind many years ago, this capability might have been, you know, the Internet. Right. And so now we can deliver software over the Internet. We don't have to wait on, you know, DVDs to hit the shelves. Right. We don't have to physically deliver software. So now we should be able to deliver patches, you know, orders of magnitude faster. faster, right? Fast forward a little bit. And, you know, the explosion of the dot com era meant that a lot more, you know, frameworks were popping up web frameworks. And so now the these frameworks should make building web applications easy, right? We should be able to, to easily, you know, design CSS, it makes designing websites a lot easier. And so we should be able to move a lot faster. And on principle, a lot of these things are true. And you guessed it, you know, in today's episode, like every episode we've been doing recently, we're going to talk a little bit about AI and agentic coding, making things a lot faster. All right. And on fundamentals, on principle, this is true. This is true. Whether you have, have, you know, jumped on this bandwagon or whether you're riding the wave or not, there's an observable reality here that a lot of tasks that previously had to be done manually by hand, whatever, no longer have to be done that way. And so certain aspects of of software engineering are a lot cheaper, a lot faster. However you want to phrase that, it's gotten a lot more efficient. And so if you're a product leader, then you're translating this into, well, why aren't we moving faster, right? Why aren't we actually moving faster with these new tools? And it's a reasonable question. If you're a software engineer right now and you're tired of this question, I want you to take a moment to recognize the reasonability of the the question, right? It may feel naive to you, right? And you may end up wanting to push against AI as a result of this. AI is just causing people to have fever dreams about how fast engineers can really go, but actually it's not making us that much faster because, and this is the point of this episode, I want you to pay close attention to what happens, what comes after because. Because pay close attention to the friction. The friction. Not the speed. Not the energy. Not the effort. Not the push, the dedication, the motivation. All of this upfront energy. I want you to pay attention to the friction. What keeps these things from naturally moving faster when there is a fast component introduced in the pipe? This is the critical thing that most people are forgetting. So, again, we keep talking about the theory of constraints in this podcast. And it's really because this is the fundamental model to understand. We have to understand how work flows through a team, how it flows through an organization. The full software development lifecycle is the work of a good manager, of a good lead. If you don't get your software development lifecycle right, then you are creating bottlenecks and then you're asking, why can't we move faster? And the answer is because you're not paying attention to the right bottleneck. And this is universal. This is very, very rarely on the show will I say there's a universal truth, but this is a universal reality. When you have something that goes through anything that looks like a pipeline, there will be a bottleneck. And if you don't pay attention to the bottleneck, it doesn't matter how fast anything else in that pipeline is. Anything else in the pipeline. line. And critically, there are usually, right now, there's usually essentially two parts of this pipe that are bottlenecked, right? For teams that are essentially like fully onboarded and fully adopting agentic coding, okay? And so we're kind of flattening out some of the problems like asymmetric adoption, right? If you have some team members who are adopting fully and other team members who are not, then you can have a very wide gap in how long a specific step in this process takes, okay? And really all that's doing is it is creating more distraction for the real bottleneck. So let's assume, let's assume that everybody Everybody is developing essentially at the same kind of throughput, which has increased in certain dimensions. And those dimensions especially are in the execution of requirements, right? The actual coding, taking some requirement, turning it into functional code, testing or writing tests for that code. and um so so the literal coding step right so the bottlenecks tend to be showing up in essentially two places one is in the beginning so like uh in in the requirements gathering phase right this is usually because either the requirements can't keep up with the appetite of uh uh you know of of the agent building portion, right? So we have this bottleneck of stuff that's idle engineers, right? Waiting for something to be handed to them. But then once something does get handed to them, then especially if it was rushed, which can happen because of the bottleneck, right? We wanna try to get things out. We wanna try to move quickly. And so fewer requirements, We hand something off that's not super well defined and the engineers take it, they build and they end up having to go through multiple phases of build. But then we hit another bottleneck. Partially because, often, because that requirement step was not sufficient for this new environment. It may have been sufficient for a human engineering process where engineers are very close to what's happening. They could fill in the gaps themselves. They could collect requirements themselves. Now, because agents are filling in those gaps, if there is a gap, sometimes that gap gets filled in incorrectly. And so if our requirements are not incredibly detailed, tailed, if we're not doing enough in that planning phase, which again can happen because we're trying to rush it because there's a bottleneck there, then we create a new bottleneck downstream. The new bottleneck is kind of two parts. One is verification, validation, review, so testing. These are things that once you've built the thing, you want to make sure that it's actually doing what you expected it to do, right? And so there's a lot of different opinions on this. Should we read every line of code that an agent writes? Or should we have some kind of validation system that will help us validate that code without reading every line? I'll leave that as an exercise for you to decide for your particular use case. Importantly though, if we're having to go through and we're finding these problems that are a part of the original spec, and the requirements gathering, then we end up kicking this back. And we kind of go back through some of those original phase issues. So that creates a bottleneck for those two reasons. One, because it's hard to verify things sometimes. It's hard to validate that our code is doing what we expected it to do, that it's not dangerous, it's not going to break something else, right? This has helped, go back to the last episode, this has helped by engineering fundamentals being right. So engineering fundamentals being right, meaning you have sufficient test cases. You're actually running, you're using clear testing to drive your code and to drive whether your code is doing what you expected it to do. If you're not doing that, then what is your process? Maybe it's manual testing. Well, when we have a much higher throughput, the manual testing, the burden of manual testing goes up, goes through the roof. proof, right? So we're now we're spending a lot more time. This is where the bottleneck comes from validating, verifying, testing, manual testing, QA, whatever you want to call that step, looking at the thing that the agent built to make sure it's good. And so this is where the bottleneck is. And this, this is the friction that I'm talking about. There's just kind of two places, right? Two places where the friction is. First, if you're experiencing these two in a GenTech workflow, then focus on solving the first upstream one, right? Solve that first, which is make sure your requirements are very detailed. Spend more time in that planning phase. Spend more time getting specific about what you actually want the outcome to be. Provide more direction, more detail. Secondly, if you're going to be building on top of something and all of the spec is only so good to be built on top of a pile, right? If you're kind of globbing things on from left and right, then it's harder for the agent to be able to read and interpolate, okay, this pattern that they're talking about using the requirements, we're going to adapt it to the existing standards. standards. We're going to adapt it to the existing code base. And so what ends up happening is agents often end up writing a lot of extra code. They end up creating models or entities or whatever that they don't necessarily need to create. They overload endpoints or create new endpoints where they didn't necessarily need to. They could have, if your system was designed with a little bit more principle in mind, then perhaps it would have been able to discover that little bit better, right? So there's kind of three points to fix this problem because all of those things I just talked about make that review and validation even harder, right? So if we start with very good requirements, then very good requirements can easily translate into very good tests, right? We can kind of see how the beginning and the end are directly connected to each other. We we write acceptance criteria over here, somewhere in the middle, we make changes in order to meet that acceptance criteria. Then we validate on the other bookend that we actually did it. The acceptance criteria is being met, right? So we should look at these bookends as essentially directly connected to each other that we have a validation workflow is kind of the closing out of the specification workflow. You specify, agent handles the specification, actually goes and builds the thing, and then we validate, right? So if we're not tying those things together, if we have poor specification, we should expect to have poor validation. We should have, if we have poor specification sitting on top of a poor structure, we should expect to have poor execution. And so if you are facing, if you're asked this question, It's going faster. These are the components that you want to look at, right? How good is the specification? How good is the structure? How good are the principles of the design architecture such that when we build on top of it we are following some kind of principle, right? There's a design pattern here that we're following or there's some structure that is dependable that's reliable that if you were to tell the agent go follow the way this is already being built conventions, et cetera, and it can say, oh yeah, I can, you know, the agent can go investigate and actually do that rather than saying, well, I don't see anything necessarily structured here. So I'm just going to kind of put something on top and hope that it works. If you were to think about how a human would do this, how does a human recognize how to work in a code base? If you can do that, right? If you can, if you can align your code base so that a new onboarding engineer could very easily go in and say, there's a convention here. In order to add a new endpoint, I need to add da-da-da-da, right? There are ways to organize your code base, to provide documentation in your cloud.md or in your agents.md. There's all of these kind of hooks and opportunity to make that environment or the basis for the building more reliable. All right, so these are the surfaces. So you have requirements gathering, you have the basis for building, right? The foundation that you're building on top of, and then you have your validation. Something in those three things, something in those three things is what's causing friction. I guarantee you. And somewhere in there is a bottleneck. Something in those three things is causing friction is a bottleneck, right? Right. So a good setup, a good setup has good requirements. It develops on top of a foundation where those requirements can be translated into, okay, there's patterns here. Maybe the pattern doesn't exist and we can talk about designing a new thing, but if it already does exist, then we can fit it in. Right. And therefore, if there's good testing of the existing foundation, then then extending that testing beyond that foundation into the next phase to validate these requirements should be totally possible, right? So if you are experiencing friction, look in those three places. I would love to hear from you if you find some other place, right? If you're recognizing, and by the way, you may come back to me and say, well, actually, it's because our scope is creeping more because we don't have X, Y, and Z. Most, you can fit a lot of what you, the, the, um, uh, if you were to have an objection to this scope creep would be, in my opinion, that would fit in the, uh, uh, in the requirements gathering part of this, right? That, okay, we actually, we didn't gather requirements well, because there's more scope that we, uh, we're not able to capture in that, right? Right. That the the idea that, oh, we don't have the talent that we need. This is likely the the foundation problem. Right. Because the talent that you need, what do they generate? What are they responsible for? They're not necessarily responsible for writing the code. They're responsible for cultivating the foundation. And this is really the job of the engineer now is to understand the foundation and make sure that the code that's being generated is contributing to is extending on. is enriching the foundation so that the new things that are built on top of it don't topple over, okay? And the validation, of course, has its own long set of potential disagreements that you could have. I'd love to hear them. Send them to me. Send them to me. You can email me at developertea at gmail.com. Come join the Developer Tea Discord community, developertea.com slash discord. Thank you so much for listening to this episode. Hopefully this was, hopefully enjoyed this kind of throwback version of Developer Tea, a shorter episode, more focused on this one concept of, you know, velocity or agentic velocity. This is something that we're hearing over and over and over and over. Hopefully you can see how this ties back to, you know, this is not a new problem. We're looking at a piece of tech and asking, okay, why isn't this thing making us go faster? It's because it's not a new problem. existing problem. We've looked at this over and over again in the past. Now it's time to apply those same principles to our current environment. Thank you so much for listening. Until next time, enjoy your tea.