Spec-Driven Development With Kiro  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: Spec-Driven Development With Kiro - Category: #podcasts - URL: https://share.snipd.com/episode/3632951b-1a0d-40cd-bc85-912c5829e4af ## Document Notes ## Highlights - **Specs First, Code Second** - Kiro centers development around authored specs rather than direct code editing to mirror senior engineers' design workflow. - The agent converts natural input into requirements, design, tasks, and then generates code as an output artifact. Transcript: Deepak Singh Yeah, I mean, we threw our hat into the ring a little bit before Kiro, and actually we learned a lot doing that. If you go back in AI world, like donkey's year is less than two and a half, three years ago. It feels like another era, epoch in AI time. You had all these assistants that were basically fast typists. They helped you complete sentences. And then you went into these chat-based assistants that you could write functions with, like, hey, give me a function that does blah. And it was pretty good, but we looked around inside the company amongst our customers. And one of the nice things about being at Amazon is we have a lot of software developers in the company. So they're who are very opinionated about how they use software. And so talking to them and talking to our customers, it became pretty clear that the sort of chat based auto completion, give me a function was useful, but wasn't going to change the world. And along the way, LLMs got better, a lot better. They added thinking and reasoning to it. And that's when we started building sort of what we call our next generation of agents. And we started launching them. Actually, earlier this year, we launched something called the QCLI. This is actually the most heavily used agent inside Amazon. And in the process of building things like the QCLI, learning from our customers, a few things became very clear to us. The first one was you were moving towards a world where code was not going to be typed by humans. So the type faster, bright blocks of code for me was not going to be the game changer. The game changer was going to be, I have a pull request converted into something. I have written an issue, convert it into something that's meaningful that I can make part of a bigger project or write my entire software for me. And a human was not going to do the typing. We already started seeing examples of that. And it was pretty clear that that's where the world was starting to go. The second thing we did was we found that senior engineers had a really, really hard time with the original sort of era of assistance, where invariably they would say, I understand the Code base, I understand the problem, I can type faster. Yes, I might use it for some help. Like I used, you know, I'm dating myself like the cookbook to find a function. And we were like, okay, that's not useful. How do we get our best engineers wanting to use these tools and actually finding them useful in their day-to work? As we started talking to them, the thing that became very clear was the way they wrote code or solved a problem was by basically breaking it down into smaller problems. Like, how do you take a larger problem? What are its constituent elements? And how do they express them? Sometimes they write them on a whiteboard. Sometimes they write a design document. Sometimes they write pseudocode. And then they work with a set of junior engineers and other engineers to convert that into a final product. This was happening before AI. So the question we asked ourselves was, can we convert that into an AI-based system? Can we take the way our best engineers think, make it easier for them to do that, and along the way also assume that they're actually not going to type the code, an agent is going to do it For them? Along the way as we were doing this, this whole idea of wipe coding, as we call it, came up, which is this prompt-based loop where you keep prompting an agent until you get to an answer. And in that world also we noticed there were people who were, for the more complex problems, going into something else, maybe Claude or ChatGPT, and creating a set of tasks and breaking It up and then throwing it into the coding agent. The whole premise of Kira was that's just the way it works. The code typing part is hidden. It's there. You can type code if you wanted to. But the assumption is the only time you'll type code is to tweak things that an agent may have gotten wrong. But even changes that you want to make will be done by talking to an agent. So the way Kiro works is, like our senior engineers work, you express a problem. Kiro will convert that into a specification or specs, which is sort of the core piece of Kiro. It's a spec authoring tool at its heart. And a spec is a set of requirements in Markdown, design document, also in Markdown, and a set of tasks where it wants to do also written in Markdown. And that's what you work on with the agent. And the code part of it is just the output that the agent generates. ([Time 0:03:17](https://share.snipd.com/snip/d2e7a8aa-eed8-4830-8b57-8bae663475d5)) - **Built From Amazon's Internal Use** - Amazon built internal agents like QCLI and learned real developer needs by watching internal usage patterns. - The team observed senior engineers break problems into smaller tasks and modeled Kiro after that workflow. Transcript: Deepak Singh Agents. And we started launching them. Actually, earlier this year, we launched something called the QCLI. This is actually the most heavily used agent inside Amazon. And in the process of building things like the QCLI, learning from our customers, a few things became very clear to us. The first one was you were moving towards a world where code was not going to be typed by humans. So the type faster, bright blocks of code for me was not going to be the game changer. The game changer was going to be, I have a pull request converted into something. I have written an issue, convert it into something that's meaningful that I can make part of a bigger project or write my entire software for me. And a human was not going to do the typing. We already started seeing examples of that. And it was pretty clear that that's where the world was starting to go. The second thing we did was we found that senior engineers had a really, really hard time with the original sort of era of assistance, where invariably they would say, I understand the Code base, I understand the problem, I can type faster. Yes, I might use it for some help. Like I used, you know, I'm dating myself like the cookbook to find a function. And we were like, okay, that's not useful. How do we get our best engineers wanting to use these tools and actually finding them useful in their day-to work? As we started talking to them, the thing that became very clear was the way they wrote code or solved a problem was by basically breaking it down into smaller problems. Like, how do you take a larger problem? What are its constituent elements? And how do they express them? Sometimes they write them on a whiteboard. Sometimes they write a design document. Sometimes they write pseudocode. And then they work with a set of junior engineers and other engineers to convert that into a final product. This was happening before AI. So the question we asked ourselves was, can we convert that into an AI-based system? Can we take the way our best engineers think, make it easier for them to do that, and along the way also assume that they're actually not going to type the code, an agent is going to do it For them? ([Time 0:04:22](https://share.snipd.com/snip/23696dba-3634-4a60-baae-b75d685a11ba)) - **Edit Specs, Not Generated Code** - Change the specification to alter implementation instead of manually editing generated code to preserve agent context. - Interrupt the agent (Ctrl-C) and redirect when the chain-of-thought shows a wrong direction rather than editing code directly. Transcript: Deepak Singh But even changes that you want to make will be done by talking to an agent. So the way Kiro works is, like our senior engineers work, you express a problem. Kiro will convert that into a specification or specs, which is sort of the core piece of Kiro. It's a spec authoring tool at its heart. And a spec is a set of requirements in Markdown, design document, also in Markdown, and a set of tasks where it wants to do also written in Markdown. And that's what you work on with the agent. And the code part of it is just the output that the agent generates. There's more to it, but that was a starting point. That's how we came to the user experience that Kiro has today. Adam Stacoviak It's interesting to go that deep. I mean, even QCLI, if I got the pullback right, QCLI is the, it enables completions, is that right, for hundreds of popular CLIs? Is that what I'm... No, that's how it started. Deepak Singh Yeah, there was an open source project called FIG that became part of AWS about two and a half years ago. I use that as part of OMIZSH on my shell even before they became part of AWS. And they do a lot of CLI autocompletion. In March of this year, the QCLI team put an agent inside the terminal, inside the CLI. I see. And you can basically start vibe coding. That's what it is. You start prompting it. It's advanced quite a bit now. For example, you can start a conversation and if you want to experiment with something, you can actually create a branch of your conversation. You can go into a tangent. Quite literally, it's called tangent. Have a conversation. If you don't like that part, you can come back to your checkpoint. Or you can now go down the different branch and make that main later effectively. So that's been very successful. But it's all an interactive conversation. So the problem is what happens on day 20 when you've forgotten what you did, you have to go look at your conversation history. And what happens when you give that code to somebody else? They have no context of what was in your head and no artifact that they can look at in a team. And we work in teams. A lot of engineers work in teams. So in many ways, what we were trying to do with the Kiro spec UX was, how do we capture that vibe coding magic while making the code more robust over a period of time? Where it's still useful a year later, and people have the ability to inspect the specification, modify it if they want to make any changes. The two teams work pretty closely together so that we learn a lot from each other. So it's kind of fun. Jerod Santo I think perhaps why this idea, at least, if not the implementation, resonated with me and I think with a lot of people. Well, first of all, it's AWS, so you guys have a loud megaphone. So when you announce something, people pay attention. And so that got some of the attention, but also just it's a new take on something that we're all working on, which is like this agentic coding thing. And it's kind of jumping ahead, I think, in the process of we're all kind of getting to maybe in our own ways of like realizing that chat isn't it and chat's cool and all, but you just can't Build serious software in a chat dialogue. Like you can do stuff and you can make progress and you can experiment, but there's like a certain point where you're like, yeah, I don't want to live my entire life this way. I'm not going to be, yeah, I'm just not going to be productive. And you guys formalizing, yeah, formalizing the idea of, I think you're calling it spec driven development, or you can give me other taglines about like this concept. That's the right tagline. Okay, perfect. Like even just that to me, I was like, yeah, that makes some sense. That's that's something worth trying and adam can tell you about agent flow i'm sure he will he's kind of developing his own specter of development style inside of cloud code or with Cloud code as he builds things and hero seems like an attempt to like what you're using with cloud code right, right? Adam Stacoviak Well, AMP and Augment. And AMP. Jerod Santo Yeah, it's agent agnostic. Okay, so lots of things. Yeah. Okay, well said. Regardless of the agent, he's doing that. And I think that what Kiro attempts to do, I guess, is to formalize that into the entire experience. Is that fair? Deepak Singh Yeah, that is fair. And it'll evolve. I think we are learning how to build software in a world where the engineer's role is, the role of an engineer is going from being the, I'll say typist, I don't mean it quite like that, but They are the ones who are, their fingers on the keyboard, you know, converting that, converting what they have in their head into a language, which is usually pick your language of choice Here. Inside Amazon, AWS, if you're building a back-end system, it's probably going to be Rust. And that's what they excel at. Now you're acting a little bit differently. You're a driver. You're driving the behavior of an agent. It's about how you give the agent the right context. Structured thinking with specs is one way. There are other components to it, which others, I suspect in your agent flow thing that also comes up, which is how do you provide access to the right tools? How do you provide access to the right steering files that give the agent the right context to be more effective? And this combination of actually inside a Kiro project, the core components are the spec, the tools, which is usually MCP servers, the steering files, which are essentially, again, Markdown files, JSON files, that tell an agent, this is what I want you to do, how I want you to behave, give it a persona, as it were. And downstream of that, you have this idea of hooks, which are these automations that happen. Like the moment you check in code, it's watching for events. And it could be the moment you save a file, please run an optimizer for me because there may be a better way of optimizing the code or send somebody an email saying, I'm done checking in Code. You may want to look at your merge request or whatever. That combination is the Kiro UX, but the spec workflow is the heart of that. Jerod Santo So what does Kiro look like? How does it work? What is it today? Where is it heading, et cetera? But first, lay the field out so we can all see what it looks like. Deepak Singh For those of you who haven't seen Kiro, it lives on its own website called kiro.dev. It's the best place to find anything about Kiro is go there. It has, you can download it, you can read the documentation, but my recommendation is get it. Right now we have a wait list. So one of the, you know, we talked about the Kiro launch, it got really popular, really fast. We got over 100,000 developers signing up in the first few days. And we had to put a waitlist on, which we mostly cleared the original waitlist, which got very, very large. But it's still there. But the assumption is if you sign up for the waitlist now, you'll be out of the waitlist very quickly. You don't have to wait for a month or so. But once you download it, you'll recognize a few things. One, I think the most obvious one is that it is a code OSS-based ([Time 0:07:03](https://share.snipd.com/snip/c8a25ef6-1897-49bd-a451-cc9665a3d87b)) - **Project Context Is Multidimensional** - Kiro projects bundle specs, tools (MCP servers), steering files, and hooks so agents have structured context and behaviors. - This package approach preserves intent and allows automation to run within the project's context. Transcript: Deepak Singh And this combination of actually inside a Kiro project, the core components are the spec, the tools, which is usually MCP servers, the steering files, which are essentially, again, Markdown files, JSON files, that tell an agent, this is what I want you to do, how I want you to behave, give it a persona, as it were. And downstream of that, you have this idea of hooks, which are these automations that happen. Like the moment you check in code, it's watching for events. And it could be the moment you save a file, please run an optimizer for me because there may be a better way of optimizing the code or send somebody an email saying, I'm done checking in Code. You may want to look at your merge request or whatever. ([Time 0:12:16](https://share.snipd.com/snip/b50cbee2-9847-4019-b461-e857955ae95c)) - **Pick UI To Fit The Task** - Use a graphical IDE for rich spec workflows and visualization, and a CLI for fast prompt-driven tasks. - Choose the interface that fits the task: visual for spec authoring and hooks, terminal for quick prompts. Transcript: Deepak Singh Yeah. So actually it's interesting is that both the agent living inside Kiro and I've, one of the nice things is we have the terminal based agent as well with the QCLI. You know, when we say 80% of builders inside Amazon are developing code with AI tools on a very regular basis, a very large number of them are using QCLI. There's a couple of, because as I said, it predates Kiro. There's a couple of reasons we did that. There's a class of people who just love working with what you would call an IDE. And I think the IDE as we know it, which as a code editor is going to go away. Because as we just discussed, that's the less important part. It's more of a visualization system. So if you look at people doing terminal editors, they will use an IDE or some text editor at some point because they need to visualize, they need to do diffs, etc. There are some things that we found even with QCLI where which are very, very hard. If you want to build a spec and have a spec workflow to it, that's a much richer interface. And it's very difficult to put that interface into a terminal. We think there will be a lot of folks, especially power users, who will use terminal-like systems because they give you that freedom and flexibility. Or they're just from, you know, it's the classic VI versus Emacs or at some level. They just test the flow that they like. But if you're interacting with an agent, it's not a bad system to use. We also felt that there was a very large number of people who wanted that richer user interface. And the richer user interface allowed us to try a few things. One was the whole spec workflow thing that you can try building it inside a terminal. It's going to look clunky and ugly and won't work. There was one, and we had strong belief in that. But the whole helping people author an MCP server, helping them author a set of steering files, the whole library of hooks that Akira has is much, much easier. The way you would do hooks in a terminal was you would probably have a slash hooks button, and you would get a list of the hooks that you wanted. But if you had 500 hooks, you'd have to scroll through all of them to find them. In a visual interface, that's much easier. You can have a library of hooks that only your team cares about. And over time, you may have a library of hooks that, in fact, your company may publish. ([Time 0:26:47](https://share.snipd.com/snip/92db2591-3dd2-426f-8700-b2e3bb6c71c8)) - **Agent Scaffolding Matters More Than Model Label** - Kiro ships an 'auto' agent that composes multiple models and scaffolding rather than exposing raw model choices to users. - Quality depends on scaffolding, prompts, caching and guardrails as much as on the underlying LLM. Transcript: Deepak Singh Is a bit of a philosophical debate we have within ourselves as well. So the reason the drop-down is there, there was a time that Kiro allowed you to pick between Sonnet 3.7 and Sonnet 4 because sometimes you run into availability issues with Sonnet 4, There was just not enough capacity. So you could choose Sonnet 3.7 and do your work there. But that problem went away and nobody cares about Sonnet 3.7 when Sonnet 4 is available. You could always pick Sonnet 4. So we took that out. Jerod Santo Okay. But it's not going to say GPT-5 next to this ever. Deepak Singh No, but there is an, if you download it now, you will get two options. The default model, I won't say model, the default agent in Kiro is something that we call auto. And I'll go into this in a second. I'll actually go back to Sonnet 4 as well. What you're using in Kiro is not Sonnet 4. You're using an agent that uses Sonnet 4 for the core thinking part of its work. There's a set of scaffolding that goes around it, everything from your system prompts to the way you handle caching, to the way you are handling any guardrails that might be in the picture. Sonnet 4, let's take two editors, they both say Sonnet 4. They're not equivalent. It's how you drive context into the LLM and the scaffolding you have around it that makes it useful or less useful or more. So in some ways, you could argue that saying Sonnet 4 is also almost a comfort level for people saying, I've got Sonnet 4 inside it. Because it is an agent that's doing the work. It happens to be an agent that is built on Sonnet 4. There could be pieces of it. And actually, that's true for many agents out there. Wherefore, saying hello, I don't actually want to use Sonnet 4. That's a very expensive hello, you know, as an example. Jerod Santo Yeah. Well, I was just thinking about that because you, I didn't want to call it a wrapper because that seems like that's just like belittling the amount of effort that you all have done. But basically in wrapping a model like that, you're making a pretty large bet on the provider of that and you're, and you're to the, to the, you know, choosing them versus being like, Well, you can use Gemini, you can use ChatGPT, you can use Anthropic. Deepak Singh The good news is because we have a drop down, we want to go in that direction. That's fine. Now, where we have decided to go, at least for now, is an agent called Auto. Auto is using multiple agents underneath the hood. We can choose whichever largest frontier model we want to choose. Right now, we tell people, it's there in the documentation, that one of the models that we use is Sonnet 4, because that's a model that we know well, we understand well. All our agents use Sonnet 4. QCLI also uses Sonnet 4. So we have all the scaffolding in place. We understand how it works. But we are starting to, we want more. There's a number of ideas we have around how we handle the model based on the tasks you have, including maybe some specialized models for certain things. So auto is an agent, it's not a model. It uses multiple models underneath the hood, one of which happens to be Sonnet 4. And over time, we may have different categories. Sonnet 4 sets the bar in some ways for how good the results need to be. We have, you know, the way we think about it is our quality of results with Auto have to be at least as good as the agent that uses Sonnet 4, the one that you've been, that's Sonnet 4. ([Time 0:30:37](https://share.snipd.com/snip/d569df3b-98bc-4317-9327-67ac1f8f4463)) - **Turn Incidents Into Steering Files** - Capture bug diagnostics, incidents, and learnings into artifacts (specs or steering files) to feed reflective improvements back into agents. - Use hooks and automated summaries to convert runtime feedback into reusable steering context. Transcript: Deepak Singh I'm glad you asked this question. I will say the way we are thinking about it right now is where hooks come in. Because I don't think we know exactly what the right way to do it. Kiro will summarize what it's done for you and say, here's all I did. You can take a look at all the actions it took. That you can go find. Our current mechanism for doing that is the hooks part. Hooks is a great way for people to hook into, no pun intended, into Kiro. The hooks can come from you. They can also come from a third party, by the way. It's a great integration point because it's easy for somebody else to write a hook. So for example, you want to take a code and document it properly. Let's say you're writing Java code and you wanted Java docs created or something like that. I'm not a Java guy, so I have no idea how that works. But you wanted to convert that into a really nice documentation that you can upload onto a website and maybe even publish it. You could create a downstream hook that is essentially a documentation agent or another agent that takes a look at it and converts it into documentation. Maybe somebody else has written it. There's another startup or some open source project that does it. You can plug it into Kero as a hook that will do it automatically. So you still don't have to drive it. The good news is that the hook is using the same context as the rest of the project. So the context gets preserved. So that's one example. On the bug side, the thing that I would love, like one of the things I would love to do, actually, as learnings is, can you convert your learnings into a steering file that can then be used As a feedback loop? The good news with agents is they're really good at reflection. You give them error logs and feedback, they'll get better and better over time. How can we do more there? It's not something that's built into Kiro, but you can imagine that that's something that ends up happening. And I think what we learn over time is, what are the kind of hooks that everybody does? ([Time 0:45:18](https://share.snipd.com/snip/e21096fc-b468-47c8-9acf-902fa2517e2f)) - **Automate Side Work With Hooks** - Use hooks to automate side tasks (docs, localization, optimizers) so agents keep working while background automations run. - Build or install hooks that run on file changes and preserve project context for consistent results. Transcript: Deepak Singh I'm glad you asked this question. I will say the way we are thinking about it right now is where hooks come in. Because I don't think we know exactly what the right way to do it. Kiro will summarize what it's done for you and say, here's all I did. You can take a look at all the actions it took. That you can go find. Our current mechanism for doing that is the hooks part. Hooks is a great way for people to hook into, no pun intended, into Kiro. The hooks can come from you. They can also come from a third party, by the way. It's a great integration point because it's easy for somebody else to write a hook. So for example, you want to take a code and document it properly. Let's say you're writing Java code and you wanted Java docs created or something like that. I'm not a Java guy, so I have no idea how that works. But you wanted to convert that into a really nice documentation that you can upload onto a website and maybe even publish it. You could create a downstream hook that is essentially a documentation agent or another agent that takes a look at it and converts it into documentation. Maybe somebody else has written it. There's another startup or some open source project that does it. You can plug it into Kero as a hook that will do it automatically. So you still don't have to drive it. The good news is that the hook is using the same context as the rest of the project. ([Time 0:45:18](https://share.snipd.com/snip/1853c0b6-e91f-40e3-9ec9-2220c74eadaa)) - **One More Model Generation Needed** - Current models are close but not yet sufficient to reliably produce large, production-grade distributed systems without skilled oversight. - Developers still need expertise to finish the 'last mile' despite big productivity gains in prototyping. Transcript: Deepak Singh Oh, both, both. Jerod Santo I mean, it wasn't a bold question, Deepak. You can't say, I'll be blunt. Deepak Singh It was either or. Fine. Touche. I think we need at least one more generation of models. There are probably models out there that can get you there, but they're really expensive. And the context windows aren't right. There's a lot of limitations right now. I mean, I say that given the fact that over the last year, the models have become so much better. Some of the things that we're doing today, you could not do a year ago. You just couldn't. I do think there's one more generation of models before we get, I still feel like to write a full application, like not a simple product, but a proper distributed backend. And we have examples of people who've done that. But it requires a lot of skill in the part of the developer to be sure that you're in the right place. I'm not saying that's a bad thing. I still feel like the people who are going to be most effective using these tools are skilled people. They're not, there's a lot of folks who believe and hope that you can give somebody like me and somehow make me a better programmer, developer. That's not happening. Can I write applications more quickly and easily? Absolutely. I can prototype better than I ever could. I've written more in the last year than I had in the five years before that. ([Time 1:01:17](https://share.snipd.com/snip/97fa26b5-4e33-4f8d-ab7e-166d76009d01)) - **Make Usage And Cost Transparent** - Track real-time credit consumption and show per-action costs so users understand and control expenses. - Expose which models, context sizes, and tools drove each cost to guide optimizations. Transcript: Jerod Santo This thing's a product y'all are trying to sell. How do we buy it? Deepak Singh So we changed our pricing twice already. Okay. So this is a pricing that we announced, and I'm going to get it wrong, last week. And it'll probably go fully live. We'll start charging people sometime in the next few weeks. But it's your classic per-user pricing. You get a free tier. You actually get a free trial, because the free tier is mostly just for vibe coding. The free trial gives you the full experience. I think we put you into the pro tier for about a month, and you can play around with it. And then if you like it, you can actually start paying, or you can flip back the free tier. But there's a $20 tier, a $40 tier and a $200 tier that give you 1,000, 2,000 and 10,000 credits as a credit system. The way we talk about it is if you're using the auto model, you will get those credit consumption for Sonnet 4 is 1.3 times the credit consumption of auto. And so you just get a set of credits. And as you can see, if we gave you a selection of some kind, we would have different credit consumption rates based on the cost of running those models. And so you get two agents, an auto agent and a Sonnet 4-based agent. The Sonnet 4-based agent is 30% users, credits 30% more faster, typically, because it depends on the prompt and the LLMs are deterministic. But for the most part, 30% more than faster rate of consumption than the auto model. And we also have overages. So if you, you know, use, so there's another thing that we did was, we added the idea of fractional credits. So when you go to, when you go, you can go from one to 1.1. You don't go from one to two in these step changes. We found people who are running into going through their credits a lot because they use a little more than the boundary, and then they would get sent to the next one. And that just meant that you just consume credits really quickly. The other thing we have is overages. So if you're in the $20 plan, you don't need to go to the $40 plan if you just want to spend $21 for the project you have in hand. So there's overages there. And then the 201 assumption is most people will rarely get there, but we know there's some people who will because they have. But we spent a lot of time in trying to optimize that credit consumption. And at least in our early testing, it looks like you're not running out of credit so quickly. ([Time 1:05:09](https://share.snipd.com/snip/80d8eda5-f467-4adf-b87b-07848d9cd1e0)) - **Lower Activation Energy For Builders** - Agentic tools lower activation energy for building software, enabling solo founders and small teams to ship more complex projects. - This change reduces barriers and lets creators act on ideas they previously couldn't afford to implement. Transcript: Adam Stacoviak World. And I'm just not sure how I feel about that right now. Deepak Singh Yeah, I actually think it's the other way around. I'll give you examples. Maybe there's a toll booth. I don't know. But the way I think about it is there are things happening where the cost of doing that thing is very, very high. Maybe I am a semi-technical founder and I'm busy spending time looking for an engineering, a very deeply, a deep engineering team because I can't even build a prototype, right? Because I'm not technical enough to go do that. I have an idea in my head. I can write some JavaScript maybe, but my idea requires some heavy duty backend stuff and I have no idea how to do it. In theory, and I've seen enough examples that this is possible, you can do that on your own, or maybe with one person to do much more work. Once you have that, you can go further. That's one example. I've also seen people who've had a project that's been sitting on the back burner for a decade because it is something that they built. It's an open source project. They've got a day job and they don't have the time to go and, you know, evolve that open source project because it takes too much time. They don't want to spend their weekends doing maintenance of an old thing, maybe. Or you have a backend that's not scaling and you need to change it. But the cost, you know, you need to change it. But the cost of doing it is like 20 people and a year and a half of development, if you did it the old way. I've seen enough evidence now in all three cases of people building, using these agentic development systems, going and tackling those problems. The first one is an obvious one. People talk about it all the time. That's this founder thing. The second and third one, I think, is where the magic lies, which is you are doing things now that you would not have done before, which results in better code, better user experience, Et cetera, because all your barrier to entry and ability to do it is small and low enough that what you thought would take you two weeks is now going to take you a day and a half, maybe even Less. What would take you 20 engineers and a year and a half, you can now do in much shorter time, et cetera. My favorite example is actually of a team that does sprint planning every four days instead of two weeks because they were finishing their backlog that quickly. So I think that's, to me, that's, I don't know if you'd call that a toll booth or shifting of the toll booth or whatever, but I do think there's this innate sort of barrier reduction. There's an activation energy to everything. I used to, you know, I'll speak in my physics terms. And you need a catalyst to cross that activation energy. And that catalyst could be funding because you get more people. It could be hiring really talented people. I actually think it's not just the catalyst part. Your activation energy has gone down significantly. So the catalysts you need are, you don't need catalysts at all in some cases, or you need the best ones out there. And I think that one, it'll have a meaningful impact on software development and how teams are structured and how we think about it in a very positive way. Because you're getting things done that you either not doing or wouldn't have done or would have done much more slowly. And I think that's at least that's how I think about it. Maybe I'm the glass half full guy. ([Time 1:15:29](https://share.snipd.com/snip/b972244e-8343-49eb-9480-103eb396db6d))