In this New Builders conversation, Kate Holterhoff speaks with Clare Liguori, Senior Principal Software Engineer at AWS, about Kiro. They discuss Kiro’s Vibe and Spec modes, and how these both factor into better coding practices and outcomes for developers. Clare explains the importance of requirements in software development, the collaborative nature of spec-driven development, as well as Kiro’s roadmap.

This is a RedMonk video, sponsored by Amazon.

Links

• LinkedIn: Clare Liguori
• Bluesky: @clare.dev‬
• For more information visit Kiro.dev

Transcript

Kate Holterhoff
Hello and welcome to this Redmonk conversation. My name is Kate Holterhoff, Senior Analyst at RedMonk. And with me today, have Clare Liguori, Senior Principal Software Engineer at AWS. Clare, thanks so much for joining me today for this new builders conversation.

Clare Liguori
Hi, thanks for having me.

Kate Holterhoff
Well, I’d like to begin with just getting a little bit of your background. Can you tell me what you do at AWS?

Clare Liguori
I’m a senior principal engineer at AWS in our agentic AI organization. So I focus on all things developers and AI agents. Most recently I’ve been involved in the launch of Kiro, our coding assistant IDE, and Strands, our open source agent framework.

Kate Holterhoff
well, I am super excited to talk to you about Kiro. I have used Kiro. I love it. It’s a lot of fun. I talk a lot about vibe coding here, So it’s very much top of mind for me. But I’d love to hear your perspective on maybe let’s just begin with what is

Clare Liguori
Kiro is an agentic IDE which enables you to develop code in two ways. One is, well really three ways. One, you can use it as an IDE, just like any other IDE, but you can also use it for vibe coding, so chatting along with an AI as kind of your peer programmer and developing code together. Or you can use it in what we call spec-driven development mode.

where you really start out by defining requirements for your project, your application, and working with the AI through defining requirements, defining technical design, defining tasks that can then go and be implemented by the AI and you review that code.

Kate Holterhoff
Awesome. Yes. And that has been my experience with it when I bring up the IDE, I see the two boxes asking me whether I’d like use the vibe mode or use the spec mode. I tried them both. And so I like that it engages me in that way. this is such a new

Clare Liguori
Mm-hmm.

Kate Holterhoff
way of going about the work of development that, you know, it’s requiring us to think a little bit more about what sort of engineer we’re going to be that day.

Clare Liguori
And it will also try, you pick Vibe and you’re starting in a conversation that seems like you’re asking it to do kind of a big project, you say, hey, I wanna build a, I don’t know, a YouTube-like website, it might tell you, hey, that might actually work better in spec mode, so let’s switch over to that.

Kate Holterhoff
so the human doesn’t even need to make all the decisions, especially when it comes to the agent experience in terms of like, how the AI is interpreting your prompt.

Clare Liguori
Yeah, we find that with anybody who’s used an AI coding tool which is almost everybody at this point has at least tried it. We find that that vibe code, that chat-based experience is just more familiar. You’re very likely to start out with that. That’s what you’re familiar with. And so we like to give people the opportunity to start with what they’re familiar with, but then move into spec-based development when it might be more appropriate for the task at hand.

Kate Holterhoff
right. So I want to talk about both of these modes. Maybe let’s begin with the vibe mode. I think it’s interesting that Andrej Karpathy, when he coined this, he has since sort of taken a step back and called it now context engineering. I actually prefer vibe coding for most cases. I think it’s a little bit more fun. think it also…

I just, the marketing appeal around it, mean, everybody knows what it is immediately. If you say context engineering, it’s a little bit less clear at this point. I don’t know what’s going to happen, you know, six months in the future, but I’m interested in why it is that the Kiro team decided to go with vibe mode.

Clare Liguori
It is a more familiar term, but it’s also more fun. You can see in the Kiro branding and in the experience in the editor with the ghosts kind of floating around, we did want this to be a fun experience. There’s, I think a lot of worry out there about using AI for your job, whether it’s going to take away part of your job, take away the fun part of your job. hear that from…

from developers coming into a product that talks about spec-based development can feel a little bit like we’re going back 20 years to writing requirements docs by hand and getting them reviewed. And someone even said, at that time I was writing Fortran on gridded paper. But we wanted to make sure that it felt fun. This isn’t the dreary days of programming coming back. It’s a fun experience and Vibe captures that as well.

Kate Holterhoff
So let’s talk about the spec-driven mode. So I am interested in how you chose the term spec because it does seem to have similar connotations with a requirements doc. Maybe sounds a little bit more technical, but I think that there’s a lot of advantages to, I guess, reaching that technical audience to, walk that razor’s edge between the all-fun vibe mode.

