"It becomes quite difficult to have enough context and enough memory as an individual developer to remember what you did yesterday or two days ago... I forget what I told the agent to do three hours ago, right? So one of the things that we wanted to do was to solve that problem in a more structured way."
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.
Show Notes
- Learn more and try Kiro: kiro.dev
- Join the Kiro Community: Kiro Discord Channel
Transcript
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
[00:00:00] Andrew Zigler: 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.
[00:00:11] Andrew Zigler: Called Kiro and picture this. It's a tiny team inside of Amazon that starts from scratch and 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. a new approach called spec driven development, and today we're learning what it takes to reinvent the agentic coding experience. Amit, welcome to Dev Interrupted.
[00:00:43] Amit Patel: Thank you. Great to be with you.
[00:00:45] Andrew Zigler: Great. Well, we're really excited to dive into this with you. You know, I'm a Kiro user and I have, uh, uh, so much, you know, success I've had with the tools.
[00:00:53] Andrew Zigler: I'm really excited to learn more about where it came from and I think that, um, going back to my tool adoption this year, I, found [00:01:00] that early AI coding tools, they were great at quick wins. Uh, but it, it's struggling 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.
[00:01:17] Andrew Zigler: I think it's what we've all learned. So Kiro 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 Kiro?
[00:01:38] Amit Patel: Yeah, when we started out with Kiro, um, uh, it's probably more, uh, close to a year ago now. Uh, one of the things that we were looking at, um, was what are the problems that, um, 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, we. Talked to a lot of [00:02:00] developers inside the company.
[00:02:01] Amit Patel: Obviously we have a very active internal, uh, development, uh, infrastructure and, and, and uh, uh, 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, in the development lifecycle, uh, what kind of frustrations they were hitting and, uh, what they would like to see improved.
[00:02:22] Amit Patel: And at the time, the industry was also, uh. Improving things. For example, you know, introducing things like steering and rules, and other ways to guide the LLM to do what they needed it to do. so, you know, as the industry as a whole recognized that there are, there, there are limitations to what can be done in a simple chat window with just vibe coding. especially when. The problem to be solved is, um, a reasonable size problem, a meaningful problem. Uh, it becomes quite difficult to have the, have enough context and enough memory as a, as an individual developer to, to remember what you did [00:03:00] yesterday or two days ago.
[00:03:01] Andrew Zigler: Right.
[00:03:02] Amit Patel: what you told the agent, uh, uh, you know, uh, even, even three hours ago, sometimes I forget what I told the agent to do, right?
[00:03:09] Amit Patel: So, so one of the things that we wanted to do was to, to solve that problem in a more, uh, 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 it, we didn't feel it was enough to just kind of provide those things.
[00:03:29] Amit Patel: We, we felt that in order to build more complex, um. Projects in order to, uh, tackle harder problems, uh, which required multi-day initiative, um, we needed more structure. So that's, that's the, the sort of genesis of the, the product idea.
[00:03:45] Andrew Zigler: And how does Kiro keep that context alive between days and teammates? Because I completely agree with you about that ephemeral nature, that nature that happens in the chat. Maybe you don't remember what happened three hours ago, so, so how does Kiro [00:04:00] transform that ephemeral ness into something that lasts?
[00:04:03] Amit Patel: the concept we introduce is what we're calling spec driven development. And, and rather than remembering what the prompts were three days ago, what we're saying is, uh, we will, uh, kiro will allow you to, uh, essentially. Build a plan, a structure for your project or whatever work you want to do.
[00:04:24] Amit Patel: And it has three stages. So first stage is, and again, we, this is typical of any software development project, which is, hey, let's define what the requirements are. That's the first step. Then let's define what the design's gonna be for those requirements, and then let's figure out how we're gonna implement it in a step by step way, uh, and make sure that.
[00:04:44] Amit Patel: At every step we have made progress towards the ultimate goal and that we are not, uh, you know, um, introducing. Issues or regressions or whatever else, right? So those are the three stages of, of what we're calling spec driven and development. And what we've, what we've [00:05:00] built into the tool is the ability for people to plan complex things and then to have a very structured task list.
[00:05:06] Amit Patel: 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 gonna 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.
[00:05:29] Amit Patel: Kiro can also see what the requirements are. Kiro can also see what the design is, and so all of that context is available. On task six and seven and eight and 20, uh, as you go down that list. So, 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.
[00:05:49] Andrew Zigler: Yeah, and, and I want to call out the great part about Kiro two and, and how it captures that spec is, you know, this becomes like a, a really, our first class experience inside of the IDE [00:06:00] 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 des, the designing, planning, making sure you have a really clear structure. Because of how critical it is for it to work. And so what other guardrails or does Kiro have built in besides keeping the user on this structured flow? Um, are there other things that usually get baked into a spec that make it more robust out of the box? You know, how, how does it help the engineering leaders trust the, the end result that comes out of the IDE?
[00:06:34] Amit Patel: during the, the, the sort of requirements and, and design phases of the spec, um, the developer can actually ask, uh, for additional tasks to be done, um, by default. We're also in our structured approach, we're also doing things like, enabling the, the Kiro to generate. Um, unit tests for, uh, the [00:07:00] application or the feature that the, that the developer is trying to build.
[00:07:03] Amit Patel: But you can, you, as a developer, you can just ask Kiro to implement, either, um, architectural changes, like, you know, if you wanted to go in and say, Hey, for these requirements, I want you to, um, you know, have, uh, this kind of, uh, scaling. Um, uh, potential so that you know it, the, the application will be built for, for, for, for a scalability or whatever, whatever those requirements are.
[00:07:29] Amit Patel: You can, you can add those to the requirements or you can add them to the design, whether if they're functional, non-functional, and so on, and that will then generate the tasks. Um, that are necessary to accomplish those objectives. So there's a, a lot of things that Kiro does in itself in terms of things like unit tests and so on.
[00:07:46] Amit Patel: There'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 gonna be met by the ultimate, uh, output from Kiro.
[00:07:56] Andrew Zigler: Yeah. And, and what do you think people should really care about when [00:08:00] evaluating these AI tools and these new IDEs? a, what does, should a leader prioritize about what matters to their team with these tools?
[00:08:09] Amit Patel: there are a number of things that we would. Uh, a leader should, should consider. One of them obviously is what, what is the priority for their organization? Typically, those, those things revolve around having their engineers be more productive, uh, and that the, the, the output from these tools is actually, uh, maintainable and it is, uh, production ready.
[00:08:33] Amit Patel: Um, and also that the, the developer ergonomics are there so that their engineers will enjoy using these tools because. If the, tool is good, but it isn't us, uh, you know, enjoyable to use or it causes a little paper cuts or frictions, um, it can be really frustrating and reduce productivity. So ultimately this is about having productivity increases in your organization and, uh, making sure that the [00:09:00] output from these tools is something that is maintainable and reliable and, You know, operationally excellent so that it doesn't, uh, cause a lot of, um, issues after you've shipped it to production
[00:09:13] Andrew Zigler: Right. Cogens just one part of the
[00:09:15] Amit Patel: Yeah.
[00:09:15] Andrew Zigler: Does it cause issues? Downstream. I, I also love that you called it the developer ergonomics, like that experience, that joy of creating software with the tool and, you know, to, to get there. You know, you, you told me that you went through six iterations of the spec experience to make it, make it as good as it is now, and to meet the developers where they, they need to be met right now.
[00:09:36] Andrew Zigler: So what did that journey feel like? You know, did it feel like overkill doing six iterations or did it feel like exactly right. Um, in the amount of iterations to get where, where you got.
[00:09:46] Amit Patel: Yeah, I mean, I, I think our, our approach was to make sure that we had something that would be useful and easy to use. Deliver the productivity that developers wanted. And [00:10:00] we didn't know at the beginning of the journey whether it would take us one rev or six revs. Uh, we just didn't know. We just wanted to make sure it was right.
[00:10:07] Amit Patel: Um, what we found as we kind of went through this, uh, because we kind of worked with a lot of internal developers to make sure that, you know, we validated our, our assumptions about what would work and what wouldn't work, uh, what we found is that. People had ideas on how we could improve things. Um, and every time we felt that those ideas would meaningfully improve things for our customers, we, we went back to the drawing board and we tried to incorporate those.
[00:10:35] Amit Patel: It did take us six attempts to get there. I think it was worth the journey because, um, um, what we ended up with, um, actually I don't think we could have got in one shot. I mean, it was, uh, it, it really required that number of iterations to get to where we landed.
[00:10:51] Andrew Zigler: Yeah, I think it speaks also to the exploration phase that everyone is in. You know, nothing's more exploratory than the actual, uh, you know, a agentic coding experience [00:11:00] 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, and how that could translate it into specs itself because, uh, 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.
[00:11:22] Andrew Zigler: So, How does, um, AWS evaluate spec quality and, 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
[00:11:41] Amit Patel: Yeah. So one of the things we, uh, wanted to do was to balance the, the ability of developers to change things as in how they needed with the ability for the LLM to actually understand the spec when it came out at the end of the process. Right. So, um, and because the, [00:12:00] the. The LLM is by nature, non-deterministic.
[00:12:04] Amit Patel: The less ambiguity you give it, the, the better the output will be, right?
[00:12:09] Andrew Zigler: Yep.
[00:12:09] Amit Patel: so we chose to use ES format. Uh, it's. Sort of, I, I won't go deep into that, but you know, people can look it up. We used ears format so that it provided some structure. then enabled, uh, the developer to either use the, the normal chat window to iterate on the design and the requirements.
[00:12:29] Amit Patel: Or if they wanted to, they could go directly into the markdown files, um, for requirements in design and edit those directly. And then. Ask the LLM to generate the, um, uh, the, the task list based on their edits. So that provides enough flexibility for people who either directly want to edit the markdown files, uh, or who want to use the LLM to make the changes that they wanted to make.
[00:12:54] Amit Patel: But we have. Set it up in a way that you can iterate with the design and [00:13:00] with the, uh, 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 lists, that ultimately comes out. So it was super important to make sure that you.
[00:13:14] Amit Patel: We, uh, we enable 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. They'll generate, that will generate a whole bunch of requirements. you can then clarify it and say, Hey, no, I don't want web app. I want to. Build it using Python or whatever, I don't know.
[00:13:33] Amit Patel: Um, and, and, and that's how you iterate with the, with the, with the requirements. So a lot, a lot of the times people just go with the one shot and generate the, the requirements, generate the design, generate the, the, the task list. And then after it's gen, you know, built the first version of the feature or the first version of the app, then they go and say, okay, now I wanna refine it.
[00:13:52] Amit Patel: Now I wanna do something else. So, so you, you could choose to do it in either way. Um. Um, but that control is with the, with the [00:14:00] developer.
[00:14:00] Andrew Zigler: And since that control is the now the, the superpower, the taste that the developer brings and how they use these tools. It's also the new kind of skillset and the new le layer in which, you know, engineers operate on they're decision managers, um, in, in this world. And do you think we're heading towards a world where.
[00:14:21] Andrew Zigler: Um, 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, getting on the same page about that is more important than what happens downstream or maybe equally important.
[00:14:41] Amit Patel: I think that it's actually better to clarify that, 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. So [00:15:00] even before AI teams would regularly do design review, so they would have a design doc and they would review the design doc and they would go through that, right?
[00:15:07] Andrew Zigler: Yeah.
[00:15:09] Amit Patel: 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, you can even print it and, and, and have a meeting and talk about the design that the, that was generated by the tool or you can collaborate, in front of a screen and just.
[00:15:28] Amit Patel: Edit the design together. So, so I think it doesn't take away the normal software development best practices. You know, if you have a project that you're working on, it's meaningful, you've generated requirements, you've generated designs for it, um, I would expect, uh, that design to be reviewed with the team and, and, and, uh, you know, it's iterated and worked on.
[00:15:49] Andrew Zigler: Yeah, no, you make a great call out here and it's actually one shared by many great minds at at at some amazing companies like your own that we've speak, been speaking with around how large companies are [00:16:00] using, you know, these new to. Coding tools and all of them equally and rightfully, call out just like you yourself, just did that, you know, ultimately it comes down to having best practices.
[00:16:09] Andrew Zigler: It's a force multiplier for what your organization is already doing, and if you have these great, uh, rituals and processes and support that allows your developers to ship great software already, then you're gonna have a lot of success. Bringing AI into that world. If you don't have those practices, you're gonna find it rapidly misunderstanding and misdirecting you.
[00:16:28] Andrew Zigler: So, um, I think that's totally right to clarify and call out and kind of like a great part of what, what makes the tool so flexible too, is it meets people where it
[00:16:36] Amit Patel: Yeah, and typically, you know, on a reasonably complex project, it would take an engineer. Maybe 2, 3, 4 days to write a design doc for it. Uh, 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, so that's the, that's the benefit, right?
[00:16:53] Amit Patel: It's, it's not, um, it's not circumventing some of your regular processes just getting you there quicker.
[00:16:59] Andrew Zigler: [00:17:00] So going back to like the genesis of Kiro, um, you, you, you, you tell the story like Kiro has been launched as a startup inside of Amazon. You know, what did, what did you do differently? What did, how did your team operate that was maybe different from a quote, normal AWS team that gave you that startup level?
[00:17:17] Amit Patel: Yeah, I mean, our fir first thing to say is that, uh, a lot of am uh, the AWS, um, 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. So, uh, in, 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, of small teams moving fast and being able to implement things, uh, based on customer needs has been part of the Amazon culture since even before I joined.
[00:17:49] Amit Patel: So, uh, you know, I, I, I, I think that that. That part of it was the same. The, the, the things that were different for us is that we were building client software, versus what most [00:18:00] of AWS does, which is to build cloud services. So, so that piece of it was different. Um, we had to innovate and invent a bunch of different things.
[00:18:08] Amit Patel: Everything from. How are we gonna distribute this software to, um, uh, what build system should we use? Because we can't use the internal build systems. We, we actually, build this, um, externally in, in GitHub repo and things like that. So there's, there were, there were a lot of different kind of.
[00:18:25] Amit Patel: Things that we had to invent in order to just be able to kind of, uh, move quickly. but also we, we also wanted to make sure that we did, iterative development on, on this. Uh, so we didn't kind of wait until we had a completely working product before we kind of did some beta testing. We actually on onboarded and worked with, uh, a number of our colleagues in the company who were willing to be Guinea pigs for the early stages of development and, and really help us to define, and I, I talked earlier about the spec driven and development and how we iterated on that multiple times in the early stages of the product,
[00:18:59] Andrew Zigler: Yeah.
[00:18:59] Amit Patel: that wouldn't [00:19:00] have been possible without leveraging the broader community of engineers inside the company.
[00:19:05] Andrew Zigler: So that feedback loop, you know, like these nightly build groups, these canary testers, that that's what really moved the needle and let you, um, kind of move quickly. How, how, how did you operationalize on, on that and filter any kind of noise from like gold that you then acted on,
[00:19:20] Amit Patel: with that, we, uh, we, we were a pretty, uh, sort of, um. Frugal in our, in our approach to this. We just sort of set up a Slack channel, invited about 50 or a hundred people and said, okay guys, you know, uh, we'll give you a, we'll give you a nightly build. You'll be able to update it automatically.
[00:19:38] Amit Patel: And then what we'd like you to do is just to, dump all of your thoughts into this Slack channel. And, 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, uh, and, you know, make sure that we, uh, we iterate on it.
[00:19:56] Amit Patel: And, and the cycle kind of went on and on every day after that.[00:20:00]
[00:20:00] Andrew Zigler: I love that. So it's like you, 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 Kiro to build and deliver things, you know, at, at what, what kind of things did they teach you about the real world usage, um, that maybe that internal engineering feedback wouldn't have surfaced for you?
[00:20:19] Amit Patel: Yeah. So we, um, as we progressed through the development lifecycle towards the, towards the later part of it where we had actually a, a, 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 a hundred people.
[00:20:34] Amit Patel: We expanded it to include not just engineers. Uh, people in our, solution architect team in our, uh, uh, sales organization, people who are working with customers and ask them to see how this would help them in their day-to-day jobs. So what that, instead of just helping us to debug the product, they were actually using it for their day-to-day jobs and saying, okay, well.
[00:20:56] Amit Patel: Here's where it was useful for my day to day job, and here's where it wasn't so [00:21:00] useful. And 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, we went through that process in terms of trying to figure out, uh, are we building the right thing for the right audience?
[00:21:17] Amit Patel: 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.
[00:21:27] Andrew Zigler: And a 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?
[00:21:39] Amit Patel: Yeah, I mean, we ha we've had a lot of, internal usage for. What I would call, uh, large scale production projects. I think at the beginning of this you mentioned, uh, the S3 project, um, that, that was super interesting. One of our very senior engineers in the company was, uh, [00:22:00] part of this early group of, uh, adopters looking at the Kiro product.
[00:22:04] Amit Patel: And they were, you know, they were using it for the day-to-day job, which was to build, large scale components for S3 and, um, uh, they would, they would come back and tell us all the things that worked and all the things that didn't work. And we, we, we improved, uh, but ultimately they were able to build meaningful pieces of, uh, a new product launch that was part of the, uh, part of the, the S3 service.
[00:22:29] Amit Patel: So, um, 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.
[00:22:39] Andrew Zigler: And, and, and when, then, when it finally reaches this point where even engineers that are building Kiro are using Kiro to build Kiro.
[00:22:47] Amit Patel: Yeah.
[00:22:47] Andrew Zigler: You know what? What was that moment like? What did that unlock like culturally, just generally for like what it meant to get to that point.
[00:22:54] Amit Patel: it actually happened pretty organically. So we, I mentioned the Slack channel earlier on where we just get peoples, [00:23:00] you know, saying things. One of the, one of the testers at the time said, Hey, you know what, um, uh, when Kiro is doing a, a task using the specs, um, it can take, you know, five or 10 minutes to execute.
[00:23:11] Amit Patel: I don't wanna keep watching it, do its work. I wanna go and do something else. Uh, so, uh, is it possible for Kiro to tell me when it's kind of finished? Finish the task.
[00:23:23] Andrew Zigler: Oh yeah, the, the
[00:23:24] Amit Patel: Uh, the notification thing. Yeah, the notification thing. Right. So, uh, we, we looked at it and we said, yeah, you know, that's a lot of work. We have multiple platforms.
[00:23:32] Amit Patel: It'll probably take us about three or four weeks of engineering work to do it. And, uh, 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 plug, they plugged the requirement into Kiro and said, Hey, what would it take to build this notification system?
[00:23:52] Amit Patel: 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 [00:24:00] this on Linux and, and this on Mac, and did the whole thing. And we were able to build that whole feature in about two days. and it worked and that was the kind of realization that, yeah, you know what, actually you can just add features and build things on, on, on Kiro without actually having to handcraft everything yourself.
[00:24:18] Andrew Zigler: And do you have any kinda advice for other leaders at companies that maybe wanna 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?
[00:24:33] Amit Patel: I think that, um, one of the things that we note noticed was that it doesn't just happen because you've got the mechanisms in place. Uh, you actually need to have the space for the engineers on the team to react to those mechanisms, right? So, we didn't cram the engineer's days with.
[00:24:54] Amit Patel: Task after task after task, we actually allowed them to be on Slack, [00:25:00] engage with the customers, or, you know, they were internal users, but we called 'em customers and, and get their, uh, inputs and, uh, have discussions with them, walk through how they were using it, having the ability for your engineering team to do that.
[00:25:15] Amit Patel: And not just work on feature after feature. Having the space and time to do that is super important. And, and those engineers, uh, enjoying that process is also super important because that's where the real benefit comes from, is to, is to get that input in real time.
[00:25:31] Andrew Zigler: Such an amazing call out because I think it's all too common for place, places to start with the impulsive of creating the mechanism to send in the feedback to, to, to, to otherwise start the loop right. But without necessarily giving. the same amount of space to stop and to listen and to pay attention to what they're building.
[00:25:51] Andrew Zigler: And that's how you actually unlock the loop of that feedback. And, and as you've called out, you can't just have those mechanisms [00:26:00] in, place and, you know, were there any other surprising things about Kiro? It's along its journey that has really made it stand out from you, for you, uh, maybe against like other projects at AWS that you've worked on before?
[00:26:13] Amit Patel: one of the differences and I've, I've personally, I've worked on a number of different service launches and, and, and, uh, 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, the important, uh, success factors was that we, uh, we decided not to limit ourselves to what historically AWS has done.
[00:26:40] Amit Patel: I'll give you quick example. Typically, whenever services are built in AWS, um, they're built around an AWS account. So, uh, if you want to use one of our services, you need an AWS account. Uh, one of the things we realized early on was that yes, we could do that with Kiro as well, but if we did [00:27:00] that, it would require our customers to first of all, create an AWS account if they didn't have one.
[00:27:05] Amit Patel: So we, uh, made a decision early on to. Allow people who had, uh, Gmail accounts to use our, 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.
[00:27:31] Andrew Zigler: 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?
[00:27:40] Amit Patel: when we look at AWS overall, things like S3, DynamoDB, uh, EC2, there's a certain audience that wants to use all of those things, right? Um, and. If you look at developer tools more broadly, there is an overlap between developers who want [00:28:00] to use EC2 and S3 and DynamoDB, but there's also, in that Venn diagram, there's also a bunch of developers who just wanna build a website or something like that, right?
[00:28:09] Amit Patel: So. we wanted to cater to both of those audiences to make sure that, you know, people who just wanna build a website, uh, for, for whatever purpose, and people who want to use EC2 and Dynamite DB and and and S3, they are all able to use Kiro and all get the benefits of using Kiro. Uh, and, and that was the kind of, uh, important decision we wanted to make at the beginning.
[00:28:30] Amit Patel: And, and, you know, for those people who. Wanted to use a website or want to use, build non-cloud applications, uh, 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.
[00:28:48] Andrew Zigler: Right. They're all developers. I, I love that realization and how profound that actually was for AWS as an organization to, to make that decision and act on it. And I do think that speaks to the future of [00:29:00] what development looks like and engineering being more accessible. To more people. And I can see all sorts of technologists and knowledge workers leveraging the success of Kiro.
[00:29:09] Andrew Zigler: You know, like you would said in the at, at an earlier point in our call, you know, 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, uh, specific and meaningful for you. So, um, I think that's an exciting reflection on the tool itself and how robust it is, and we'll continue to be. Um, and I, I've had a lot of fun really digging into this with you, Amit.
[00:29:44] Andrew Zigler: It's been 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 [00:30:00] accessible to all.
[00:30:01] Amit Patel: Yeah. So, uh, to learn more, just Kiro Kiro.dev. We also have a, a channel on discord for people to provide feedback.
[00:30:09] Amit Patel: So if you just wanna. Hear what other developers are saying, you can go to our, uh, our Discord channel. Again, you can find that on the, on the website. So, uh, look forward to look forward to people trying it and giving us feedback and making it better.
[00:30:24] Andrew Zigler: Amazing. Well, we're gonna include all of those notes,
[00:30:26] Amit Patel: Yeah.
[00:30:27] Andrew Zigler: 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. Um, but 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.
[00:30:53] Amit Patel: Thanks. It was great talking with you.
