Faster Code, Slower Delivery: The AI Productivity Trap의 전체 녹취록

centered around a lot of the rational stack way back in the day. And obviously Derek, that's how you and I had gotten connected up from our time at IBM. And I've really kind of seen that grow across the likes of being in rational, in WebSphere, moving to Microsoft and being part of the platform evangelism, two tours of duty. AWS, time at GitHub, time at digital AI, kind of working through the capacities. And I think the reason that I've always enjoyed this space is no matter what we're talking about, whether it's any of the different frontiers we've seen from internet, cloud, mobile, AI, no matter what it is, it really does start and end with the developer. And being able to kind of live within that context. There are always going to be and always have been suites of technologies to get used that constantly evolve. There's always different platforms and different endpoints and things that we use that obviously also evolve. And the developers at the intersection of that, right? How are we providing the best sets of technologies that actually enable teams to go faster? teams to fix things more quickly and really take advantage of these technology revolutions. And in my current capacity being back at AWS, what I've been working with is really working with the largest financial institutions, helping set the strategy for We've grown up with a lot of these tools. We have lots and lots of developers, sometimes as many as 60,000 across the estate, and we use every tool under the sun. And foundationally and fundamentally, the better I can be at kind of harnessing the information that's coming from them. building in consolidation and using that as a foundational way that we're going to deliver the kind of value investments that we see in the likes of cloud, in AI, in whatever next future trend will be. My capacity is to help those customers really set their charter over a three to five year span to get better at that domain function so that when they are making these large, large scale investments in these future leaning technologies, they're able to take advantage of it. the most value-based way. Derek: Yeah, no small endeavor, that's for sure. And endless complexity that we'll get into. ⁓ We're going to spend a bunch of time, Eric, talking through kind of where we're at today and where we're going. But one of the things I've always found is like, you got to know where you've been to know where you're going to go. And to kind of unpack a little bit of our history together or our similar time in the industry, we've been lucky enough to kind of, in my opinion, see really four waves of the way that software is built and delivered, right? The first, I probably caught, I'm gonna think I'm a little older than you, I caught a little bit more of this than you did, but was the age of sort of procedural, co-located teams, the internet wasn't obvious, printing software, you know, on CDs and DVDs, that gave way as the internet became more obvious to what we describe

as wave two, which was really around web object oriented and actually, Eric Baran: Sure. Derek: the web as a distribution mechanism for software, which enabled agile, right? I think we all would have liked to be agile before the internet. It just wasn't physically possible to get the bits to move around ⁓ in an efficient way. The third way, which we really, think in a big, big way, kind of the majority of our ⁓ careers in, which is really around scaling agile, going to mobile, going to cloud, going to SaaS, modern DevOps. Eric Baran: Sure. Sure. Derek: And then Now we're in the earliest days of what Agentic or based software development and delivery looks like, or what we call wave four. Let's go back though to like late nineties, early two thousands. know, we, ⁓ we of the beginnings of this agile revolution. would argue 25 years later, we're still on some level of an agile revolution. ⁓ and in some ways AI is, is, is again, kind of reinventing that, but talk to me like your view on the customers that have been forward leaning in past waves. Eric Baran: Totally agree. Derek: how that helps them be set up for success in the next wave. Eric Baran: Yeah, absolutely. You know, it's been one of the kind of hearts. of where I've really engaged teams is helping what you described as, we've got this practice where I want to start creating chunks and bite-sized capabilities of delivery out to the workload. At the end of the day, like at its absolute simplest form, probably not saying anything, the audience doesn't know, but that's what agile really did. Right. To your point. And, and what, started to emerge in that vector was, well, how do I keep up? Because the structuring of once I get that new set of code. is still dependent on a lot of legacy process. I need to have the infrastructure created. I need to have the environments tested, integration testing done. I need to make sure that we have built, secured, and governed the process. And then once all that is ready to go, now I can move that out to prod. And I know you saw this for a while, Derek, a lot of teams, even today, we'll say we have a strong DevOps practice or we have a strong agile methodology that we follow. But if it's still taking me six to nine months to get those features out into production, don't, I'm following a waterfall-based methodology. It doesn't matter. what the underpinning of technology is. And I think that where I've spent a lot of time helping teams is over the course of the last 10 years with the rise of cloud, cloud made it easier for teams to start encapsulating a lot of that stack, whether it's the infra, the configuration of the application, the way that we're kind of governing security and testing and integration, policy enforcement, et cetera. We were able to start to bake that into repeatable sets of patterns or Lego books that could be used and consumed. And at the end of the day, in its simplest form, making sure that we eliminated the problem that built on my desktop and it broke when I handed it to the ops team, right, was like the critical thing that that really saw for us when we look at the DevOps pipeline. So where I've engaged a lot with clients, especially over the course of the last four to five years, has been DevOps isn't going away and cloud isn't going away. But we've built a lot of different capabilities across the CI estate, the source control mechanisms, the delivery mechanisms. And a lot of times that gets wired into the individual 10 person, 12 person development team working on their piece and trying to bubble that up and build the body of evidence, the supply chain, the artifacts of what went into that in the way that these teams have grown up with a lot of different point solutions, especially in the large regulated customers that I operate with is a really hard problem to solve, right? And we've done a lot of really good work in trying to help use different techniques to start to bundle and be able to actually aggregate the data, the information of what's coming from each of those sprints so we can keep up with what Agile really tried to do in the first place, which was I've built something over three weeks. I want to get it into production. ⁓ I think one of the things that has been even more fascinating in that vein, especially coming in and working with the large financials, is these were kind of the last sets of communities to really move to cloud, right? Like we had, they were definitely starting to kind of go down the path. Five years ago, we started to see dabbling, but it really was in the last four that we saw, not an if, but a when and how quickly can we get there, right? How do we really take advantage of the economy's scale that this provides. But a lot of the way that they had been building software throughout the last few years, really 10 years, didn't really kind of marry up to the way that cloud was going to need to be introduced. So a lot of the work that we've done is to help streamline that process. If I'm driving a migration using a development platform that's tied to a set of sprints that will then get delivered into that workload, I want to start to create repeatability and shareability in what we did to migrate that first work. workload and proliferate that among other teams. And the developer platform becomes a phenomenal facility to do that. I think the other thing that we've seen now with the rise of AI is I can't go into a customer today that isn't experimenting with at least two to three of the agentic capabilities that I'm sure we're going to get into at some point, whether it's a new IDE or agentic IDE capability, a prompt platform, or even agents that are doing the role of a junior developer or platform engineer. Right? And what we see now is how, we were trying to build the foundational estate to keep up with the cloud motion, now we've put all these resources into the Agentic capabilities for developers to get them more productive. But just like we