Maybe we could compare it to how Cursor has YOLO mode or something. That’s certainly a way of doing AI assisted coding. And then you’ve got this spec with Kiro. And so I’m interested in the decision to go with spec-driven development as opposed to another way of framing this general idea. How did that decision come about?

Clare Liguori
Yeah, we did test a lot of words with users and we just kept coming back to spec. We actually started using the word specification very early on. We started talking about not necessarily a new IDE, but a new style of programming more than a year ago. And there were a couple of things that were happening at that time.

Kate Holterhoff
All funny.

Clare Liguori
one was that we were starting to see folks really struggle with vibe mode, so to speak, in terms of validating whether the AI had done its job, right? It could, you could tell it, go build me this application or go build me this feature, but it didn’t really necessarily have, in AI terms, what we call a reward function or, some way of validating that it had actually done what you wanted it to do.

And part of that was because when you tell Vibe Mode to do something, it’s very imperative. You say, go change the application in this way, as opposed to specifying your intent for what you want the application to do. And when you specify what you want the application to do, what your requirements are, those are testable. Now, suddenly you can build unit tests around it, you can build integration tests around it, and the AI can actually self-validate that it’s actually met your requirements

simply by really moving from kind of an imperative way of telling the AI to go do something to a declarative way of telling your intent. The second one was that there was a researcher at King’s College, London, who did a blog post, his name is Laurence Tratt, around this time last year. And he talks a lot about the nature of software development. And he had this great quote in this blog post where he talks about

Software development has a circular specification problem that you always have to almost entirely build an application before you actually know what you want it to be, what you want that application to do. And we’ve learned this a lot in the industry, right? We went from waterfall where we got all the way to shipping a software product before we realized, the requirements we wrote way at the beginning were not right.

We moved on to Agile, but that’s actually very difficult with the cost of software development itself. It takes months and months and months for you to come up with some kind of working steel thread application you can actually see and say, actually I want this to work a little bit differently for this use case. And so one of the ideas behind spec-driven development was that,

you would actually be able to iterate on the requirements themselves of an application so much faster because you can get to a fully working application in say an hour, writing up a specification or having the AI write it from your instructions and then having it generate all the code. And suddenly you can now go back all the way to the requirements within an hour and start tweaking what you want. And we started to see a lot of…

A lot of people trying to do this in vibe mode, but there was so much ambiguity when you start out, you know, that the example of I want to build a YouTube clone app, there’s so much ambiguity of what you actually want it to do other than copy and paste what this experience looks like, that you start to kind of iterate and dive deeper into what it is you actually want that application to do. So there’s almost this very…

reflective nature to it where you say, what is it that I actually want this to do now that I’m playing around with this and it doesn’t actually quite feel right? How do I want it to be different from what I said before or how do I want to add more requirements and more detail to what I want this application to do?

Kate Holterhoff
I love that idea of comparing it to Waterfall and Agile because the sense that I get when I read not only what developers are saying about spec-driven development, but also, yeah, from some of the more official channels from AWS is that it is about shifting left, that it is about making sure that these design decisions are happening earlier and that that’s going to be so important to AI-assisted coding. Is that accurate?

Clare Liguori
Yes, and I would say it’s also that these things were always probably pretty important to do early on, right? We still do, we still write requirements at Amazon, we write our PR/FAQs. We still write design docs, all of us, even though we’re now in this, you know, non-waterfall kind of agile scrum world. But now it’s so much easier to see what the implications of those are.

very early on, very quickly. I think that’s really the power of AI is that there’s almost this, you can almost start doing prototype driven development, right? Where you bring the prototype of what the AI generated for you from the first time that you write these requirements to see what it looks like. And so the iteration cycles are going to be so much faster. Whereas, today if you write a

big technical design doc, it’s gonna take months and months for a team of people to write that much code before you realize, early on, we made an assumption that was false or something, or this isn’t actually going to scale. And so that’s really the power of making sure that you don’t skip that step, right? That you have something to come back to, a document to come back to as you’re validating all these assumptions as you keep going down various paths with the AI on what the code actually looks like.

Kate Holterhoff
Yeah, that makes a lot of sense to me. And when I hear folks talk about their, evolving feelings about AI assisted coding, what I see repeatedly is folks saying that it’s not really about generating code, it’s about the people. It’s about meeting the needs of the stakeholders, right? And I feel like shifting the focus to that specification is a part of that, recognizing that it was never about how many lines of code we’re generating, it’s about… Yeah, people making sure that you’re actually doing what they need.

