In short
Dev Interrupted Podcast Episode Summary
Podcast Overview Title: Dev Interrupted Description: A podcast focusing on software engineering leadership, where hosts Andrew Zigler, Ben Lloyd Pearson, and Dan Lines talk with experts about the strategies and stories behind high-performing software teams.
Episode Details Episode Title: How Spec-Driven Development is Changing the Rules | AWS’ Amit Patel Description: The episode features Amit Patel, Director of Software Development for Kiro at AWS, discussing spec-driven development and its significance in managing complex AI projects. The conversation includes the development process of Kiro and its innovative methodologies.
---
Key Themes & Discussions
Spec-Driven Development
- Definition and Importance:
- A structured approach that maintains context in software development projects.
- Addresses the limitations of "vibe coding" (ad-hoc coding without a structured plan).
- Provides persistent, structured specifications that serve as a long-term memory for both AI tools and developers.
- Kiro's Approach:
- Kiro allows the transformation of requirements and design into structured specs.
- It aims to maintain project context across sessions and teams.
Development Process and Feedback Loops
- Building Kiro:
- Developed in under a year using a rapid iteration process.
- Incorporated feedback from internal developers testing nightly builds, leading to real-time improvements.
- Kiro's development included multiple iterations (six revs) to refine the tool based on user feedback.
- Effective Feedback Mechanisms:
- A dedicated Slack channel was created for developers to share feedback and suggestions.
- Feedback was prioritized and acted upon to continuously improve the tool.
AI and Engineering Context
- Challenges with Traditional AI Tools:
- Initial AI coding tools struggled with complex projects requiring context outside chat windows.
- Kiro was created to address these challenges through a structured workflow.
- Future of Development Tools:
- The evolution of tools like Kiro could lead to new job roles and responsibilities within software engineering.
- Emphasis on developer ergonomics and productivity.
Industry Context and Insights
- AI in the Current Landscape:
- The podcast discusses the current state of AI, comparing it to the early days of the internet.
- Highlights the notion that while AI tools can enhance productivity, they also require established practices for effectiveness.
- Psychological Safety in Engineering Teams:
- Importance of creating an environment where team members feel safe to voice concerns.
- Discussion on the negative impacts of fear-based management styles in tech environments.
Interesting Anecdotes
- Real-World Applications:
- Early adopters of Kiro reportedly used it for significant projects, including contributing to AWS services like S3.
- Users found Kiro's structured approach greatly reduced the time required for tasks traditionally handled manually.
- Cultural Impact:
- The process of using Kiro has led to a cultural shift within teams, enabling engineers to build features faster and more collaboratively.
---
Conclusion This episode of Dev Interrupted showcases how spec-driven development through tools like Kiro can transform the way software is built, emphasizing the importance of structured planning and continuous feedback. Amit Patel shares valuable insights from both the development of Kiro and broader industry trends, making it a must-listen for software engineering leaders interested in enhancing team performance and productivity.
Additional Resources
- Learn more about Kiro: [kiro.dev](https://kiro.dev)
- Join the Kiro Community: [Kiro Discord Channel](https://discord.com/invite/kirodotdev)
---
Takeaways
- Embrace structured development methodologies to improve project outcomes.
- Foster an environment of psychological safety to enhance team performance.
- Continuous feedback loops are essential for innovation and improvement in software tools.
Written by AI. May contain mistakes. Listen to the episode to check what was said.
Transcript
Automatic transcript. May contain errors.0:05Welcome to Dev Interrupted. I'm your host, Andrew Ziegler. And I'm your host, Ben Lloyd Pearson. This week, I'm sitting down with Amit Patel, Director of Software Development for Kiro at AWS. And we dive into how his team, operating like a startup inside of Amazon, created a new agentic IDE called Kiro that uses spec-based development to create persistent structured plans. This approach keeps context alive between sessions and your teammates and fills in a crucial part of the agentic handoff. Amit shares how his team used the tool to build itself, and all by creating the space for engineers to do their best work.
0:44But before we dive into it, in this week's news, we're covering a few topics, including something that came across our desk about AI being in its dial-up era, engineering managers who are paralyzed by fear, and how they act out, a hack that someone did for their Wi-Fi-connected robot vacuum that was just too good to read. So we're going to cover all of this stuff. And Ben, I think let's start at the top. Yeah. So I wanted to cover this story on AI's dial-up era. So this comes from Substack user Nowfall. And look, Andrew, it's 1995 all over again. You know, the AI boom feels like the early internet, like full of hype, destined for a bunch of shakeups.
1:25But while all the while along, we're building these foundations for what the future is going to look like. And, you know, so back in 1995, like, let's all think back 30 years, you know, the internet had just started to go mainstream. Many of us were just starting to get connected to it and imagining the possibilities that it would bring to us. And, you know, looking back 30 years on, in a way, both the optimists and the pessimists were right about many things over the years. But ultimately, it was incredibly hard to imagine what life would have looked like here in 2025, if you were sitting there back in 1995, just getting connected to the internet.
2:04Let's just think about the fact that the internet search or the internet giants now started as a search engine in an online bookstore. Would you have imagined that those would be the titans 30 years later? Truly. And this article brought up everyone's favorite philosophical concept in 2025. That's Jevon's paradox. But approached it in a way that I think is nuanced in a way that not a lot of people have covered this paradox, you know, and that is that, you know, more supply, yes, it can lead to more demand. Like if you build more efficient steam engines, you may just increase demand for steam engines, but there's a, there's a limit to that actually.
2:42And many industries, they grow in demand for a while, but then productivity and demand for that service or that object, uh, reach some sort of equilibrium that sort of causes employment to drop over the longterm. And, you know, we're all like navigating this space of AI with its excessive hype, its inflated valuations, these inevitable failures that are certainly around the corner. But there's a lot of infrastructure that's being built in the space right now that will outlive a lot of that hype and bubble popping. I feel often that we're kind of at like the peak of it right now, especially with like what we're hearing around like open AI coming out and, you know, they've got 1.4 trillion in spending obligations over the next few years and off revenue of like less than$2 billion revenue per month.
3:33You know, like do the math on how long it's going to take them to pay for that without extreme growth. And, you know, but I've seen a lot of these parallels sort of between the internet bubble popping and how it gave us all this internet or inexpensive infrastructure that was then used by all the web 2.0 companies to sort of build the next generation of the web. And, you know, this article really just sort of makes the point that, you know, we can predict change, but we, it's really challenging to know the specifics of that change. You know, very few in 1995 for Saul dating apps or Uber or influencers being a career option.
4:12And similarly, AI is going to unlock a lot of new domains and job categories yet that, that we just don't really have a concept of because they haven't been invented. And, you know, a great example is there's a lot of job transformation that happens during these sorts of changes. Journalism as a function has expanded over the internet era, but the journalist job has declined all along the way. You know, just as a great example, like I would say you and I, Andrew, we are certainly not journalists, but we do engage in a lot of acts of journalism, as do many professionals in our space. Yes. But I wanted to cover this because this is one of the best articles that I have read in quite a while about the state of the AI industry.
4:52And it really closely matches my own perception on where everything stands. And I just love the closing line. Our AI future is loading. We're all still determining that today. I love how it ended. Ben, you phrased that all so well. This article for me was also really amazing to read, really poignant of a time when transformation was happening really rapidly. And none of us could have really predicted how it was going to shake out to be the world that we live in today. Like you said, it ultimately called us this transformation of so many things that we took for granted or just thought were going to be around forever, both in good and bad ways, right?
5:25And so ultimately, it's about understanding where that change is taking you now and really living in the moment. Because I think the people who got the most out of all of that transformation and change were the ones that were looking not at what could be in the far, far potential ahead, all of the hypotheticals, but looking at what's possible right now. Like you hit on how journalism is something that became more approachable for everybody. That's because the freedom of dissemination of information over the internet became so powerful and became so easy for everyone to share their perspectives, their experiences in real time.
5:57And on top of that, it really brought everybody into the world of journalism. It helps everybody think like a journalist. And the same thing right now is happening in engineering. We're inviting the entire world into how the engineering world works with AI. Because AI is making it something that anybody who can conquer language, which everybody can, can use and can do. So we're in this powerful new era where our roles and jobs are transforming. But we're going to see a lot of things of people playing with these new parts that they never had exposure to before. And that's where bloggers and influencers come from.
6:32Like, I'm really excited to see what the people of the world do with their accessibility to technology. Yeah. And one great point that this article makes is that software engineering as a function could or as a role, as a job, could be plateauing either today or in the near future. But software engineering as a function or as a capability is probably just going to continue to increase in demand. It may just not be the role anymore. It may only be like a part of a role. That's right. That's right. Let's jump from the environment that we live in and how it's rapidly evolving into the real life work environments that we live in now and how they're populated by people.
7:10And we have to navigate people problems sometimes. And this really amazing article by Stefan Moreau came across our desk as well. And it's about a study from Work Life that's looked at how workplace environments from managers can create psychologically unsafe environments. We're talking about managers who control power with fear and who act out because of their own insecurities. And these kinds of behaviors, they cause an estimated$36 billion in lost productivity worldwide. I think, you know, many of us have been in toxic work scenarios before. I touch on this because this article in particular frames it in the engineering manager world.
7:49If you've ever been in that kind of environment in a technical one, where there's also maybe, you know, some bad people chemistry going on in terms of a manager who doesn't feel secure in their role or they are lashing out for other reasons. You know, ultimately, we're all human. And unfortunately, sometimes we get the worst of humans as well. But Ben, you want to walk us through some of the ways that Stefan framed how this fear really operates and how our listeners could really recognize it and navigate it. Yeah. So I really like how Stefan framed this through two different lenses. So there's almost like an internal focus to fear where you exist in an environment like you describe where it's psychologically unsafe.
8:30And this can lead to like a vicious loop of things like micromanagement that just destroy trust. There's also a version of fear that's almost more external focused. It's fear that keeps you aware of competitive pressures, technical debt, the ability to optimize for excellence. And the latter type of fear is completely normal for humans or for any life form really for that matter to engage in because it's a healthy way of just promoting continuous improvement, responding to external stimuli, things like that. But there's a lot of great tips in this article. First and foremost, psychological safety is the top predictor of team effectiveness.
9:10Everyone on your team should feel free to voice their concerns. It should be an environment of being able to share opinions in a trusted space. You also should understand the things that you fear to analyze whether they're actually worth fearing or not. You know, I personally always think about worst case scenarios for practically every project I engage in. And it's not to be afraid of them or to get fixated on them, but it's to understand the level of risk that I'm taking on. You know, and usually the worst case isn't so bad, you know, and I'm willing to live with whatever that level of risk is.
9:43But that's a perfectly healthy response to fear. And then if you do feel like you're in an environment where you are maybe stuck in a fear-based leadership loop, just pick one to work on. Whether that's a communication challenge, micromanagement, decision paralysis, conflict avoidance. There's a lot of ways you can break down your fears to determine which one might be causing the most disruption. Literally telling you to pick a struggle. Yeah. Yeah, but there's some great quotes at the end of this too. Like I love fear, fear mediocrity more than mistakes, fear stagnation more than experimentation.
10:23There are healthy things to fear. Just use them to channel yourself in productive and positive ways. Here's the deal. We all end up in these scenarios from time to time. I myself have been in a toxic workplace and the first step is acknowledging it and understanding it for yourself. And then like this said, you know, carving out that safety for yourself, picking a struggle as comical as it might sound on the surface is actually the best thing you could probably do for your psyche, as well as evaluating the things that you are worried about and have fears about. Like, is it worth worrying about even in the worst case scenario?
10:56Literally walk it all the way through to the end. Is it really that bad? A lot of times it's not. So don't make your own boogeyman as well. And if you're in these kinds of situations, you know, we wish you the best in navigating it. And we hope that this article can help you do so. All right, now let's move on to fear of IoT. We have a really interesting story about vacuum robots. Angie, what is this? Okay, I love this one because I'm always really skeptical about the Internet of Things. I'm not that person who has like all of their stuff on their router. I do have a few smart devices around my house, including though a smart vacuum against my own wishes.
11:30It's unfortunately just something that other people in the household really want to have. So it lives with us. I love my smart vacuum. I do not. Me and my smart vacuum, we have an understanding. But ultimately, this story is about how invasive these things can really be in your home. And it hits at how the technology inside one of these particular vacuums works, including transmitting telemetry information about it going around your house and mapping out your home. You know, so you have to send that stuff off to a third-party server to get processed. Of course, there's not enough processing power on the robot vacuum.
12:03But there's a lot of other security concerns in there as well, transmitting really sensitive information about your house, but then also being connected to your local network through systems that may not be very secure. This was an article about how he really got into a war with his vacuum, disabling it, changing how it worked, and ultimately it was issued a kill command by the remote manufacturer. And he was actually able to, or they were actually able to revive it, opening it up, connecting it with Python and creating some custom scripts with custom hardware to actually get it to run again. And this was a really fun article about how you can take the Internet of Things back into your own hands.
12:39And I myself really felt justified about all my hatred for robot vacuums by reading this one. What did you think, Ben? Well, first of all, I mean, it really lends credence to the narrative of how bad centering your life around services that have to exist on the Internet for like core functionality. You know, like if a manufacturer can just turn off your vacuum robot because you disabled the setting on it. Like that's, you know, very anti-consumer practices, unfortunately. But I mean, I love the ingenuity, you know, software engineers are certainly the types of people that will figure this stuff out and make it work no matter what.
13:17But yeah, I mean, there's a lot of, it's just a great journey on like understanding this vacuum and following the journey of this person. You know, there's some great advice on not using your primary Wi-Fi network for IoT devices and sort of training them as strangers in your home. So, you know, I did say I do love my robot vacuum, but it also is not allowed to go on the Internet. And I have actually had a lot of smart devices in my home in the past, but they are always on their own separated network with a lot of restrictions around how they can access the Internet. And many of them are just refused access.
13:51And I'm also a big fan of if you are doing IoT stuff, the more that you can control within the confines of your house. So using local protocols and control devices, the better because then you kind of cut out the needs of internet services. But yeah, it's a great story. So go read it if you just want to learn how to fight off these anti-consumer practices with engineering. And just take this hardware back into your own hands. I think it's getting easier than ever to really like poke at these devices. is we've covered this in a few different stories now recently of people taking everyday pieces of hardware, like a receipt printer or an actual printer, or in this case, a vacuum cleaner, and changing it to modify for how they want it to work.
14:34I think hardware modifications are really expanding right now because you can use LLMs to do a lot of probing information about how the technology works and actually get that architecture up and going. But I'm over here right now staring at my vacuum cleaner like, yeah, I'm talking about you. And it's sitting over there looking back at me. So before it starts moving, I think we should move on to the next story here. Yeah, absolutely. Yeah, so I wanted to cover this one. So Have I Been Pwned out with a really great article written by Troy Hunt. Two billion email addresses were exposed, and the Have I Been Pwned team had to go through the arduous effort of indexing all of these.
15:11I'm a huge fan of this organization. If you're not aware, they're an organization that keeps track of all the passwords and email combinations that have been published to the Internet by malicious actors. This data dump, the most recent one that was covered in this article, is three times the size of their previous record. So 2 billion emails, 1.3 billion passwords, and about 625 million of which were unique. So just an extraordinary amount of data. It brings the total accounts that are on the website to just over$17 billion, about$17.2 billion. Wow. This article has a lot of really interesting technical details about the challenges they faced while handling this data.
15:54The mere act of hashing the email addresses was enough to just crash their infrastructure. So they ended up having to build this fairly complex process of batching things in chunks of 1 million records. And then on top of that, they had to notify 2.9 million subscribers by email that their account was in this dump. So, you know, just a great PSA. You know, make sure to check your accounts if you haven't already. It's a good practice to check this regularly. Yeah, really fascinating story. What did you think, Andrew? This one was really interesting. The size of this breach is huge, y 'all. I know it's like it's easy to kind of roll your eyes.
16:31You're like, oh, another data breach story. That's kind of how I initially kind of glanced at it, too. But, you know, 625 million unique passwords in this dump is really significant. And it's worth going in and punching in your info to see how it works. And speaking of how it works, you go to the website and counterintuitively it asks for your password that you want to test, which is really fascinating to me as like an engineering challenge. Because like Ben said, you know, they had to go through all of the batching to ingest all of this and to actually do stuff with it. But then they have to manage and actually let you check against this data in a really safe way.
17:05So the engineering architectural challenges of making Have I Been Pwned possible are magnificent. And the service that they offer to, you know, the entire world is really impactful. Because you have to think about this in downstream consequences. If have I been pwned didn't exist and people couldn't verify, then people's accounts would further get compromised, which would then cause more things to get into the breach, which would ultimately cause a lot of internet security problems around the globe. So by having this kind of step in place, it kind of like stops the bleeding. It's like a tourniquet, right, on these password breaches.
17:40I mean, it lets people kind of get a control on what they could do with it. And working with this huge amount of sensitive data that in most cases is hash, you can't even see it. You don't even can't verify what's going on underneath. It actually reminds me of when we had Min on the show recently from Transcend talking about the engineering challenges of working with highly private data, data that you can't see, the security practices behind working on that kind of scale of really sensitive data. It's a huge challenge. And it's something that Herner engineering team carries itself as a first class concern within their engineering work.
18:14So same thing is happening here. This is like a highly secure engineering process to make this possible. Really fascinating to me and kudos to that Troy Hunt and the whole team there for continuing to operate the service for everybody. Yeah. And if you haven't listened to that episode that Andrew just mentioned, Make sure you go back and check it out. Yeah, it's a pretty good one. Yeah, so speaking of guests, who do we have this week, Angie? Yeah, so like I mentioned at the top, after the break, I'm sitting down with Amit. Amit is from AWS. He's talking all about Kiro. So you don't want to miss this one.
18:43Stick around.
18:47AI has changed how we build software. But faster code doesn't always mean faster delivery. That's why Linear B is launching The Essentials Plan, your toolkit for measuring and improving AI productivity. You get the new Linear B MCP server, AI Insights dashboard, and developer surveys, all designed to reveal how AI tools impact delivery speed, code quality, and developer experience. Stop guessing which AI tools work and start leading with data. Visit LinearB.io to learn more and unlock the next chapter of AI productivity.
19:23You know, my guest today for those listening is Amit Patel. He's the director of software development for Kiro at AWS. And today we're diving into the new agentic IDE his team built called Kiro. And picture this. It's a tiny team inside of Amazon that starts from scratch. In under a year, they build a vibrant community with hundreds of developers testing nightly builds. They use the tool to build the tool itself. And they even start contributing code back to a foundational AWS service, S3. And what made all of that possible? Well, it's a new approach called spec-driven development. And today we're learning what it takes to reinvent the agentic coding experience.
20:05Amit, welcome to Dev Interrupted. Thank you. Great to be with you. Great. Well, we're really excited to dive into this with you. I'm a Kiro user and I have so much success I've had with the tools. I'm really excited to learn more about where it came from. And I think going back to my tool adoption this year, I found that early AI coding tools, they were great at quick wins, but it struggled on a team level to get code across the finish line to production. And it became a real pain to build complex stuff that was shared across lots of workspaces with project-specific details that, you know, live outside of the chat window itself.
20:41I think it's what we've all learned this year. So Hiro at the top addressed this with a structured spec-driven flow that bakes in all of that context. So what signals did you see that showed you that prompting isn't enough for building real-world software that led you to creating Kuro? Yeah, when we started out with Kuro, it's probably more close to a year ago now, one of the things that we were looking at was what are the problems that developers are able to solve with AI as it was at that time? and what are the things that they struggle to solve. And we talked to a lot of developers inside the company.
21:25Obviously, we have a very active internal development infrastructure and community. And we talked to a lot of those developers. We talked to a lot of customers as to what they love about using AI in the development lifecycle, what kind of frustrations they were hitting, and what they would like to see improved. And at the time, the industry was also improving things, for example, introducing things like steering and rules and other ways to guide the LLM to do what they needed it to do. So the industry as a whole recognized that there are limitations to what can be done in a simple chat window with just Vibesoting, especially when the problem to be solved is a reasonable size problem, a meaningful problem.
22:13it becomes quite difficult to have enough context and enough memory as an individual developer to remember what you did yesterday or two days ago and what you told the agent. Even three hours ago, sometimes I forget what I told the agent to do. So one of the things that we wanted to do was to solve that problem in a more structured way and not simply provide you know snippets of memory or some kind of steering or you know we have those things in Kiro and those things are important but we didn't feel it was enough to just kind of provide those things we felt that in order to build more complex projects in order to tackle harder problems which required multi-day initiative we needed more structure so that's that's the the sort of genesis of the product idea.
23:09And how does Kiro keep that context alive between days and teammates? Because I completely agree with you about that ephemeral nature that happens in the chat. Maybe you don't remember what happened three hours ago. So how does Kiro transform that ephemeralness into something that lasts? The concept we introduce is what we're calling spectra-driven development. And rather than remembering what the prompts were three days ago, So what we're saying is, Kira will allow you to essentially build a plan, a structure for your project, or whatever work you want to do. And it has three stages. So first stage is, and again, this is typical of any software development project, which is, hey, let's define what the requirements are.
23:58That's the first step. Then let's define what the design is going to be for those requirements. and then let's figure out how we're going to implement it in a step-by-step way and make sure that at every step we have made progress towards the ultimate goal and that we are not introducing issues or regressions or whatever else. So those are the three stages of what we're calling spectrum development. And what we've built into the tool is the ability for people to plan complex things and then to have a very structured task list. And the task list that comes out of it is really the way that the um the user of kiro the developer can keep context on what was done you know i completed tasks one to five yesterday now i'm going to go on to task six and seven and eight kiro actually can look at all the tasks that were completed in a previous session and say okay these things are done kiro can also see what the requirements are kiro can also see what the design is.
24:58And so all of that context is available on task six and seven and eight and 20 as you go down that list. So that's how it maintains the knowledge of what it has done, what it's supposed to do, and what the ultimate goal is. Yeah, and I want to call out the great part about Curo 2 and how it captures that spec is, you know, this becomes like a really a first-class experience inside of the IDE in a way that maybe is new to some developers. The spec-driven development in some cases will really push you back into doing the designing, planning, making sure you have a really clear structure because of how critical it is for it to work.
Read the full transcript
25:40And so what other guardrails does Kiro have built in? Besides keeping the user on this structured flow, are there other things that usually get baked into a spec that make it more robust out of the box? How does it help the engineering leaders trust the end result that comes out of the IDE? During the sort of requirements and design phases of the spec, the developer can actually ask for additional tasks to be done. By default, in our structured approach, we're also doing things like enabling the Kiro to generate unit tests for the application or the feature that the developer is trying to build.
26:26But as a developer, you can just ask Kiro to implement either architectural changes, like if you wanted to go in and say, hey, for these requirements, I want you to have this kind of scaling potential so that the application will be built for scalability or whatever. But whatever those requirements are, you can add those to the requirements or you can add them to the design, whether if they're functional, non-functional, or so on. And that will then generate the tasks that are necessary to accomplish those objectives. So there's a lot of things that Kira does in itself in terms of things like unit tests and so on.
27:10There's a lot of things that developers can do in the early planning phases to make sure that their functional and non-functional requirements are going to be met by the ultimate output from Kira. Yeah. And what do you think people should really care about when evaluating these AI tools and these new IDEs? What should a leader prioritize about what matters to their team with these tools? There are a number of things that we would, a leader should consider. One of them obviously is what is the priority for their organization. Typically those things revolve around having their engineers be more productive and that the output from these tools is actually maintainable and it is production ready.
27:58and also that the developer ergonomics are there so that their engineers will enjoy using these tools because if the tool is good but it isn't enjoyable to use or it causes little paper cuts or frictions, it can be really frustrating and reduce productivity. So ultimately, this is about having productivity increases in your organization and making sure that the output from these tools is something that is maintainable and reliable and, you know, operationally excellent so that it doesn't cause a lot of issues after you've shipped it to production. Right. Cogen is just one part of the process. Does it cause issues downstream?
28:41I also love that you called it the developer ergonomics, like that experience, that joy of creating software with the tool. And, you know, to get there, you know, you told me that you went through six iterations of the spec experience to make it as good as it is now and to meet the developers where they need to be met right now. So what did that journey feel like? Did it feel like overkill doing six iterations or did it feel like exactly right in the amount of iterations to get where you got? Yeah, I mean, I think our approach was to make sure that we had something that would be useful and easy to use and deliver the productivity that developers wanted.
29:23And we didn't know at the beginning of the journey whether it would take us one rev or six revs. We just didn't know. We just wanted to make sure it was right. What we found as we kind of went through this, because we kind of worked with a lot of internal developers to make sure that we validated our assumptions about what would work and what wouldn't work, what we found is that people had ideas on how we could improve things. And every time we felt that those ideas would meaningfully improve things for our customers, we went back to the drawing board and we tried to incorporate those. It did take us six attempts to get there.
30:01I think it was worth the journey because what we ended up with, actually, I don't think we could have got in one shot. I mean, it really required that number of iterations to get to where we landed. Yeah, I think it speaks also to the exploration phase that everyone is in, you know, nothing's more exploratory than the actual, you know, agentic coding experience that you'd be working with in that unknown. And so, you know, along the way, as you create this experience for devs, I want to go back to like software and how that could translate it into specs itself. Because, you know, building softwares can be a highly opinionated and prescriptive thing for different orgs, and they have their different requirements and different things that they care about that matter to them when making software.
30:46So how does AWS evaluate spec quality and evaluate how that actually impacts the needs of the users? How customizable is this? How much does it prevent people from hurting itself? I guess the question becomes, how opinionated is it and how easy it is for people to change for their own needs? Yeah, so one of the things we wanted to do was to balance the ability of developers to change things as in how they need it with the ability for the LLM to actually understand the spec when it came out at the end of the process, right? And because the LLM is by nature non-deterministic, the less ambiguity you give it, the better the output will be, right?
31:33So we chose to use EAS format. It's sort of, I won't go deep into that, but people can look it up. We used EAS format so that it provided some structure. Then enabled the developer to either use the normal chat window to iterate on the design and the requirements. Or if they wanted to, they could go directly into the markdown files for requirements and design and edit those directly. and then ask the LLM to generate the task list based on their edits. So that provides enough flexibility for people who either directly want to edit the markdown files or who want to use the LLM to make the changes that they wanted to make.
32:18But we have set it up in a way that you can iterate with the design and with the requirements as much as you want. And then based on those requirements, generate the design. Based on that design, generate the task list and then execute the task list that ultimately comes out. So it was super important to make sure that, you know, we enabled that level of kind of iteration. A lot of times, you know, people will just one-shot the prompt and say, hey, I want an app that does X. That will generate a whole bunch of requirements. You can then clarify it and say, hey, no, I don't want a web app. I want to build it using Python or whatever.
32:56I don't know. And that's how you iterate with the requirements. So a lot of the times people just go with the one shot and generate the requirements, generate the design, generate the task list. And then after it's built the first version of the feature or the first version of the app, then they go and say, okay, now I want to refine it. Now I want to do something else. So you can choose to do it in either way, but that control is with the developer. And since that control is now the superpower, the taste that the developer brings and how they use these tools, it's also the new kind of skill set and the new layer in which engineers operate on, their decision managers in this world.
33:42And do you think we're heading towards a world where maybe we have spec reviews as much as we have code reviews, where since so much of this work and thought that developers do now moves so early and so critically foundational to any software project that almost reviewing and getting on the same page about that is more important than what happens downstream or maybe equally important? I think that it's actually better to clarify that we haven't tried to significantly disrupt the typical software development lifecycle, right? So we have requirements, we have design, and we have a task list. Those are the three different stages of the spec.
34:23So even before AI, teams would regularly do design reviews. So they would have a design doc, and they would review the design doc, and they would go through that, right? So with the tools that we have now with the spec-driven development, you can still do that. You can still generate the design. It's a markdown file. You can even print it and have a meeting and talk about the design that was generated by the tool. Or you can collaborate in front of a screen and just edit the design together. So I think it doesn't take away the normal software development best practices. If you have a project that you're working on, it's meaningful.
35:01you've generated requirements, you've generated designs for it. I would expect that design to be reviewed with the team and iterated and worked on. Yeah, no, you make a great call out here, and it's actually one shared by many great minds at some amazing companies like your own that we've been speaking with around how large companies are using these new coding tools, and all of them equally and rightfully call out, just like yourself just did, that ultimately comes down to having best practices. It's a force multiplier for what your organization is already doing. And if you have these great rituals and processes and support that allows your developers to ship great software already, then you're going to have a lot of success bringing AI into that world.
35:47If you don't have those practices, you're going to find it rapidly misunderstanding and misdirecting you. So I think that's totally right to clarify and call out and kind of like a great part of what makes the tool so flexible to as it meets people where it needs to be. And typically, you know, on a reasonably complex project, it would take an engineer maybe two, three, four days to write a design doc for it. The benefit of something like Kiro is that you get the design doc in, you know, 10, 15 minutes, and then you can just go and have that meeting and have that review. So that's the benefit, right?
36:17It's not circumventing some of your regular processes, it's just getting you there quicker. So going back to, like, the genesis of Kiro, you tell the story like Kiro has been launched as a startup inside of Amazon. You know, what did you do differently? How did your team operate that was maybe different from a quote normal AWS team that gave you that startup level speed? Yeah, I mean, the first thing to say is that a lot of the AWS portfolio of products started off in a very similar way, you know, that kind of gets together and says, okay, I have an idea for a product and let's go and let's go and build it.
36:55So in that respect, we didn't do anything different. And we had this product idea and we were asked to go and build it. And, you know, this idea of small teams moving fast and being able to implement things based on customer needs has been part of the Amazon culture since even before I joined. So, you know, I think that that part of it was the same. The things that were different for us is that we were building client software versus what most of AWS does, which is to build cloud services. So that piece of it was different. We had to innovate and invent a bunch of different things, everything from how are we going to distribute this software to what build system should we use?
37:40Because we can't use the internal build systems. We actually build this externally in GitHub repo and things like that. So there were a lot of different kind of things that we had to invent in order to just be able to kind of move quickly. But also, we also wanted to make sure that we did iterative development on this. So we didn't kind of wait until we had a completely working product before we kind of did some beta testing. We actually onboarded and worked with a number of our colleagues in the company who were willing to be guinea pigs for the early stages of development and really help us to define.
38:16And I talked earlier about the spectrum and development and how we iterated on that multiple times in the early stages of the product. And that wouldn't have been possible without leveraging the broader community of engineers inside the company. So that feedback loop, you know, like these nightly build groups, these canary testers, that's what really moved the needle and let you kind of move quickly. How did you operationalize on that and filter any kind of noise from like gold that you then acted on? With that, we were pretty frugal in our approach to this. We just set up a Slack channel, invited about 50 or 100 people, and said, okay, guys, we'll give you a nightly build.
39:00You'll be able to update it automatically. And then what we'd like you to do is just to dump all of your thoughts into this Slack channel. And then everyone in the team would go through the Slack channel every day and filter out all the important things we wanted to work on and make sure that we iterated on it and the cycle kind of went on and on every day after that. I love that. So it's like you're getting the tap in all these different feedback layers. And another layer that you talked about tapping into are folks like solution architects using QRO to build and deliver things. What kind of things did they teach you about the real-world usage that maybe that internal engineering feedback wouldn't have surfaced for you.
39:43Yeah, so as we progressed through the development lifecycle towards the later part of it where we had actually a reasonably working product, obviously it had bugs and things in it and those needed to be resolved. We actually expanded that initial group of 50 or 100 people. We expanded it to include not just engineers, but people in our solution architect team, in our sales organization, people who are working with customers and asked them to see how this would help them in their day-to-day jobs. So instead of just helping us to debug the product, they were actually using it for their day-to-day jobs and saying, okay, well, here's where it was useful for my day-to-day job, and here's where it wasn't so useful.
40:24And that also then helped us to understand, do we actually need to build a feature for that? Or is that shortcoming okay for the audience that we're targeting? And we went through that process in terms of trying to figure out, are we building the right thing for the right audience? We couldn't build everything for everyone, obviously, but we wanted to make sure that for the audience that we were targeting, we were not missing any edge cases on how the product could be used. And along the way with that, did any other power user stories that maybe seemed unlikely at first pop up or emerge as these different kinds of groups did get their hands on the tools for the first time?
41:03Yeah, I mean, we've had a lot of internal usage for what I would call large-scale production projects. I think at the beginning of this, you mentioned the S3 project. But that was super interesting. One of our very senior engineers in the company was part of this early group of adopters looking at the Kira product. And they were using it for their day-to-day job, which was to build large-scale components for S3s. And they would come back and tell us all the things that worked and all the things that didn't work. And we iterated, we improved. but ultimately they were able to build meaningful pieces of a new product launch that was part of the part of the the s3 service so we've had multiple examples of that inside the company where people have built some meaningful things for their uh for for different services in the company and and when then when it finally reaches this point where even the engineers that are building Kuro or using Kuro to build Kuro.
42:11You know, what was that moment like? What did that unlock, like culturally, just generally for like what it meant to get to that point? It actually happened pretty organically. So I mentioned the Slack channel earlier on where we just get people, you know, saying things. One of the testers at the time said, hey, you know what, when Kuro is doing a task using the specs, it can take, you know, five or 10 minutes to execute. I don't want to keep watching it do its work. I want to go and do something else. So is it possible for Kira to tell me when it's kind of finished, right? Finished the task. Oh, yeah.
42:48The notification. Yeah, the notification thing, right? So we looked at it and we said, yeah, you know, that's a lot of work. We have multiple platforms. It'll probably take us about three or four weeks of engineering work to do it. and one of the engineers on the team one afternoon had an hour or two i don't know why but had some time so so they they they plugged they play they plugged the requirement into kiro and said hey what would it take to build this notification system uh and it generated the spec for it it did all of the platform specific things like hey you have to do this on windows and this on linux and and this on mac it did the whole thing and we were able to build that whole feature in about two days.
43:29And it worked. And that was the kind of realization that, yeah, you know what? Actually, you can just add features and build things on Kiro without actually having to handcraft everything yourself. Do you have any kind of advice for other leaders at companies that maybe want to emulate the same kind of layered feedback approach and virtuous cycle, this virtuous feedback that you manage to type into, tap into to build something so quickly with such high impact? I think that one of the things that we noticed was that it doesn't just happen because you've got the mechanisms in place. You actually need to have the space for the engineers on the team to react to those mechanisms, right?
44:15So we didn't cram the engineers' days with task after task after task. We actually allowed them to be on Slack, engage with the customers, or they were internal users, but we called them customers, and get their inputs and have discussions with them, walk through how they were using it. Having the ability for your engineering team to do that and not just work on feature after feature, having the space and time to do that is super important. And those engineers enjoying that process is also super important because that's where the real benefit comes from is to get that input in real time. That's such an amazing call out because I think it's all too common for places to start with the impulse of creating the mechanism to send in the feedback to otherwise start the loop, right?
45:08But without necessarily giving the developers the same amount of space to stop and to listen and to pay attention to what they're building. And that's how you actually unlock the loop of that feedback. And as you've called out, you can't just have those mechanisms in place. And, you know, were there any other surprising things about Kiro along its journey that has really made it stand out for you, maybe against other projects at AWS that you've worked on before? were one of the differences and i've personally i've worked on a number of different service launches and and and developer tools over the years um one of the things that we got right in this in this uh product which uh which i think was really one of the the important uh success factors was that we uh we decided not to limit ourselves to what historically aws has done i'll give you a quick example.
46:06Typically, whenever services are built in AWS, they're built around an AWS account. So if you want to use one of our services, you need an AWS account. One of the things we realized early on was that, yes, we could do that with Kiro as well. But if we did that, it would require our customers to, first of all, create an AWS account if they didn't have one. So we made a decision early on to allow people who had Gmail accounts to use our product. Now that may seem like a small thing, but actually it was one of the larger, more meaningful decisions early on in the product. And I think if we hadn't have made that decision in the right way, we would not have had as much of a success because people would have been reluctant to create an AWS account just to try it out.
46:55And because of that decision too, do you think Kiro is positioned to maybe appeal to an audience that maybe traditionally hasn't been a developer or an AWS engineer? When we look at AWS overall, things like S3, DynamoDB, EC2, there's a certain audience that wants to use all of those things, right? Yeah. And if you look at developer tools more broadly, there is an overlap between developers who want to use EC2 and S3 and DynamoDB, but there's also in that Venn diagram, there's also a bunch of developers who just want to build a website or something like that, right? So we wanted to cater to both of those audiences to make sure that, you know, people who just want to build a website for whatever purpose and people who want to use EC2 and DynamoDB and S3, they are all able to use Kiro and all get the benefits of using Kiro.
47:50And that was the kind of important decision we wanted to make at the beginning. And for those people who want to use a website or want to build non-cloud applications, forcing them to create an AWS account or any cloud account seems like an overhead that they probably wouldn't be interested in doing. But they're all developers. So we wanted to just make sure that all developers could use it. Right. They're all developers. I love that realization and how profound that actually was for AWS as an organization to make that decision and act on. And I do think that speaks to the future of what development looks like and engineering being more accessible to more people.
48:28And I can see all sorts of technologists and knowledge workers leveraging the success of Kiro. You know, like you said at an earlier point in our call, you could come in with that one prompt, you know, make me this app and just see where it goes. And it's great at making the in-between, you know, conquering the spec and then actually making the plan and then executing on it bit by bit. For those that have a lot more intention, you can pack that all in too, and then use it to create something really specific and meaningful for you. So I think that's an exciting reflection on the tool itself and how robust it is and will continue to be.
49:05And I've had a lot of fun really digging into this with you, Amit. It's been a really fun conversation. And I appreciate you taking us on this journey about what this new coding experience is going to look like. And before we wrap up, where can our audience go to learn more about your work, but also to go experience Kiro since it is accessible to all? Yeah, so to learn more, just Kiro.dev. We also have a channel on Discord for people to provide feedback. So if you just want to hear what other developers are saying, you can go to our our Discord channel again you can find that on the website so yeah look forward to look forward to people trying it and giving us feedback and making it better amazing well we're going to include all of those notes including some supporting stuff for the things we discussed and you know if you listen to this and if you're a Kiro user or if you end up trying Kiro after this I'd love to hear from you I know Amit would as well so let us know your feedback raise your hand come find us on socials and continue the conversation on LinkedIn or in the comment sections below, wherever you're listening to or reading this.
50:09But thanks for joining us. That's it for this week's Dev Interrupted. We'll see you next time. And Amit, thanks again for coming on the show. Thanks. It was great talking with you.
From the publisher
What is "spec-driven development," and why is this structured approach the key to unlocking complex AI projects? We're joined by Amit Patel, Director of Software Development for Kiro at AWS, to explore this methodology. He explains why "vibe coding" in a chat window fails on multi-day initiatives: the AI (and the developer) loses context. Kiro solves this by turning requirements and design into a persistent, structured spec that acts as the agent's long-term memory, enabling it to maintain context and build sophisticated applications.
Amit shares the inside story of how his team at AWS built Kiro from scratch in under a year. He reveals their virtuous feedback loop with internal developers testing nightly builds and providing real-time feedback. This rapid iteration, which included six full revs of the spec experience, was so successful that the Kiro team famously "used the tool to build the tool," turning a multi-week feature into a two-day task.
LinearB: Your AI productivity journey starts here
Follow the show:
- Subscribe to our Substack
- Follow us on LinkedIn
- Subscribe to our YouTube Channel
- Leave us a Review
Follow the hosts:
Follow today's guest(s):
- Learn more and try Kiro: kiro.dev
- Join the Kiro Community: Kiro Discord Channel
OFFERS
- Start Free Trial: Get started with LinearB's AI productivity platform for free.
- Book a Demo: Learn how you can ship faster, improve DevEx, and lead with confidence in the AI era.
LEARN ABOUT LINEARB
- AI Code Reviews: Automate reviews to catch bugs, security risks, and performance issues before they hit production.
- AI & Productivity Insights: Go beyond DORA with AI-powered recommendations and dashboards to measure and improve performance.
- AI-Powered Workflow Automations: Use AI-generated PR descriptions, smart routing, and other automations to reduce developer toil.
- MCP Server: Interact with your engineering data using natural language to build custom reports and get answers on the fly.