did with Agile, ⁓ the measurement of productivity is how fast we're building features for developer, that's great. But if I can't get them out into production, Did we actually make anybody more productive? And that's been a really, really interesting paradigm that's actually surfacing itself because a lot of customers I work with still need a lot of ⁓ work to try to really get the pipeline of the DevOps practice intact to take advantage of this AI capability. Derek: Totally. Totally. And look, we're going to get into this. I think this is for us, particularly for us in the enterprise. This is area where I feel like a lot of the thought leadership and a lot of the media and other things around the topic of AI or agentics, software development and delivery, they're melding together what are two wildly different situations. One situation is if you and I go start ⁓ new company, we have no source code, we have no governance, we have no customers. Of course, our biggest bottleneck is writing code. Eric Baran: Yep. Yep. Yeah. Derek: Right? Because there is no code. Whereas as I'm sure you share the similar experiences I do, when I meet with CIOs and CTOs in large scale banks, insurance companies, transportation, et cetera, often they're trying to reduce the amount of code they have, not increase. And to your point, a lot of the real bottlenecks end up being upstream and downstream from the task of coding. And again, that's not a knock on coding agents. think clearly Eric Baran: That's right. That's exactly right. Yeah. Derek: just as I don't use VI to write code and, you know, and Gang of Four pattern books anymore. I use a modern IDE and code assist and whatnot, you know, during the nineties and early two thousands. Now, of course, I'm going to use an AI agent for another level of abstraction to be able to write code more efficiently and effectively and hopefully with higher quality. ⁓ But boy, in the big enterprises, that's just one piece of a much more complicated end to end process. Eric Baran: Yep. Sure. ⁓ fully agree. And think that that's been one of the biggest where a lot of these customers starting to dramatically engage, right? I've got this legacy estate that I need to figure out what I'm gonna do to evolve it. How do I apply that discipline? Yep. Derek: Yeah, well, and unpack that a little bit because that was where one of my questions was going to go, which is, ⁓ I assume that ⁓ you will align to this or agree to this. Like sometimes there are technology waves that frankly, late movers have an advantage. In other words, folks, let's say in this example, ⁓ if you were, ⁓ there are some situations where like, hey, I didn't ever get DevOps really automated. It's still a lot of manual processes and a new technology comes along. You leapfrog and in fact, those folks can go from kind of way in the back of the pack to the front of the pack. What we are seeing is those that had been the most forward around automating that last pull request to production around putting built-in governance, built-in compliance. They ironically are both at the head of the pack for DevOps and they are also at the head of the pack for this next wave because they've invested and they can actually go faster, not just write more code, but deliver more value. Eric Baran: Sure. Fully agree. And I think that's kind of the heart of what we're getting at, right? I have had many, conversations with customers, especially over the last six months, when we've seen a lot of the rollout of these agents and capabilities to the developers go back to that fundamental bottleneck that you just described. It's, I am getting as much as a 7X amount of speed and velocity on my feature burn down. right, or my work item burn down in terms of what I can write, in terms of how I can author user acceptance testing, different types of testing, integration tests, functional, security, whatever it is. If I scan it, go put an agent towards the backlog and help me with all my vulnerabilities from a security standpoint. Like all that is happening. But the fundamental problem still exists that if I didn't have a way to get better, at really moving that logic out into production, right? And enforcing governance, policy, how that actually was mapped and packaged up. That's the critical bottleneck. And that is where we still see three, six, nine month delays, no matter how productive the developers have been. And it gets into a conceptual discussion for a lot of the CIOs and CTOs that I discuss is how do we actually measure developer productivity in the first place? Because it's wildly different in the way that we've kind of grown up in segmentation from a development audience versus an ops versus a security audience. Derek: Totally, yeah. I think that's absolutely spot on. And I think it is just this other reminder, particularly in these larger, more complex environments, that ⁓ this is a orchestration of many, many different tasks together. And okay, maybe at some point we have this utopia world where all of the agents are working together harmoniously and it's just all happening. But the reality is right now, there's human in the loop in a lot of those areas and really like... Eric Baran: Yeah. Derek: you know, 50, 60 years ago, operational management, ⁓ kind of textbooks, you find the bottleneck, you address the bottleneck, you don't fix parts of the process that aren't yet the bottleneck. I think early days here, sometimes we've applied the new technology to areas that may or may not be the bottleneck. And, thus we're, sort of surprised, but, shouldn't be surprised that the, the ultimate system didn't get any better, right? We just got better at a sub process, right? So, so why don't we like good, good chance here to. Eric Baran: 100%. Sure. Of Okay. Derek: to break this down a little bit, right? Let's just think about it super simply. Obviously there's a long list of things from idea all the way to production, right? There's planning and