Clare Liguori
Yeah, you want to build the application that best meets the needs of your customers, right? And because it has been so manual, time consuming to write code, it’s been really hard to validate that you are indeed writing an application that’s meeting your needs of your customers. And I think we’ve all seen projects that go…

way over time, way over budget because we find out four months later that, our customer needs have changed in that time, or we actually made a false assumption at the beginning. So I think that spec-driven development is gonna be really interesting moving forward because today in Kiro, it’s a very individual experience. We mostly envision an individual developer

taking on a project within their team and using Kiro and spec-based development to implement that feature. But I think what’s going to be really exciting is the possibilities for collaboration across many stakeholders, like you said, across a development team, across product managers and user research folks and user experience folks to all kind of collaborate on what do we want this application to be, what are the customer needs that we want to meet.

Kate Holterhoff
And I feel like we’ve done a good job talking about the why here, but maybe we spent less time on the what. So would you mind describing what is spec-driven development and how does Kiro actually perform that?

Clare Liguori
So, spec-based development is where instead of starting from the code, starting to write code and write tests, you start from standing back and saying, what are the requirements for this application? That could be functional requirements, it could be user stories, it could be pseudo code for an algorithm that you need to be included.

mock-ups from a UX designer or from your own napkin, mock-ups that you drew, all coming together to kind of define what do you want the application to do and from that the code gets generated. In Kiro, we split it up into three different phases that we found works really well. The Kiro team actually builds Kiro with Kiro. And so they use spec-based development to, or spec-driven development.

to build parts of Kiro. And so that, these three steps really came out of them, finding what worked for them as a development team. So first is that you give at a very high level, kind of conversationally, what do you want to build today? What is your project? What’s your feature? What’s your application? And from that kind of very ambiguous statement, probably, Kiro is going to generate a requirements doc.

And this is generally in the kind of old school requirements docs language. When the user clicks on the button, then the product shall open a modal. But what we found is that that’s actually really helpful language for both the model and the person. It’s very boring to write as a person. So you have the AI write it and then you kind of review it. But it’s really valuable as…

as language for the model because now it can take that and do behavioral driven tests. So we’ve all seen unit tests that implement that kind of language. When this happens, then that should happen. And that’s all that the requirements doc is really trying to capture. But it will also capture different user stories if you have different types of interactions, things like that. And you can go and review that. You can add your own, or you can simply chat with

Kiro and say, actually, you’re not really capturing what I meant. Here’s actually what I meant, and it’ll go and rewrite the doc. So once you’re happy with that, it’ll move on to the second phase, which is technical design. This goes into what’s the architecture? What is, is this something that’s going to run in the cloud? Is this a command line utility? Is this a microservices application? Does it use specific cloud services? How is the code base going to be laid out?

And that all helps in terms of how it’s going to lay out the code. What are the different tasks that it’s going to do? What kind of research is it going to do? You can add in MCP servers into Kiro so it can start gathering knowledge and information about your resources that are out there. And then finally, once you’re happy with that, it’s going to move on to the task list. And the task list is really great because what we found

pretty much broadly in the industry with vibe coding is that these AI models do best when given kind of bite-sized tasks that they can go and implement independently. Things like something that can be tested with a unit test, going and adding a class that does XYZ. So Kiro’s gonna generate out the task list that’s going to be.

roughly the size of complexity that an AI model can do on its own of generating code. What’s useful then is for you to go through and say, which of these things do I actually need? Sometimes models will, do you want to do a lot of work? It’s what I tend to tell people. It’ll give you kind of the…

the gold standard of software engineering maintainability and testability. It’ll write a whole bunch of integration tests. It’ll write a load test. Some projects require that and some don’t. So you can start to modify the task list or ask Kiro to modify the task list. But then what I really like about the task list is that you can send it through what we call auto mode where it’s just gonna implement all of the tasks

one shot and then you review all the code at once. But I like to actually do it task by task. So you can run individual tasks in that file. And then that’s really useful for steering because in all of these cases, there’s always room for ambiguity of what’s in your head versus what you have actually told Kiro. That’s often the hardest part for folks is pulling out what you already have in your head.

onto the screen, into the IDE. So doing it task by task, I get smaller chunks of code to review, which is always nice for me. And then you can also tell it, steer it until it’s, you’re happy with the results of that one task and then move on to the next. So that really gives you the best results. We found that going through these three different steps, especially for complex projects, complex features,