there's probably even you can go back and say there's portfolio level planning, there's team planning, there's coding, there's CI, CD, like testing, security, like all of that ongoing that's not even getting into the production world that I know you guys live a lot in. Eric Baran: Let's do it. Yeah. Derek: Let's just break it down though into things that happened before coding and things that happened after coding. Like let's just simplify that process. ⁓ clearly, and I'm just level. you like for us, what we've seen the overwhelming majority of the adoption early on was at the coding task. Did you, have you guys seen the exact same thing? Yeah. Eric Baran: 100%. Right. As a matter of fact, not only is that where it's started, it's still where it lives in a lot of the areas, right? Because, Hey, I've got this really interesting new agentic IDE that just came out, or I've got a team that very much wants to use X application, or I've got a model that I want to deploy and I want to just be able to give that agentic capability to whatever IDE that the developers want to choose or use. Right. ⁓ Derek: Yes, yes. Eric Baran: That's exactly what we're seeing on a daily basis right now. Yeah. Derek: And I would say in that space, a couple of reasons for it, maybe one, that's where the earliest products came, right? Engineers building for engineers. And so that makes a ton of sense. You highlighted another one. This is a group that has historically had a little bit more latitude to kind of change up IDEs. It's not uncommon to go into a large scale enterprise and you've got some people that are super fans of IDE number one and other people that are super fans of IDE number two. Like typically there's been a little bit of choice, no different than... Eric Baran: Of Derek: You can have a Mac or a PC, right? Like, like there's been a little bit of a choice for that audience. ⁓ but, but also they just tend to be early adopters as well. Right. So like, those are like three, like check, check, check. When you start to then think about the bottleneck downstream, let's start downstream. That's probably where you and I have spent most of our time. We'll talk about the upstream one, but where are you starting to see the next generation adoption from like last pull request to all the things that need to get into production when it comes to. Eric Baran: Of course. Derek: maybe particular succinct agents or even maybe a handful of agents tied together. What's there? think QA is the one that I think typically comes up. But like, what are you seeing in production? Eric Baran: Sure. For sure. Yeah, you know what's been fascinating? I think I'll segment it out and maybe even take a step back before this whole notion of AI was kind of in the mix of all this, right? Again, because remember, it's only been 18 months really that we started seeing this uptick, right? ⁓ When we used to consult and do a lot of work with the different kind of banking customers, there were two fronts, right? We used to kind of talk about Derek: Yeah. Yeah, do it. Do it. Yeah. Eric Baran: Being able to consolidate source control is one of the core fundamental things we need to think about, because I need to have consistency where teams are able to share assets, right? And then what really came and bred out of that was, I got a lot of Jenkins pipelines out there that service those things, right? So how do we start to make sense of that? And some customers would... after they kind of started really getting into the source control fabric, really would start to reimagine what does CI look like for us. That was happening. But one of the lifts that I used to describe for folks, and I had a really, really ⁓ interesting CTO explain this to me, the thought of really consolidating those. before we had some magenta capabilities, but the thought of really trying to consolidate and come away from that would be analogous to going, you know what? We're rebuilding the highway infrastructure into New York and we're gonna shut all traffic down, like 100 % for the next two years. Right, that's right. Or we're gonna reformulate the subway system and it's like, you could do that, but that's non-starter, right? Because if you don't do it that way, it's gonna take us... Derek: We'll let you know when it's done. ⁓ Yeah. Eric Baran: hundreds of billions of dollars over a 15 year period, right? So, but realistically, these things became such the lifeblood of how different applications were built, utilized, released in the environments for developers that it was just, it's too mission critical. So one of the paradigms that we, and I wanna give some credit to a couple CIOs, CTOs, there were times where that was a legitimate thing that they wanted to go undertake, but the population was actually smaller there, especially when it came to the CI pipeline. I think the thing that really took off was this concept of how do I start building orchestration into what's coming from those pipelines, right? So. When I harden in across the CI execution for all the testing, the scanning, the things that I need to do at the developer level, and as I'm bringing those things together, if I go back to that analogy of I might be using lots of different tools all the way down to the 10 person team, well that 10 person team might be part of a 2,000 person team building a really large, multi-dependent application. What customers started to do was how do I actually orchestrate bringing that information together, we might call it the release process, to be able to aggregate what is my bill of material, what is my supply chain, right? Because the better I could be at packaging that data, given that it was really hard to extract all the way at those individual team levels, the better I could be at feeding that out once I did release things out to the production environments. to be able to have more contextual awareness for the observability teams to say, this is what was built, this is what