more than just write this function for me in vibe mode, gives you the best results that are gonna be pretty close to production because you’ve gone through all of this kind of thinking ahead of time of what are the requirements and what is the technical design? You can get into observability, what services do you use for metrics and logs and traces? And then you get to a fully testable code base that’s maintainable at the end.

So it gives you much better results even though it’s a lot of kind of cognitive load at the beginning to think through what you really want as opposed to getting right into the code, which is kind of our habit as engineers.

Kate Holterhoff
That is super helpful. And just in terms of brass tacks around this, what model does Kiro use?

Clare Liguori
You can select Claude Sonnet 3.7 or 4.0 in the product today.

Kate Holterhoff
Okay, awesome. And I think what has been so remarkable for me using Kiro in the spec mode has been the fact that yeah, these large language models fill in the gaps of, I have this idea, but they’re gonna take care of the boring part of writing out each of these different tasks, which becomes a little bit repetitive. It’s a little bit dry, but it’s absolutely necessary.

So I have a couple sort of related questions to this. The first one is, think when people hear spec-driven development, many are going to think of test-driven development too. So what is the relationship of tests to these specs?

Clare Liguori
Yeah, I thought about that a lot early on because, know, test-driven development just didn’t really take off. I have been a fan for a long time. I know, I I’ve tried to get so many teams to do it and often what I see is that they’ll do it while I’m on the team and then it’ll kind of die off after I leave the team. But with spec-based development, you know, really,

Kate Holterhoff
Blasphemy.

Clare Liguori
when you think about writing tests, you are trying to capture what is the desired behavior. So many of us write tests in kind of a behavioral style but it’s been so verbose, right? You’ve had to do it in code and in comments sometimes, and it’s very difficult to think at that level of specificity about

the very micro behavior of the code base before you’ve even written the code base. But one of the things that Kiro helps you with is one, thinking at maybe a bigger picture of what is the behavior that you want. And you end up with test-driven development at the end of that because you have specified what’s the high level behavior. And then in the test design, you might even have a bit of a class structure going on.

how is the code base going to be laid out? Where are the different pieces of functionality that need to be tested? And then Kiro was really easily able to translate those requirements, behavioral definitions, and the code structure to unit tests that capture that behavior that you wanted initially, but kind of drill down into that individual function level, class level.

behavioral type unit tests. And so without really having to actually write the tests, which I’ve heard a lot of engineers don’t like to do, you end up with this very testable, test-driven code base. And what you’ll see in Kiro a bit, because it’s able to actually compile your code and run those tests, it will actually try to self-correct and say,

these tests are failing, but this links back to a behavior that you wanted. So it must be that the code is wrong. So I need to go update the code to make sure that it matches the behavior. And so it’s really interesting to see it self-correct, go into this kind of reflective loop of, I need to change this because this specific test failed.

Kate Holterhoff
I have many thoughts on TDD myself. So I love digging into some testing as part of the requirements. The other question that I have around these specs is how they overlap with writing documentation. Because it seems like when I have looked at the specs that I’ve created, they give me a long way toward describing what the app actually accomplishes.

Clare Liguori
Thank

Kate Holterhoff
And so I’m wondering if that’s something that other users have noticed as well.

Clare Liguori
I think that specs today have a similar problem to any documentation about a code project today, which is that it gets out of date fairly quickly. So today in Kiro, it really only goes one way. And as soon as you start changing the code under the hood, the spec is out of date. One thing that I do think that we’ll get to is this…

kind of auto updating. So you can actually use a feature in Kiro called hooks, which allows you to kind of personalize and automate your IDE experience. So you could say something like, anytime I change the code in this directory, go and update the spec to make it reflect what’s actually happening now. Because otherwise it’s the same as any human written documentation or design doc, right? I have so many.

technical design docs that no longer reflect reality. We also have a feature called steering docs, is really, which is also really helpful for documentation. One common problem that I see over and over again is that we hire an engineer to a team and we throw them into the code base and they have no idea what they’re looking at. Right? And so they look at our project documentation, which is of course out of date.

But steering docs are effectively a summarization of the repository that you have opened up in Kiro. And that can serve two purposes. One is it’s really good information for the model to have an understanding of what is this application that I’ve been opened up into? What does it do? What is the structure of the code? That’s really good kind of overall steering information as you start to make.

more changes with Kiro through Vibe or spec-based development. But I’ve actually also really found it useful for myself, someone unfamiliar with a code base, it’s really good information for me too as kind of an overall, just information about the code base, kind of introduction to that code base that the model’s gonna use, but I can also use as well. And that’s another thing that has to be kept up to date. You can do it with agent hooks, but hopefully I think in the future we’ll… get to a lot more of keeping those things up to date so you can actually use them as source of truth.

Kate Holterhoff
That is awesome. I love that bit about the roadmap. I’m wondering if you can share anything else about the roadmap. What else is Kiro looking to do in the future? Or even just more broadly, what are you anticipating as next steps in vibe coding and spec-driven development for the industry?

Clare Liguori
I think for the industry, certainly thinking about collaboration, especially across stakeholders, like we talked about earlier on specs, I think that the more that you can have more of those voices in the specification, that’s going to be the best outcome at the end, right? We’ve been talking a lot about how specs give you a better kind of code base at the end, right? Very testable.

aligns with the requirements that went in, very maintainable. But I think also, but it doesn’t really talk to, you what’s the quality of the product itself at the end. And so I think having that collaboration on those requirements is going to be very important for the industry as we all hopefully adopt spec-based development. Let’s see, in Kiro, we’re currently opening up access to more and more users.

So we have a wait list in place for the product right now, but we are opening it up as we speak to more and more users.

Kate Holterhoff
Ah, so exciting, yes. I’ve been following what developers are saying online and I have one question sort of related to how AI is affecting day-to-day development. And one of the things that’s top of mind for many developers is the cost of tokens. And I joke around with folks about them being gold.

You see people talking about moving their projects between the different free tiers of all these different services. I don’t know. It’s kind of a, it’s a wild time to be following the vibe coding scene right now. But what interested me about Kiro is that one of the selling points around this spec-driven development is that with this single spec, you are able to eliminate a lot of repeated prompting, which of course uses tokens. So I’m interested in, I guess the economic framing about that. Are you thinking about it in terms of like, just running prompts without, a good reason, in order to be thrifty with one’s tokens.

Clare Liguori
Yeah, certainly. I think what we’ve seen is that there is a bit of a trade-off between how many tokens are you using versus what is the quality of the code that comes out of that? So in some ways, we’ve done some analysis on if you just took the task list at the end of the spec-based

flow before you’re about to generate code and just kind of try to feed that into Vibe yourself, we find that you do end up with less quality because you have less of that overall context. The spec itself, the technical design itself is still valuable even once you have that kind of bite-sized chunk of tasks. It really helps to get the code that you want when you provide that as context.

But that is a bit more context than potentially if you just kind of took that task list and just copied and pasted it into Vibe, right? But as you said, when you get to the end of doing that in Vibe mode, you’ve spent less on tokens in terms of context, but you’re gonna have to keep going because you don’t have the code base that you want. You may not have the tests that you want, you may not have the functionality that you want.

And you still may be at that place, as I said, this is such an iterative process, you might now need to go back and say, that wasn’t actually the application that I wanted, I now have this other requirement, now I have to figure out, what are the other tasks that need to happen? So we do see kind of a, I would say a blend of usage of vibe and spec.

really depending on the complexity of the project that you’re working on or the tasks that you’re working on. So, if I’m just going in and I just need to add a function that does such and such and add a single unit test, I’ll usually use Vibe. It’s going to take me a lot less time than going through the spec workflow. But if I’m starting a new project, I’ve taken on a new epic in my sprint, something like that.

the spec-based development is going to get me much better results and probably much faster just time-wise that I have to spend kind of steering the AI that can get really frustrating in vibe mode when you get to the end of this massive conversation and you still don’t have what you want.

Kate Holterhoff
So we are about out of time, but before we go, how can folks hear more from you? What sort of social channels are you using the most these days? And how can folks keep up with the latest in Kiro?

Clare Liguori
So I’m personally on LinkedIn and Bluesky. Kiro, we have a ton of options for you. One, our most popular is our Discord. Super active community. It’s been amazing to see that community grow. But we also have Kiro channels on LinkedIn, YouTube, Twitch, Reddit. any of the developer communities you can find, we’re there to answer your questions.

Kate Holterhoff
Well, Clare, it has been so much fun chatting with you. Love talking, vibe coding, love talking, AI assisted coding in general, spec driven development is super interesting to me. And I’ve had a really fun time playing around with Kiro on my own silly hobby projects. So again, my name is Kate Holterhoff, senior analyst at RedMonk. If you enjoyed this conversation, please like, subscribe and review on your podcast platform of choice. If you’re watching us on RedMonk’s YouTube channel please like, subscribe and engage with us in the comments.