the auditor signed off on, this shows that we're protected, but if you find a problem, this will help you more with root cause remediation, right? And we really did see it on those two fronts over the last kind of four to five years. That's where a lot of the teams focused. So now we, and they're on that journey for the record, like that's something that's being done. What has been fascinating and what I think a lot of folks are not talking about as much in the practical application of what these agentic services provide, right, are instead of thinking I might have to shut down all of the traffic into New York, right, what if I could recreate a replicable environment of the city of New York and then I can actually start to simulate or showcase using these agents, how can I consolidate my pipeline strategy? Derek: A digital twin, if you will, right? Like you see in manufacturing. Yeah, yeah, sure. Eric Baran: Literally, and then schematically be able to feed that in and go, this is exactly how you want to reformulate this, right? That's been a huge area where we've really seen uptick. Obviously the testing function, right? Testing to be able to keep up to ensure we're authoring new code is actually covered, but also. The things that are happening as we're going through that process and we start flagging issues, and I like to pick on security testing in this vein, because there's a huge backlog of information. And we used to talk a lot about different types of SAS and DAS and dependency scanners and composition analysis around how are we taking that information and then doing something with it or figuring out, for a while it was just, tell me what actually is real and what's not, right? Now it's, now it's. do that, but then let's go focus on how we help eliminate tech debt, right? ⁓ That's been a critical aspect. And then if I go to the kind of bundled package on the supply chain, bill of material side that we can feed into the observability layer, many of these shops grew up with lots and lots of different systems and observability and monitoring tools across each layer of the stack, whether it's the seam, log analytics, infra, ⁓ etc. from a monitoring perspective and being able to start to consolidate that information to action what we're finding at runtime and being able to prioritize that. That life cycle is where we are seeing massive application. and promise of what AI will bring to those different domains. Because at the end of the day, if we go back to the fundamental thing we're trying to do to drive productivity, developer productivity is not some metric that said I wrote my sprint, ⁓ I built my work items in a week instead of the three weeks. It's we were able to do that and we got them out to production and we're able to do them in a more highly governed, compliant way. Derek: What's so interesting about that, is, mean, one side of this is like, it will be interesting in the coming months and years on even this term developer productivity. Like it comes in and out of vogue. I'm not sure I ever really fully understood even as a developer what it meant. ⁓ Everybody has a little bit of a different definition. And as we, and we'll get into this, like as, as ⁓ even the definition of what a developer is begins to evolve. I think there's a bunch of things that we can, we can take another look. Eric Baran: Yeah. Right. Yeah. Yeah. Derek: One of the things I just piggyback, because we're seeing very similar, and I actually think one of the things that's most interesting about you and I have sort of chosen to spend a huge amount of our career in the most complicated, most ⁓ complex, the organizations that frankly have what I like to refer to as like the deepest software archeology, right? You dig down through levels of dirt and you find different ⁓ dinosaur types from different ages, right? In terms of, you know, there's, yeah, web and mobile, but like, Eric Baran: Of course. Right. Derek: there was, there's 40, 50 years of, of, of decisions that were made by people that no longer work at that company, but the mainframe is still there. And, and, and, and, and, look, AI has a bunch of really interesting ⁓ applications there around, you're bridging the cobalt gap, you know, skills gap and some other stuff. but one of the things that we definitely are seeing is in the complex enterprise, it is relatively easy to envision the future, right? Use your, your, your highway or, or, or subway. Like we could sit down and say, here's how I want it to work. Eric Baran: 100 % 100 % yeah Derek: But the distance between where you are today and that, not just big organizational change, but also where the tech is at right now, right? Like it's not all the way there for these more complicated use cases. One these, I remember from early DevOps is like the holy grail was get from ⁓ all manual to completely continuous delivery. And quite candidly, very few enterprises got all the way to continuous delivery. But it was a, ⁓ yes. Eric Baran: Yeah. Right? Even the ones that say they do, yeah, are not. Yeah, right. Yeah. Derek: ⁓ there, the, and, know, and this popped up really dramatically during COVID when it was like, ⁓ wait, normally there's a person that goes and hit does this and they're not at the office anymore. So like, how do we do this? But, but we've been therefore orchestrating humans and for all intents and purposes, API calls the applications. Right? So like, to your point, like go call this DAS product, go call this SAS product. What we're seeing is not a, a necessarily wholesale, like throw all the DevOps away and start over. What we're seeing rather is human. Eric Baran: Fully. Derek: API, traditional API calls and MCP calls out to agents that are going to be doing more kind of broader autonomous workloads. So instead of passing variables to an API call, we're passing prompts and getting, and getting responses back. And, and it does feel like it will evolve, but you know, we certainly

could be sitting here three or four years made huge progress, delivered way more velocity with, with ⁓ maybe less ⁓ But There's still human task and there's still some API calls and there's a whole bunch of MCP. Eric Baran: Fully. Yeah, fully. And not only do I agree with that, I think that we are on the frontier of a fundamental shift in not just, like we need to be talking explicitly about. not just foundationally building the platform to help velocity, help accelerate, help curation, but we need to be building and thinking about the platform where this fleet of digital workers, right, is actually orchestrated by our humans that are out there. And I think that orchestration is probably the best way to describe this because those AI engineers, whether it's anything from a prompt engineering tool, all the way to the agent that's my DevOps team, right? That's doing all this stuff. There's a fundamental shift in the industry right now where there's a massive gain that that gives us. Not just beyond the efficiency, but it actually helps the teams that are in place from a development perspective really focus on the most high value critical features, new routes to market, new lines of business that they can use software to power. And what has happened, is a lot of that work. When I talk about platform engineering or DevOps, a lot of that work historically has fallen on the developers, right? Like they're the ones that have to go build that stuff. And if we talk about different tooling environments getting used, you add the complexity of writing infrastructure logic, policy logic. I mean, this is literally why we have environment drift deviations from things, right? And I think the other thing we're seeing that this really Derek: Yeah. Yeah. Yeah. Eric Baran: apply for all of us is that is that is a massive area where AI can eliminate that problem like fully right anyway Derek: Totally right. Yeah, totally right. And so maybe let's dig into that area a little bit, right? Because it's interesting, if I think about the last few years, we went from like, early on, we were using our coding copilots, ⁓ typically prompted ⁓ ultimately by one of our developers. Early home run use cases were around refactoring, around, certainly we had a ton of... Eric Baran: Yeah. you Derek: success around, we got to do this migration from this version of a, know, infrastructure we're using to this other one. It's world-class. was world-class at that for some time. More and more now tech debt, more and more now bug fixes, more and more now, ⁓ new development. But, but clearly we go from like prompt engineering, like what kind of a developer to a prompt engineer or a prompt. Now we go to a developer, a developer to any N number of agents that are working on that developer behalf. Eric Baran: Yeah. Yeah. Derek: You know, I think it makes people a little bit nervous, but then I'm always reminded you go back and look at a picture of somebody working in an office in the 80s and like there's no computer on the desk. There's like a phone. So like we all figure out how to evolve in this world. And, and so now it's like, okay, we all have multiple computers, big screen monitors, and we got a bunch of agents that can do work for us ⁓ at our, at our ⁓ request. ⁓ How are you seeing that? Like literally the adoption of agents that are running autonomously, even if it's for Eric Baran: 100%, yeah. Yep. Yeah. Derek: for like subsets of the work in your most forward leaning enterprises and for you that's enterprises that happen to be in almost universally highly regulated industries. Like what's the state of the art in actuality right now? Eric Baran: Yeah, you know what, it's been, it's been, I've had a good fortune of working, especially over the last 18 months with all of the major model providers, whether it's Anthropic, whether it's OpenAI, XAI, some of the more boutiquey ones that are kind of trying to go curate and build very specific use cases, whether it's development, whether it's, know, financial advisement, all that kind of stuff, 18 months ago, having a lens of kind of the regulated environment, right? If I had said to you that I believed each customer was gonna consume a variety of models to build their own agents, that it would have contextual awareness of the inner workings of how that company has been writing software all along. policies and things that the humans themselves need to adhere to and follow. I believed fundamentally that each bank would be consuming those models and building that loop themselves. Now, it's not that that hasn't happened, right? And there are pockets where that's been done. And we absolutely have different customers that are deploying lots of very interesting use cases with these custom built agents that they're controlling. ⁓ However, ⁓ I was wrong in the sense that I have absolutely seen some of the largest customers that I support look to off-the-shelf agents from different companies that are actually coming, especially in the development domain. And we're not talking about, let's grab 10 of those agents to kind of supplement this team. I'm talking about full-scale replication of the size of a development organization. that is augmented by a fleet the same size of AI agents that are onboarded and creating access points to the different ways teams are looking to enhance the software delivery function and work on different types of things that are creating lots of debt, transformation, et cetera, throughout the actual life cycle. ⁓ And where the conversation now has gone, is not kind of like the cloud thing, not an if, but a when and how quickly are we going to really consume more of this agenda capability. Now the conversation shifts in kind of two capacities. One, the first one that's still super relevant to what we talked about in the beginning. If I go back to that notion of getting better at the data that's coming off the developer footprint at that team level, we can call it

release, right? Packaging that information. gives me a really interesting interface when I look at runtime observability, or I look at how do we help create improvement in the overall DevOps and platform function, that release capability is critical, right? Because that's what I'm gonna be pointing these agentic systems at, right? I think the second part of that, and we can kind of talk more, is how do I govern If I'm gonna pull an agent off the shelf and I'm gonna create 20,000 of the environment with different roles, know, just like we would hire a Java developer versus a PHP developer versus, you know, ⁓ if I'm doing that in that capacity. Derek: Yeah, yeah, yeah, yeah. Eric Baran: How do I actually create that segmentation, govern tooling access, create the actual environments that that AI and the human are able to interface with, right? And that has been the most critical aspect where we're getting involved in discussions today. Derek: I think, I mean, it goes kind of a little bit full circle of what we were describing. Those that have been forward thinking about the way that they manage to just call it their release process and all of the many, many, many steps that go into that ⁓ are the most suited for this because not just from a velocity perspective, obviously getting, ⁓ being able to write the code quicker, being able to migrate quicker, handle tech debt, respond to a bug, et cetera quicker, getting that to production more autonomously is only going to be beneficial. Eric Baran: Fully. Yeah. Derek: But it also allows them to start to adopt some of these tools with more confidence because there is also a governance layer there too. And I think too often we've thought about the word governance as if it equals slow and heavy-handed. I would actually say those that have done the most automation, governance there is benefiting all of the ability to say, hey, here's what we said we're going to do. Did we do it? Here's the transparency around security quality, et cetera. Eric Baran: course. Derek: but they can actually go faster, which is probably a little bit the opposite of what folks used to think, right? Eric Baran: I know. I mean, it's, it almost becomes a human governance discussion, right? Literally, because if I'm going to go hire somebody, I have an onboarding process, a way that I'm getting their developer workstation access tools. What are you going to be working on? Right? Like all that same thing. Yeah. Derek: Yes. Yes. Yeah. Totally. I mean, this is, mean, in some ways this is the, yeah. Yeah. Yeah. I mean, in some ways this is the irony of it. I get the, you know, it does require a little bit of a new way of thinking and maybe a new vocabulary, but like for the long time, right? As you bring in particularly folks that have to kind of hire at hyperscale, like every developer is going to be a little different. Every developer is going have a little bit of different skills. Some are going to be better at this or better at that. And I think we're seeing the exact same thing with agents and Eric Baran: Yeah. Yeah? Derek: and it's evolving very quickly. We're in a very similar ⁓ boat, is, for all intents and purposes, as we monitor what tools our teams are using, ⁓ obviously we use our own tools where we have them, but there's places like Coding Copilots that we just adopt what's out there. I think there's plenty of people competing in that space right now. What is in vogue today won't be in vogue next week. And also what you tried to do and it didn't work today. You better try it again tomorrow because it might work. And I'm sure we've all had that experience where you almost have to, we used to kind of learn and then you just wouldn't do that again. And this kind of hyper innovation cycle, you've got to, hey, it didn't work today, but man, I might try that again in a week because it may work better just given how quickly these things are moving. Eric Baran: Yeah. Right, fully agree, fully agree. Derek: So a couple of things here and look, everything we see, when I think about like our portfolio, we're not here to talk about that, but like when it comes to like automation around security, automation around release, like those are the things that our customers are coming to us and a lot of it's being driven by the upstream adoption and frankly, some of the needs to help accelerate that delivery piece. So I want to skip, we're almost to time here. As predicted, this will end up being the longest episode, I am sure. And we're like, we could go on for another hour. I like to always close out with some predictions, which ⁓ I've always found predictions to be terrible because like if you get it right, nobody will remember. And if you get it wrong, we'll put it on the Internet and everybody will be there to shame you of how wrong you were about about predictions. But I'm going to try to make these like relatively easy ones. ⁓ Maybe so we talked about we didn't talk a lot about upstream. I think there's actually a whole episode to be to have conversations about where where's planning going because you think about traditional planning, it was really rooted in these work breakdown elements that was about getting work granular enough at sort of the task level so that individual human developers could handle it. Well, it turns out the agents maybe ⁓ don't have some of those limitations and they can work on kind of bigger kind of epic level type things and do the work breakdown themselves. So there's a bunch of discussion to be had ⁓ there. But outside of the coding space, what part of the SDLC do you think will look the most different in the next two to three years? Eric Baran: Yeah. Yeah. It's a question. I think that there are two areas. One, I want to touch on the planning phase for a second, right? Because there's been a lot of evolution in that space kind of prior to the agentic services applied, right? What are we trying to do? We're trying to prioritize what customers want,

right? At the end of the day, we're trying to prioritize efficiency gain and how we make the workload run better. Derek: Yeah, do it, go for it. Yeah, yeah. Sure, sure. Eric Baran: We're trying to prioritize security and governance, and we're trying to understand and get ahead of where we might be able to prioritize items to open up brand new routes to market. I think one of the foundational things that we are going to see is as more agentic capability moves its way into that space, and as we allow and work alongside working with kind of the customer sentiment, where's the market going? Like there's this trove of information that's out there. that creates lots of mechanisms for inference to make those kinds of bets. And when I look at the Agile planning phase, I genuinely believe we are downstream on our going to see that. And that allows us to do things when you're describing the portfolio level, that is right at the sweet spot of how we actually allocate budget. the things we want to prioritize, which is a critical aspect of this. So like 1 million percent see that being not just a place where that's right for ⁓ evolution, but will be revolutionary in the next two to three years, right? Yeah. ⁓ Derek: Total revolution. I totally agree with that. Yep, I totally agree with that. Yep. Eric Baran: think one of the other areas that I'm really interested in, you know, it was funny, I was running ⁓ a workshop in New York just this past week with a whole suite of financial services customers was there with ⁓ one of our really strong partners in Anthropic. And the conversation actually came up around this notion of MoteBook. Now stick with me on this, right? Because like kind of pie in the sky, kind of crazy that that's a thing, right? Yeah. Derek: By the way, we're gonna really date ourselves on this podcast, because like four weeks from now, God knows what the take on Multbook is gonna be, but go ahead. Yeah, yeah, yeah, yeah. Eric Baran: Right. God knows what the next thing is going to be. Right. But one of the things that really was an interesting discussion that came out of that. Right. If you look at how we've been building software from a versioning standpoint, the version control entity, which really is the heart of the developer workflow. Right. One of the things that made the evolution of that practice so strong was the ability to build community of sharing and a sharing economy around those notions, right? And one of the things that kind of had this moment, again, could be wrong, but. If I'm hearing from the likes of that kind of an LLM provider that this smoke book thing is kind of a real thing, and even if you read Dario Modi's paper that he published back in January on how there could be an entire nation that's being created with these agents, again, pie in the sky, it comes back to if we look at how we can progress there. I do see that the notion of version control needs to fundamentally change, right? Because the way we potentially would

replicate fleets of bots and use these agents to augment and build software on our behalf is a completely different set of governance and things that we need to do in the way that version control systems are built today. I see that being a major place where this happens and then I also see Derek: Sorry. Eric Baran: communities of practice on top of that, where we potentially are letting agents learn from each other, just like we did when we were sharing code before. And I see that potentially having an ability to democratize a lot of the training costs and inference costs that goes into the model itself. ⁓ So I see a world where that is possible. And there's a lot of benefit that we could gain in that vein. ⁓ And the final piece on that is when we go back to that, notion of how CI has grown and how development platforms in that domain have just kind of gone all over the place. Being able to curate that data set. and understanding how to really make use of agentic services to keep up with that throughput based on the regulatory environment I operate in if I'm a core banking or a capital markets customer. Every environment's different. So the ability to really understand where the market goes, but then also harness what's going on and take advantage of how teams have been doing this all along and helping them evolve, I think is probably the next phase that we're really gonna see explode. Derek: There's a ton in there and I agree with you on each of those. Even you just think about like, again, the constructs of ⁓ Agile, a lot of the epic to story to test that was around breaking it down. Like you highlighted a whole bunch of dimensions of why we do planning. One of them is to take big ideas and break them down to work that individuals could do, right? Similar with SCM, when you think about what, when you do a pull request, what's involved there? Okay, who was the developer? What did the code look like before? What did the code look like after? Eric Baran: Right. Derek: If they're following some level of best practices, they're tying that back to a reason why they made the pull requests. And so maybe that's a defect or it's a what, but boy, that's wildly different than what it would look like with these just swarms of agents. And frankly, what we can capture is probably ⁓ much, much, much more granular because it'll all be automated. You and I've probably for 30 years, I've been trying to get developers to attach the work item to the pull request, right? Or back in the day, the change set. And we got to rethink some of those things. And I think it's both daunting and exciting all at the same time. it's yet another reminder, AI or no AI, we got to always remind ourselves, software engineering is one of the youngest engineering disciplines that exists. Like they've been building buildings and railroads and all that sort of stuff for much longer than we've been building software. So it's still so much opportunity here as we go into this fourth wave. I'm going to couple like 20, 30 second answers on the last couple. Eric Baran: Yes, it is. Yeah. Derek: ⁓ CIOs, CTOs, things are changing crazy fast. How do you recommend and maybe and how do you keep up with what's the latest and greatest? Like what would you advise your customers? How do you keep yourself up to speed given how the pace of innovation? Eric Baran: The experimentation is the most critical aspect of how this works. Every day it feels like there's a new prompt engineering tool, a new agent tool, a new application of the model. ⁓ And they all have significant benefit. They've got pros and cons. The end of the day though, one of the greatest... revolutions that agentic AI provides is the democratization of this discipline, right? Literally anybody can go be a developer, literally, right? And I think that for the CIOs and CTOs that we work with, really actually understanding how to apply that technology and getting under the covers of what it does, but also what it can do is absolutely critical. And the only way to do that is to play with it. Derek: Love it. Experimentation is also maybe the first technology I can remember that can teach you how to use it. Like all you have to do is ask it and it'll tell you what it can do. So that's super helpful and free basically to be able to do. ⁓ Number two, if you're a developer, right? If you're right now, you're a developer. What are the one or two skills that you need to be learning right now to make sure that your skills are applicable to this relatively unknown but certainly different future? Eric Baran: It's exactly right. Yeah, it's exactly right. Yeah Yeah, right. Yeah, I mean, when I talk to senior devs or development leaders, the force multiplication effect of what this provides us, again, is unlike anything we've ever seen in the industry. ⁓ That experimentation is even more critical. Right? Because I still need the eye of how am I going to build this? Is this the way that I want this to actually look? Does this work based on the spec of the environment? The beautiful part is as an individual developer, I have the ability to deploy fleets that are able to really help me orchestrate manage. what I need to be rooted in, is building software, building capabilities for the customer. And all the remedial components of things that we really don't like to be burdened with doing, these give us the ability to focus our attention in that vein. Same thing, experiment, use this, learn how to orchestrate, right? I played the piano for a long time, but I don't understand how all of that fits together if I've got horns and drums and all those things there, right? We now, need to learn how to be conductors, not just the specialist in the one domain. Derek: I think it's a great ⁓ way to close out and ties into a lot of what we're talking about. Like even if you think about the end-to-end software delivery process of old and of new, ⁓ it's an orchestra. It's not just a ⁓ tuba player and a violin player. It's all of them working together to create ⁓ great ⁓ music. Well, listen, Eric, unbelievable. We could keep going. We may need to do a part two to this at some point. Eric Baran: could be fun. could be fun. Yep. Derek: ⁓ And in particular, things are moving so quickly. There may actually be the need for a part two where we can come and correct our predictions and hedge our vets a little bit. But just a huge thanks for being here. Thank you for sharing your expertise, sharing your observations. Thanks for what you do and what AWS does to kind of drive the industry forward. ⁓ Eric Baran, AWS, I'm sure I will see you on the road, Eric. And to our audience, thanks for joining. We look forward to ⁓ doing this again in the near future. Eric Baran: Alright. You know it. Derek team, thanks so much. It's always fun. Really appreciate the opportunity. Thanks for having me. Derek: You got it. Cheers.