Transforming Dev Practices with Kiro’s Spec-Driven Tools | Nikhil and Richard

13,047 words · about 52 min to read · YouTube’s automatic captions

Vibe coding creates untracked decisions

0:00 As a solo developer or small startup, you do spend time thinking about what you're building before you start building. VIP coding changed that completely. Even as a solo developer, I'm able to build something in an hour, but I'm often left thinking, hey, what did I build? What were some of the decisions I made? Cuz you move so fast, get a response. You're like, well, I don't quite like that. I'd like it to do this instead. And the back and forth with the agent sometimes is basically a stream of consciousness. So, that's the core problem space we were looking to solve with Hero. We're not looking to just build yet another agentic editor.

0:29 Inspectdriven development is the approach we think will be the way everyone develops with AI going forward.

0:36 What are the some of the key learnings that you have took from this journey of learning about specifications? Specifications are combinations, artifacts in hero product, but high level they're about behavior and a learning is they need to be composable documents with really functional business use cases as well as code pseudo code people can put in there, technical diagrams, behaviors around error handling, behaviors around properties.

0:59 How do you see people in future wanting to use specifications?

1:03 Uh, okay. So that's a very deep question. Hello and welcome to another episode of

Introducing Kiro as a spec-driven IDE

1:16 the AI Native Dev. My name is Simon Maple and I'm your host for today. And today is going to be a fun episode. We're going to be talking very much about specd driven development but also uh looking at and seeing a new pretty cool tool actually on the market which has been very recent uh called Kira. And Kira is well I'll let the folks here uh introduce it but it's a specd driven way of being able to build software uh in your IDE um which is very very interesting and and we're going to go into a few pieces talking about the philosophy of specdriven development show a demo of of uh Kira working and then talk a little bit about the journey that the folks had at AWS in order to get to where we are today. So uh let me introduce Nikil Swaminathan and Richard Thrrell. Hey folks, how are you doing?

2:07 Hey Simon, doing great.

2:09 Doing good. Thanks for having us on.

2:10 So So let's jump into into into what you what your roles are at Kira. Nikl, why don't we start with yourself?

2:16 Sure. Uh I'm the product lead for Kuro. So I've been now on the Kuro team for the past 6 months or so, though it feels like I've been here for years at this point. And uh my job is to uh one help build out what features we need to we need to build and and and and two uh work with the team on making sure we're doing the right thing.

2:36 Awesome. And and Kira is around 19 sorry a year and a half. Is it is that is that fair to say? Year and a half in in in build time.

2:44 Yeah, close to that. Um I I think let's see it's July about 13 months actually. Yeah. So I'm I'm Richard. I'm an engineer on the Kuro team. Um uh I've I've been as as Nickel kind of alluded to uh I was I think either the first or the second uh engineer that's um on the team when we started it. Um and so I've been involved in all phases of Kirro development. Um but specifically, no p pun intended, I actually focus the majority of my time on specs. Um including uh the original research projects with a lot of the Amazon science teams.

3:18 Amazing. So looking forward to getting deeper into that. Let's we've we've said Kira a few times. My my introduction probably uh probably didn't do it justice. Um why why don't we jump into into what is Kira? Um Nikil, why don't

Vibe coding lacks a unified decision log

3:29 you why don't you walk us through give us the definition of what the what Ko problem Kuro is trying to solve?

3:34 The elevator pitch. Yeah. So uh Kira is an agentic IDE that helps you do your best work. That's our tagline. So let me unpack that a little bit because that's a little vague. So unless you've been living under a rock the last year, year and a half, um, agentic IDs have become really popular, what are they? Agentic IDs allow users to use natural language. So developers use natural language to interact with an agent to generate code for an application. And what that enabled is, you know, what used to take us like days or week days or sometimes even weeks to build a feature or prototype uh has allowed us to build this almost in hours now.

4:13 And what uh agentic ids really popularized was the uh the term that we all are very familiar with now called vibe coding that really allows you to use natural language and chat with an agent to help you generate code for your application. I think of vibe coding as almost like chat GPT for coders, right? You go back and forth with an agent to build features out. And while vibe coding has been great to help people get up and running really quick, uh the process does completely shortcircuit uh traditional software development life cycle best practices and how teams of software engineers often work on a day-to-day basis, right? Working on a team here at Amazon and you know, prior to Amazon, I I ran a startup, so I' I've actually experienced both worlds. uh when building a feature, you you often spend days or if not weeks sometimes detailing out requirements and designs before you actually start coding. And even as a solo developer or small

5:14 startup, you uh are definitely moving faster cuz you you there's less coordination, but you you do have you do

1 Highlight · Vibe coding leaves behind untracked decisions

5:23 spend time thinking about what you're building before you start start building. VIP coding kind of changed that completely. uh right even as a solo developer uh you know I'm able to build something in an hour but after one session of vibe coding I often find I'm often left kind of thinking hey what did I build what were some of the decisions I made cuz I moved cuz you move so fast right like you get you get a response you're like well I don't quite like that I'd like it I'd like it to do this instead and and the the back and forth with the agent sometimes is is basically a stream of consciousness and it takes you a minute to for you to kind of reflect and think about hey what did I actually get done? Uh so that that's kind of the core problem space uh we were looking to solve with hero.

6:08 We're not looking to just build yet another agentic editor. Uh we really think that the way you work with AI is

6:18 going to change and specri development is the approach we think will will be the way everyone develops with AI going forward.

6:28 Yeah, really interesting. And I love the way I love the kind of the the the way you talk about how very often you you very you sometimes make decisions but that decision is then in your mind versus you know you prompt it very very quickly but you're actually not capturing that and and while a lot of it is represented as code when you're vibe coding it's hard to then disseminate afterwards well what is the decision and what is just an implementation and if you was to almost like think you know in future if someone else was to come in and look at your code you you could somewhat guess what is decision, what is meant to be, and what is an assumption, and what is an LLM choice, but it's not clear. It's it's it's a mixed kind of reality in in code. So, that's what I love about specs, the way it kind of pulls that out and and and allows individuals who who read that spec to to to effectively understand what the individual or or team that was developing that is is is really adding in.

7:26 Yeah. I know I was just saying one of the analogies we I I use uh when talking with people on on the team is that uh it's it's vibe coding is almost like a sometimes a slack thread where there's like a stream of consciousness you know there's often you know when you work with teams there's really long slack threads right where which have like 50 60 messages cuz they're you know complicated topics that you're discussing but then a lot of the decision log is captured in that in that thread versus a document you know where you're like okay here's a document let's review that document, make sure we're aligned on that document before we actually go implement it.

8:00 Yeah, really interesting. And the and also like a a Slack message is a point in time message and it is relevant at that point based on the context that has already passed and not on the context that has has gone ahead of that. So it is relevant and true at that point whereas a spec is the spec. It's like when you see the spec that is the that is the final outcome. Um, very similar to I guess when I'm prompting in in in a Vive coding environment, my my prompt is is relative to the the code as it was, the code as it is after the prompt, and it really connects those two those two points in time. At any point afterwards, the prompt that I use may not make any sense because it only it it's only referencing the point in time uh just before I I sent that. So, yeah, very aligned on that. Um, we've we've

Bringing formal system specifications to developers

8:47 mentioned specs a few times. I'd love to go a little bit deeper. Um, Richard, I bring you in here. What do we mean by a specification?

8:54 Uh, okay. So, that's a very deep question. Um, depending on who you're who you're talking to. Um, and maybe maybe I'll start as something that Nikquil was just talking about here. We weren't necessarily looking to to build yet just another AI or IDE tool or something like this, right? We're really kind of trying to to to help people shape software development in their practices for the future. Um, and there's a lot of things in software engineering that have existed since, you know, 40s, '50s, 60s that we're just now seeing to to come into play today, right? Like specifications as a as a term. A lot of people usually have in their head, you know, some sort of formal method that they're that they're talking about, especially when you get deeper in systems and and usually they're talking about certain things like safety properties or livveness properties of your system, right? Is it making progress moving towards a goal or are you violating these certain properties? And and as you just mentioned, Simon, that's super difficult to tell in code just by looking at it.

9:52 Uh especially as you trace through a large program or microservices, right? If I want to if I want to make sure that I have something like a read after write property of my overall system, you can't just glance at an if statement and determine that in a really complex program. You actually need to lift that up to a higher level of uh kind of definition for people to see what this means of your system. And then as you're executing the program, you need to make sure that this certain invariant or something is respected throughout the system. So traditionally the way that this has been done in software engineering is uh is kind of a backwards process actually. You build these implementations um and you know as software engineering has become more common domain in the past 20 years or so. Lots of people are really good at those low-level implementations of such but then when it comes to actually believe it or not like people that work on their systems actually can't reason about them very well. So you bring then these next level computer science PhD experts that have knowledge of this

10:54 esoteric uh you know first order logic modeling language whether that's TLA or something like Daphnia that AWS uses or P or something else um you you have those those very esoteric experts that are then walk backwards from the system and they build these models to to do verification or or some sort of

2 Highlight · Democratizing formal system reasoning for developers

11:15 validation on the system as well. Um so what we are trying to do here you know to your question of what are specifications we kind of want to make this approachable for any developer to really have this power right and I think that's a a super important top level point because many times when it comes to AI tools there's an an overabundance of talking about well now we can make programming available to anybody that didn't know how to code that's true we can also make reasoning about systems and new tools available ailable to even those developers that didn't know how to code before and were kind of the super

11:51 developers before. Now they have compounding power that they can bring to their practices that they really didn't have before.

11:58 Yeah, really interesting actually how that how it brings it. It's really going to open it up in terms of it's more of a creator now, right? You don't actually the the point of a developer isn't now who can actually write the best code. It's who can create the most, you know, through uh through business logic essentially being able to communicate better uh will actually become almost the the the better developer versus versus their understanding of the the underlying implementation. And if you take it into more of a philos philosophical kind of like motivation, I

Behavioral specifications and the circular specification problem

12:28 know when we talked previously, we would we were talking about specifications into into a much more of a philos philosophical layer. talk us a little bit about the the the the philosophical motivation behind

12:40 Yeah, I guess that's the term dour. Yeah. So, let's let's talk about that a little bit and tie it to your previous question, right? So, what are specs kind of, right? You could say specs are this technical artifact and there's lots of different ways that that people build specifications historically. Um what it re my answer would be a specification is about behavior talking about the behavior of the system rather than implementation. Right? Um now historically and and philosophically that showed up in lots of different ways. um you know uh there's been different types of uh the most common specification known in the industry is something like design by contract and this is usually where you have this if you look at the research this style logic of saying like I have this precondition of my function and these are the the mathematical quantifiers it needs to meet like can only take an integer within this domain and then the post condition of that it must meet this and then you might define like a termination condition or a loop invariant um that has to hold

13:41 inductively if you're familiar with the terms and so forth. That's that's the real like sort of like um program enforcing the contracts of like your functions and so forth. Um a lot of the the newer stuff as well like if you've ever heard of lean from Amazon around like specifications, these are more theorem based which is I I would I would say gives you a bit more fidelity like even a lower level primitive of something like that. um to where you you sort of have this this uh it's it's based on on um dependent type theory where you have a correspondence between types in your programs themselves how they tie into logic right now this is important of why I'm going into this around the research and theory of this and how this brings to hero because those are artifacts that people would build with really in those formal languages and I mentioned specs are about behavior in what you're doing and so Nik will demo here in a minute really like from Kira's perspective, we try to walk through that at even a higher level so that as we evolve this system, we can

3 Highlight · Leveraging EARS syntax for requirement control

14:41 meet these different constraints, right? So when you build with Kira, you're seeing a top level requirements. Well, if you look at this, this is actually something known as a EARS syntax. Um, this is easy approach to requirement syntax. And this wasn't just like a a clever thing that we figured out with auto formalization to tie a prompt into how you define requirements. It's actually an extension of temporal logic which is an extension of first order logic. So this gives us a lot of power behind the scenes on being able to control what the model does, how we verify certain parts of the process, how we build the design and then that h how that leads to the implementation itself.

15:23 And the interesting innovation here is when we tie that to the UX, then you're actually allow able to bring ground truths to your system, right? So philosophically what motivated a lot of

15:35 this uh was two kind of highlevel points and you t you actually believe it or not Simon kind of touched upon them before. Um there's a a computer science professor um I think he's actually in the UK uh believe it or not Lawrence Tre um where he talks about two issues with building software and and as I go through these also you'll we'll be able to talk about how we ran into that inside of Amazon when we were building this. Um so one is what we usually talk about the surf circular specification problem. So this this means like to you almost need to really build something completely in order to specify it, right? That's that's how you know what you want it to be but then you're trying to specify something so that you can say what the implementation is right so it goes back and forth. The other is this observer effect when you do this right like the act of actually seeing the software changes not only how we but also others think the software should act. Um and that even might be us changing how we look at it over time. So

16:36 these sort of things are really why I I like in Curo this sort of vibe mode and spec mode as well, right? Like you can build it and vibe it and now you can specify it. Now you can go back and forth. So you get this sort of interplay on how humans act.

16:49 Yeah. Really, really, really curious and I think it does, you know, when we think about in software development today, how much even a prototype or something like that helps our understanding of how something should be built. uh and you know the way we do iterative programming today through agile methodologies and things like that we're constantly learning as we go and it makes complete sense like you know I'm sure if 10 15 years ago or gosh maybe closer to 25 years ago pre-aggile um if we was to think about uh you know writing specs more in a waterfall style it would make a ton more sense then in comparison to how we build software today uh the vibe and the the um the vibe and the spec kind of mode are super a super cool as well in Kira. I think maybe maybe we should maybe we should jump in and should we should we jump into demo and actually see this because I think uh it'll it'll very much help uh for our viewers to to see this. Uh for those who are viewing on podcast only on audio

Structuring projects with automated steering files

17:49 only do check us out on either YouTube and I believe uh on Spotify as well you can see the video uh through the the stream on Spotify uh but it's on YouTube in full. It's probably the easiest way to easiest way to view it. So, Nikil, I think you're going to show us the uh the demo, right?

18:06 So, let's actually go ahead and look at Kuro and see how this works. So, KO uh what we did is we took a it's a fork of COSS. Uh but really what we did that so we could really build an experience that we could fully control uh from a from a user experience perspective. So as you see here is I have this uh I have this tab here for KO um which is show shows you that the the the core features that we offer. So off the bat you see there's a specs folder as a structured way to build features.

18:40 Uh there's hooks which I'll actually get into a little bit later but hooks are almost like an infosa. Uh you can set up hooks to basically watch your uh watch your codebase and make changes um if if certain files are touched. Steering. So steering bas allow what steering does it allows you to set rules and guide your agent every time you every time you interact with the agent whether you're interacting with them via vibe or spec you can set steering rules.

19:09 So often what I do is when I'm starting with a new with a existing project, the first thing I do with Kira is I generate the steering docks and the steering docs give you essentially they get autogenerated and they give you like a product overview of what what they analyze your codebase and give you a product overview of what what it is. Uh it looks at all the different um files and and and and builds an understanding of the project. So as you can see there's like here's what the root directory is. Here's how it's organized. This is an nextjs app. Here's where the data layer is. Here's the state management, the type definitions, and there's a text stack file. Also the text app here for this application I'm using um it's just a react application uh with vit and it's got command it's got some information on what pack what what build tooling is installed

19:57 and and is this is this something that you would kind of like expect to perhaps even uh put into some kind of source control that you know the rest of the team can use and and if you have an organization you can all kind of like you know work within a rule set to uh to to adhere to.

20:13 Absolutely. So uh right now with steering we have steering files defined at a repository level. So all these files are actually in your repository. So if I switch to the explorer view you'll see there's this curo folder here and essentially everything is in so the steering files are actually just markdown files right uh so you can check them in and you can add your own custom markdown file. So what you know a good example would be let's say you have certain rules on how you want your UI to if you're generating UI for components your UI needs to follow these requirements right it needs to let's say you need to use tailwind classes you need to uh the styling needs to be certain ways enforced by like the marketing team so it allows you to for your team for you to define a structure of how you operate. A big feature request we've been getting from early customers is hey we have actually multiple teams uh that need to align on um you know certain rules uh how do you how do we how do we define that and

4 Highlight · Augmenting agent workflows with steering rules

21:13 that's something that's that's you know also coming soon and and something that we're actively thinking about

21:19 one one thing to note as Nikil goes into the specs too all these things he's showing are fully composable in the system and what I mean by that is hooks can trigger at spec workflow stages as you like it for matching file globs and so forth. Similarly, steering can actually uh mention dox in spec workflow. So like a common thing that a lot of customers do is they're like well I actually want to augment my implementation so that it follows TDD for example. You can create a steering file that will do this with whatever your TDD rules are. Then you go about your spec workflow and it will respect that.

21:58 Yeah. I mean I can quickly even show that here. Right. So all I do is I say augment my workflow to ensure that we're following TDD best practices. And then I just hit refine and and Kira takes that. And now what it's going to do is it's going to say, hey, I'm going to take this I'm creating this new steering file and'll actually like update my lazy prompt to make it a more to make it a more effective prompt. Um, so as you can see here, so there's an inclusion also. So I can there are different states for this inclusion. I can set it to manual or always include, right? That um so took my single prompt and now I have like essentially a new file that to guide the agent.

Iterating through requirements and design phases

22:46 Awesome. That's that's super powerful. I love that almost like turning it from a brief into a spec. That's uh that's

22:52 Yeah, we see spec and steering very much uh uh kind of they play together really well. Uh and uh and yeah, so actually let's let's actually just walk walk through specs now. So for the application that I have right now, I've got reviews. I also I added a cart cart once before. Um I've got these I've got this heart icon here, but I don't actually have any way to add f to um well I've got this this heart icon here, but that doesn't actually do anything. It doesn't actually work. uh so I can add something to my favorites.

23:28 Um what I'm what I will do now is maybe build a new spec about hey I'm building this this mechanism to add to favorites and we'll walk through that experience. So what I'm going to do first I'm going to go ahead and say hey I want to create a spec. I'm going to enter an idea here and I'll say um I want to uh add the ability to favorite um items in my uh in my app.

24:04 So what that's going to do now is it's going to go ahead and create a new favorite system spec. And with that you can see the agent is is creating a requirements MD file. And again all of this is it's just marked down. You know one one of our tenants for at least our first launch was to build something that had opinions but make it pretty flexible so users can tailor this to you know different formats. Again with steering if I have if I have some different formats the way I want to generate this I can do this do that but we have sensible defaults.

24:38 And so this is the this is the requirements phase. Is that right?

24:42 Yep. We're in the requirements phase. So like it took the it took that initial prompt I had which was you know kind of really badly defined for a PM I might say uh but had the ability to favorite items and then it went ahead and generated a requirements file for me. So let's actually go through the requirements a little bit. So we have an introduction. Each requirement has a user story with acceptance criteria.

25:08 Now this is then the acceptance criteria is what we have in years format. Now this is something that I actually uh from my years as a PM have found really find really useful. So if you're not folks are not familiar how Amazon works, Amazon has this process of uh PRFAQ writing where we essentially building a new product. We write a PR FAQ and then that PRFQ goes gets implemented and you build that out. But often there's a lot of information context that the PRFQ is not able to capture like the details and the edge cases about how how these systems are meant to operate and the best way I found to do that working with uh engineering teams is that you break things into user stories and acceptance criteria. So the user stories is almost like the highle definition. So as a customer browsing products I want to mark items as favorites so that I can find them easily without having to search again. Right? That's that's the traditional definition of a user story that everyone can understand.

26:03 Now when you if as a PM you give that user story to an engineering team there's like a lot of questions around it right there's like uh how how is it meant to work in in in a scenar like let's just think about this this favorites use case right so with with favorites when I when I add something as a favorite right um if a if a can a user click and and and andclick it to unfavor right is there uh is there a count that needs to be displayed of how many favorites I have right like if you actually start building out the the feature, there's a lot of details and and nuances that go into almost every feature you build uh as as a developer.

26:42 So, uh so over here is we've got the first one around marking items and the acceptance criteria in yours format is when a user views a product card and the system shall display a heart icon and then there's there's something around click and and not click and then I want to be able to view all my favorite items in one place. That's the second one. You know this is a good example of an edge case that when the favor list is empty then the system shall display an appropriate empty state. Uh you know what you can do here is I can actually um say like you know uh and I can edit this either here or I can edit this in chat. I can be like u you know make so for for requirement four where there's an empty empty state I can be like okay uh make sure that this experience has some uh iconography. All right.

27:45 So I can do this here or I can do this in in in in chat. So this is really the way so you know as a as a team you can iterate on requirements before you move ahead right so um the third one is I want my favorites to persist across browser sessions that's another like user story that you know my my simple user story didn't think about uh favorite count indicator

28:11 and when you edit it just then you you do do you do you prefer the the LLM to edit the spec or how how much

28:21 um so what I what I sometimes do is that I'll I'll just I I prefer I personally prefer the LM to edit it but really like I can I can you know if I have a new one I can just add it here right um and we have autocomplete as a feature so it will it'll start as I type as you can see there's something already just appeared so I can start typing and it'll it'll kind of continue me personal my personal preferences I I I I do what I just did. But I'll also sometimes use chat and say hey for uh you know I don't like for example let's say I don't really care about a count indicator. Uh so I I'll just be like I don't really care about the count indicator requirement. Right? So this is I'm almost vive coding the requirements right now. Think about it. Right? So I I just find that the easiest. Um, and you know there's there's still a lot of lot of room for improvement here. Like you know one of the things that we're thinking of is how do we make these

29:22 easier to gro like how do you make the acceptance criteria more easier to gro so you know that so users can review them and like understand you know to Richard's earlier point if two requirements have like conflicting kind of information. uh how do we uh h how does the user be how is the user made aware of it so they don't miss it

29:41 or in a or in a larger team uh like multiple people could view what you know the three of us what NIL is going through here even if he had you know 10 15 20 requirements let's say that it's part of a larger system and you want to compare these together to see if there's logical contradictions uh that that's some of the area that uh that we're looking towards in the future as well because you really want these in team workflows as you're as you're building them to keep keep the projects moving smoothly.

30:11 Yeah. So yeah, as you can see, I think it it went ahead and removed the that that requirement for count. Um, so I'm just going to say, okay,

Design generation maps requirements to architecture

30:20 things this looks good. I'm going to go ahead and move to the design phase. So the requirements is very much more is very much about the kind of like the what. So this is defining what we're trying to build. Is the design much much more about the kind of like leaning into the how now about how it's going to start building this into an application or is it more about the architecture? How does this work?

30:41 Absolutely. It's it's it's about how the the requirements for the W and the design is the how. So I'm going to go ahead and say okay let's move ahead and let's let's go create the design. Now what what Kuro is going to do is it's actually looking at the existing code base in order to determine what the design needs to be. So as you can see it's reading a bunch of files and then it say okay I'm going to create now this design markdown file right that will get generated again based on the the requirements. Great. So the system went ahead and created a design. Now you know the the process we've been piloting uh on Kirro now is that we're like we're we're heavily dog fooding uh Kirro internally is that we're trying to take the requirements and design. So let's say we're building a new feature like we have an upcoming like point feature to do. Let's let's gen let's generate the specs for it. Let's generate the requirements. Let's generate the design all within the codebase and then take those as artifacts and sit with the sit with the team and and

31:41 decide whether um those look good or not. Like you know a lot of the time we actually spend as a team especially when you work in teams they could be small teams or large teams is is kind of ironing out the details of the the details of the design and and and and the requirements. So in this case what we typically do um it hasn't done it here but like if you're typically building a feature we generate like a system diagram. So I, you know, I can ask it to do it. It'll do it. But in general, it's saying, "Hey, here's what the architecture is." So we've got, um, you know, here's here's state management patterns. Here's the core components and interfaces. So it's going to add like this favorites context type. Um, add to favorites, remove favorites. Uh, here's the components. There are already these components. We're going to enhance them.

32:31 Here are new components that are needed. And um, and you know, here's like our data model. Right now we're using a local data model. So it's it's uh it's like adding new interfaces to the data model. Uh error handling and testing strategies. So it's thinking through we got to we got to handle errors. Let's let's think about testing. Uh and and here's what our here's what our implementation approach is going to look like. Right?

32:59 So I can I can go ahead and edit these things. um you know before like over here I've already kind of I'm done a path where I'm adding a feature to an existing application. Often times what I do is I say hey I actually don't want this new if I if I don't want a new interface or if I'm like hey you you're actually you're actually generating something that is um that I like let's say for example I I I want to focus on uh unit testing and not integration testing for now. I can go ahead and and make make those edits. Uh but so this whole process is meant to be the initial start of the process. So where you say, okay, this is where I'm going to start and this is where I'm going to I'm going to review with my team. If there are trade-offs that I need to make, I'll I'll I'll kind of add

Flexibility over rigid design enforcement

33:47 those trade-offs here and and make a decision with my team on how I want to proceed.

33:53 And and what happens when there are conflicts between your let's say your design and your requirements? So there if there are conflicts with your design and requirements here right now um they're they're basically manually resolved. Typically your requirements do not your requirements and designs are like your design is reflected in your requirements. So I can walk through like the process of how you iterate through through both right so you know when when I go back to a feature I can say hey I actually want to now add this new requirement to this feature. uh let's say the thing that I removed count, right? I could go back and add count and then we'll go through the process of updating the design as well to take into account the new requirement.

34:35 But let let's actually talk about this one for a second. This is a good point. Um so the the process that we do is uh we we use the the generated requirements along with other context engines and then some uh some things on the back end inside of the the KO API that AWS hosts to to sort of curry these things as they go forward. Right? So using that information from the requirements build the design using that the next phase NIL will show the task list and so forth.

35:07 Now we a customer could modify their design with something that violated one of the requirements and it would still go ahead as they go to the next step and

5 Highlight · Prioritizing developer flexibility over rigid guardrails

35:18 build the uh implementation plan. But we kind of assert as we were building this over the last year and working with people that's okay, right? Because the alternative could be let's say that somebody did something and we went back and verified against the requirements and and it it violated something, right? That's actually a pretty bad developer experience, right? And this is what happens in the real world. Like sometimes you actually have more domain knowledge than what you can encode in a document, right? And and what you see a lot of times with tools is when they try to put these rigid structures in place, you can't do this or go down this path. it actually ends up compounding and having a lot of friction for customers. Uh we got a new visitor in the back there. Um so uh uh so we took the choice that we want to give the customers flexibility here in what they can do rather than restrict them from an action.

36:13 Um so then let's get to the final stage

Task lists break designs into executable steps

36:16 of this process. So uh we've you know as you can see there's a requirements file we just created. as a design file. And now what we're going to do is we're going to go ahead and and get to a list of tasks. So what the task is the task list is really the implementation plan. So how do you take the requirements and design and break it into like discrete uh items that you as a user can execute against? So you know this workflow if I was if I was vi coding this workflow right I would have started with the prompt that I had up top. it would have it it would have generated something and then I would have kept kept kind of iterating through but now now what I've got is I've essentially got a task.md file and as you can see here it's broken my my it's taken my design and actually broken it into individual implementation tasks. So the first one is create favorites context and hook infrastructure.

37:11 Add the favorites view to the main application routing. Create a list component for displaying favorite favored products. Then it's enhancing it's enhancing individual components and uh it's doing things like accessibility tests. So it's really thinking through this very thoroughly like I would you know if I was v coding this I would I would probably not think of accessibility. Um right. um error handling, edge case management,

37:39 and and how much of these how much of these tasks are for the LLM versus the user? I mean, if I was to, you know, is this something that that you would really want me to come in and maybe add to, or is this something whereby it adds structure that then allows the LLM to processes in a in a in an orderly manner that it can actually it can actually do it properly? What what's the what's the user interaction with this file? Yeah. So the user interaction with this file is that it's I I think it's I think it's the latter based off of what you said but uh is that it's it's providing some structure for how you engage with the LM cuz the structure really helps. I mean that's been our experience that's been the experience of a lot a lot of our early testers as well is that the structure really helps it do helps it implement tasks well and and complete and in in a complete manner.

38:27 Right? So, I'm going to say this task list. Again, I can because we, you know, as Richard said, we indexed for flexibility. I can go ahead and edit this task list and remove a bunch of things if I wanted to um to kind of if I wanted to say, hey, I actually don't want to do this or I I don't want to do I don't want to enhance the product detail component, for example, right? But I'm going to go go ahead and finalize this task list. And now um you know this is kind of some of the unique unique UI elements we built into this experience. As you can see there's a there's each of these have a start task button. Very intentionally we you know one of the first early feedbacks we got from people was like hey can you have a play all button? We've we've been staying away from it because what we've observed with user testing is that as you kind of incrementally build things with with editors, you have better understanding as to what's happening, right? Um, so I'm going to go ahead and

39:27 hit start task here. And what that does is, as you can see, it changes the UI here to say, okay, your task is in progress. And and it's going to go ahead and implement the task. And as a user, what I can do is I can I can be on top I can be on top of what's being done. Right? So if I if I uh follow the changes being done, what what it'll show me is is adding all these different it'll it'll add basically I think we're building out the the the underlying infrastructure if you will for this favorites context uh to be done and I can see all the changes very easily see all the changes that are being made. So, you know, we're adding some sort of mock storage.

40:12 There's a test component. So, it's starting with like a test file.

40:16 I' I'd love to almost like see an LLM interact with this whereby it's not necessarily a human click and the start task, but it's more driven by an LLM effectively as a judge as well as a orchestrator. That that could be super interesting to to to see how how accurately it would almost imitate or simulate a human looking at the looking at the output. Yeah. Yeah. Abs. Absolutely. I think that's a feature that that's a that's an interesting feature request that we've we've uh we've seen um where I think what you're saying is that hey, I've got a bunch of tasks here. Can the LM can I can I offload this to an LLM to to handle, right? That's that's what you're that's what you're maybe maybe a slightly more async workflow. Is that kind of

41:04 Mhm. Yeah. Pretty much. Pretty much. So what it's doing now is that it's actually installing um it's using justest. It's actually setting up a testing framework as well. Uh I think it's because I added the TDD rule. That's why it's it's it's doing this up front. Uh because it was part of my steering. But while this is happening, let me just actually walk through maybe the maybe like how this hap what what the state looks like at the end. Right? So once once a task is completed as a user I am able to view um I'm I'm able to view the the actual changes. So I'm able to say okay here's what so this was my earlier example where I was able to view what changes happened and so I kind of have full context over each of the tasks as to as to what the LLM did for or what the agent did rather for the individual task. So I'm as a you know there there there's while it's doing things for me I

42:06 have kind of full oversight over what's being done.

42:09 You also notice the requirements on

Agent hooks automate repository-level enforcement

42:10 here. This is this is an important piece of just the full software development life cycle. This is the the concept of requirements tracing. Right? So this is how we document and track the relationships throughout the entire state machine that's executing these things including as we curry the one task to another and process this implementation plan. So if I were to now go back to let's say the requirements and I were to make a change to one of those requirements would it would it look into the design and task list identify the relation I guess between those three and then say okay I only need to actually make updates to the ones that have the references to the um to those requirements that were changed.

42:51 Yeah let's go ahead and do that. Let's say um you know I want to add like requirement you know I for counting the fe favorites right now the the the thing is I don't need to I don't really need to define the this in like the proper format I just hit refine.

43:17 So now what what this refine button will do is that'll look at this file and and see um I think we have oh I I have I

6 Highlight · Automating repository governance with agent hooks

43:27 have a hook cued. So actually before I do this maybe it's a good segue to I was like why why is this execution cued? Uh do you see this agent hook thing spinning here?

43:37 Ah I see. Yeah.

43:38 So what I have is I have a documentation updater. Uh so hooks are a feature that that allow that that basically watch your repository for different events. Right now we have file create, file save, file delete and manual trigger events. Uh so what manual trigger does is that it basically says okay just manually trigger this. uh and it's almost like a like an enforcer right like that says okay uh at the end of an when a file is touched do x right so in this case I have if if you've created new typescript files in the source folder uh update update the the docu the documentation and I think that's effectively what this hook this hook is doing Um, yeah. So that that's that's that's what this hook is is meant to do. It's it's the documentation updator. So it'll go I I have a readme file in this repository

44:40 and it's going to go ahead and and update that. So I I'm able to create a whole variety of hooks. And the way we see customers using hooks is really is really interesting. So here I have another hook where I've got this component SRP validator. So when whenever new React components are added, make sure they're like well defined and like they don't handle multiple

45:00 concerns. So as a team I can enforce these practices across across my team. So even when we come up with the design, right, that that uh we are we are actually making the right decisions. Let me just switch back to the design view for my spec. And um Richard, I think you

Context LSP injects reusable specifications

45:18 want wanted to add something here.

45:21 Yeah. So, another piece that's interesting here that I just like to call out is is is probably my favorite feature here, especially for experienced software engineers is you might be looking at this and uh looking at this code snippet or a section of the error handling defined in this doc or

7 Highlight · Injecting institutional knowledge via context LSP

45:37 something else and being like I know from my institutional knowledge this is this is how I should change this interface or I or additionally I want some other data structure in here or something else. Um so what we actually built is a uh context LSP that is integrated in the IID as well as this uh interface as well. So um for example if NIL were to just in anywhere in the markdown here just uh put um a pound sign and you'll see this is actually giving you a context reference and if he hits enter it's pointing to a file. So, a common thing uh you could imagine like this design doc could get really big over time or you've got common designs that you want to include sort of like a library import of sorts into multiple designs that you've got over time. So, you could actually inject that into here and then as KO goes through these phases, it will respect it as it's building out your implementation plan.

46:36 Like a great example of this that that I use a lot in mine is uh property based testing. And property based testing is a very sophisticated technique that u allows you to kind of have a spectrum of correctness in your system, right? It's not full proofbased, but it's much more than just unit tests or even implementation um or integration tests I should say, right? And what's pretty cool is will create just little markdown files for the specific language that I have. like if I'm writing in Python, hypothesis is a great uh property based testing library and I'll say like this is the structure that I want and then I can say what the properties are right like these are the properties that I want to hold which humans are really good at and then the model will actually do the quantification of that into code and then when you actually go through running your test then you get CPUs that execute that with all the fuzzing and so

Code drift and MCP server integration

47:30 forth. So this is a super powerful feature that encouraged a lot of people as they're building advanced systems to to to take full advantage of themselves

47:37 and and where people where people want to you know they get through to the implementation and then all of a sudden they think oh actually I'd love to change this this thing um let's say it's and it is a implementation detail let's say of course when we do something like that code becomes the source of truth versus the versus the spec and then how do we how do we regenerate and so forth um how does that cause problems and how what what's the best way of kind of avoiding developers touching code?

48:07 I would say we don't really uh see that as a problem if they want to touch code. Um now it is possible yeah the uh the specification can drift a little bit uh from where the code is. Um, I would say uh that space is going to evolve in the future and we've got some ideas about how to handle that in a little bit more robust way right now, but I wouldn't discourage engineers from editing code. In fact, if you think about it, we're in a way encouraging them by offering both the spec and the vibe mode. So, if you are an expert and you know targeted changes you want to make to your system, by all means, go ahead and vibe those small pieces.

48:46 Right. Right. So, so a spec a spec then is um if we think about life cycles, how long is the life cycle of a spec? Is it the life cycle of the change um versus you know more than the life cycle of a of an app if if uh people want to change code?

49:03 Yeah, this is this is a tough question too. It's I I would my common answer is I think about it like comments in code, right? If you put comments in code at that point in time, it's temporal and they will hold as people and teams edit them over time. Um, they can drift. That is true. Um, so you have to think about it as a similar artifact in your system um and and build controls around it.

49:29 Um, one thing we haven't talked about here on this screen is uh on the bottom left, Nick, uh, MCP servers. um h what's the what's the best way of uh kind of like making the most out of MCP servers or other other services around uh from within Kira?

49:44 Yeah. So uh MCP servers work with all the features. So whether you're vibing or you're specking MCP servers will will work. So in this case I have the fetch MCP server which will allow me which actually allows me to do a web search. So if I when I'm building a feature especially even in the design phase I can be like hey can you can you search the web for what the best practices are regarding um regarding like you know maybe like maybe it's a framework or like maybe it's a a technology you can you can do that so we have full MCP uh local MCP support so you can add you can add any MCP so server so uh to via via like a JSON file that we have here and you can do that with the chat or you can just update it yourself and and then those MCB servers get invoked by the agent and the agent can decide whether in spec mode or vibe mode whether um the agent needs to be invoked.

50:35 So so so for example um if if we do provide a uh I don't know a docs creation uh MCP server of course the LLM can do doc creation by itself as well. Do you find any challenges between when uh like the user wants you to use an MCP server uh but actually it's trying to it's trying to uh do it itself because the LLM has capability to an extent to perform that action. Uh do you ever have do you ever see contention between whether it does that?

51:03 I mean I think basically what you're saying is if there's an MCP server that's overlapping with one of your hooks functionality.

51:10 Yeah. Or even just a basic LLM capability.

51:13 Uh absolutely. I I think that you you can you can see that happen. And then I think part of again the way the system is built is is that it's it's flexible enough for you to interrupt when working with agents basically you're working with systems that are not like non-deterministic in nature right so you need to make as from a UX affordance you need to make sure that you've got the right level of flexibility so users can interrupt the agent like for example I could have interrupt the agent while it's while it was going and tell it hey actually you need to do this instead.

51:43 Um, so that that that's all all all possible with Kira.

51:49 Yeah. And I presume even add it into the

Evolving from rigid TDD to flexible workflows

51:50 task itself to say d I want you to use this service or this tool to to to create me the documentation for this or within the uh within the hooks. Yeah. Okay. So let's let's talk about let's go back into talking about uh specs just a little bit more. Um and and and and Richard I guess um I guess the specs that you kind of showed which which realistically is is a number of different things. It's the is the requirements, the design, the tasks, all of that I guess together is is in combination the specification in the KO world. um in terms of um you know where we are today versus where you started. I suspect you learned a a ton of things going through kind of like maybe the private betas using it internally at AWS. Uh what are the some of the key learnings that you've that you took from from this journey of of learning about specifications? So a few things um you know we mentioned and you kind you you nailed it like specifications are kind of the combination of those artifacts in the curo product right but high level

52:52 like we talked about they're about behavior and and really our view on this is uh in a learning is they need to be kind of composable documents with like really functional business use cases as well as code pseudo code people can put in there technical diagrams behaviors around error handling behaviors around properties, right? And so some learnings there like um I I I mentioned when we kicked off this podcast like there was building the hero product and then the research phase also that was kind of parallel and they joined up. Um let's kind of talk about this and how this went especially what we haven't mentioned. Um, so I'll start some of this and then hand it over to Nikil to talk about this is like there was a few iterations of Spack internally that were big failures first.

53:41 So we proved what wouldn't work actually too, right? So um you know I mentioned uh we we've got a lot of um Amazon has this automated reasoning group that's well kind of known and we have uh you know web pages on it and and they the formal methods community dealt with a lot of the same things that we in fact they were inputs into how we built this product itself. Um and they you know early days of Amazon with these systems um really where specifications were were were highly used were some of the systems backing AM and S3 and so forth and um separate from the technology. My biggest learning of talking through those teams and and what they were building was there was so much back and forth between people and engineers, right? Like you had people that were experts on the implementation and then experts on modeling the behaviors and so forth. And I remember I saw this one presentation internally and it was actually like showing the paths between the offices in like a triangle and how

54:42 the carpet was getting worn because what you would do is you say all right we define this behavior over here to work like this and then go talk to the expert on implementing IM or something it's not exactly like that and you go back and forth in here and that's really what we're doing here right is allowing you to iterate and go back on that system and so um you know without sounding too boring like a lot of this is you know codified institutional knowledge and you know SDLC practices but let's let's talk about some of the things as we were building this like we could have easily said like uh you know what we're going to reinvent that space even though people have been building software and and sort of like like force certain

8 Highlight · Learning from failed early spec workflows

55:22 patterns down people's throats and um so one of them maybe and I'll hand this over to Nikil that we tried at first um and I touched upon how you could augment your system to do this is like make every spec go through a TDD flow. That was one thing we tried at first here. Um, so Nik Hill, you want to talk about that a little bit?

55:38 Uh, yeah. I mean, I can talk I maybe talk about that and then what we what we did next. So I think the approach was like, hey, let's start with TDD and TDD is great. Um, like where you start with tests and then based off the tests you generate the code, right? And you know, I think from our early tests, we found that that generally worked pretty well. uh but then when actually putting that in front of users and customers it's not it was not typically how they were like people were working TDD is great if people follow it but a lot of a lot of us a lot of customers like we're just are just not were not not doing that that was not the logic chain they followed so what that what that did is it enforced a lot of rigidity in how people use specs and the feedback we got from users was that um this is not really working for me, right? And and then I think the second thing the next thing we tried uh the next major thing we tried is we said okay uh the the experience for

56:41 generating a spec was you know you open a file or or or a folder and you right click on it and you say new spec and then we generate like a effectively a specification for what what's contained in that folder. But that again was um users found that it was it was interesting. it was like generating like you know an like information about what's there but that's kind of like what we have we have with steering right so it was like okay how do I actually

57:10 action on this and build something new right and I I think finally where we landed was we we kind of those all the learnings that Richard's been working on as he's been working um you know on on on the specification based approach with yours ears requirements and and designs and we also saw the field and how uh you know power users had changed how they were working with agents right like there like there was a lot more planning up front there was a lot more uh there was more meticulous thinking up front before before doing tasks and we learned from them and we I think you know basically tried to learn take take our learnings that we go we we go that we we built inhouse and apply them with a user experience that's very much front and centered around uh the the development process which is a requirements design and implementation process right and that's where we landed with the current experience and then you know the moment

58:12 we shipped this we got a lot of positive signal and of course there were tons tons of issues uh in the experience when we first built it and and what you're seeing now is probably like four iterations in um but the core of this really is around like your require requirements, your design, your implementation plan. And I think a lot of the questions you asked around how how do I edit this, how do I keep this in sync, how do I review it are all kind of things that we are very much actively thinking about, not just from a underlying technology or capabilities

Shifting focus from building to code review

58:47 perspective or science perspective, but also from a user experience perspective. H how to make this how to make this uh palatable to users?

58:54 Yeah. And and from that when we say users, I guess there are going to be multiple different personas going forward in terms of who who has the most opinion on each of these files. And I guess when we think about I don't know whether it's tasks versus requirements. I guess we might see two different types of people. Maybe more a PM style on the requirements and maybe more an engineer or someone some some uh kind of like development practitioner who cares more about how things are built. Do you see do you see different owners maybe going forward with these different types of um uh files as part of the spec?

59:30 Absolutely. Which is which is why I was saying what we're doing is we're kind of dog fooding this internally cuz we have PMs owning like the requirements you know engineering owning design. How do how do we put them in places where they're easy to share? Like a a top a big feature request for we've been hearing is that hey you know we have we have some requirements in Jira or we have some requirements in Asana. How do we bring how do we how do we bring those in and surface them, right? Um from a and I think from a problem perspective that's very interesting, right? Um how do you how do you kind of make the coordination of that that better? How do you how do you like short circuit how do you like save a bunch of upfront time that goes into this requirements and design planning uh in a way that makes in a way that makes sense for how teams operate, right? like we don't expect every team to like PMs on every team to be inside a code editor for example to do things. So we have to kind of look at how people are doing things in in in in

1:00:31 the wild and and enable them in the tools that they're they're also using.

1:00:36 Absolutely. Um let's look a little bit further forward as well before we before we wrap in terms of where does this where does this space lead? What's the what's the next step do you feel for uh from a from a spec oriented way? How do you see people in future wanting to use specifications or development with specifications?

1:00:58 Uh Richard, do you want to take that first?

1:01:00 Yeah, I'll start and uh then hand back to you Nikil on this. Like so NL's been talking about uh you know uh a lot of the the coordination that which is really the hard part, right? that you do a lot of uh with a lot of teams and products and so forth and um you know there there's there's there's topics around that that he could talk a lot. The the one that's the most interesting to me I mean there's there's obviously some other things that we're going to do with uh giving you more controls about being able to see the ambiguity in the process and you know contradictions like we talked about before and um you know also give you more entry points to this workflow and so forth. Um th those are all technical feature specifics and um you know components of this specification component that we'll do.

1:01:47 Um what I think is the most interesting of where the the effect of a of a tool like this of what it does is um in some ways it shifts your focus from the postbuilding phase into the code review phase, right? Um because you know agents and models build a lot of different uh um code bases and lines of code and so forth. Um they're getting quite good and refined at these things. Um no matter what the AI detractors say, uh they they they are quite um coming along further um to to really meet some some high standards, especially a lot of the benchmarks that we've seen. Um, and you've now got these code bases and requirements and you have teams and people that need to reason about components of them, right? And that could be reasoning about the or reviewing even um efficiently in teams the the refactoring parts of a program, right? or it could be about reviewing

1:02:48 and reasoning about uh the new feature parts of the component or even like the secure security components right of of code of implications of code changes that are made. So I think that this is going to be a real highlighted area not just you know in hero but as the industry as a whole over the next couple years that really is untouched right now in the in sort of the AI and editor space. Uh yeah, I mean I I think for for me right like I I think about it from like the problems that um we have as teams, right? Like look across the SDLC process, right? So like I already kind of talked a little bit about the upfront process on like the back and forth with like finalizing requirements and designs. How do you have multiple when you have multiple teams working together like it gets even harder and more complicated, right? How do how do we kind of improve that process, right? And then you know going going forward uh past past the review once something is out in the wild and there are issues how do we bring those issues back to the back to the actual uh development team

1:03:48 right uh so that we're really looking at this from a whole life cycle perspective and uh you know you know there are core things that are not going to change not going to be impacted by by AI in terms of the problems you have right You ship software, there'll be problems with it. How do how do you get those problem? How do you fix those problems? You when you build software, there's ambiguous requirements or design. How do you solve how do you make that easier?

1:04:16 So, that's how we're looking at uh this space and and problem solving in this space.

1:04:22 Awesome. And where are we with the build right now? It looks like we've just completed uh I think this was uh was this section four?

1:04:31 Yeah, we've completed a bunch of tasks. Uh I've been I've been going going at it while we uh do things. So as you like one of the things that you see that's happening is that it's actually being very methodical with generating tests. Um so you know it generating generating updates. So like it like I just executed a card for uh this pro enhanced product card component with favorite functionality. So it's actually like making sure the tests are set up right.

1:05:00 And so let's actually see what it's done now. So I've I've got uh it's added like a so it's added a favorite here already. So I can favorite things. Let's see if they I don't know if this is Yep. Yep. They're actually showing up as favorites as well.

1:05:16 And remember this this one Nikil had that steering file to use TDD first. So it actually augmented his flow to do some of these up front rather than later.

1:05:25 Exactly. And you know I picked a relatively easy feature. A lot of times um people use these AI demos to say, "Hey, build me a game or build me something that are very much green field, right?" But like the reason why I picked an easy feature like like adding favorites is not because is to show that there's actually a lot that goes into building favorites. It's not just like you know a simple thing that you can add to your your application. uh you have to think that you you know having tests making sure things are accessible uh making sure like the the number of scenarios that were covered here are things that I would have not thought about doing.

1:05:59 Yeah. And and the nice and the nice thing is it's the tests that are added and I'm sure the tests would have equally been added if we didn't do the TDD piece but probably you know after uh towards the end of the tasks. It's it's not you know the thing that we miss with vibe coding is the ability to actually validate and truly say yes this is all working. I haven't regressed other things. And the nice the nice flow about this is tests are being built by default. It's it's it's coming as part of the package. Uh and it allows us to validate every step of what we're what we're doing through the through the tasks.

1:06:32 Yeah, absolutely. And like the product of that that the hook was that the uh I had I had it update like the readme file. So a lot of developers like the readme file to stay updated. So, so as you can see, it added like the favorites to the the the favorites to the um to the actual experience. And you know, it'll keep this read me up to date. The hooks experience is also is is one of my favorite things cuz you can really like do the same thing. You can, you know, language localization is also a good one. Like you add a new feature and you want to make sure that your strings are in different, you know, in different languages, you can just have a hook for that. So, we're really seeing customers get creative with the the types of hooks they're creating.

1:07:14 Yeah. And you just avoid that debt that will typically follow you around when you don't do these things uh as as well.

1:07:20 Yeah, absolutely.

1:07:21 Amazing. Um this has been a this has been a great demo. It's been really really great fun chatting with you both and um and congratulations as well on all the success that Kira's had. uh from what I from what I saw on uh on on Twitter. I think it's in it's in a it's in a waiting list right now just because it's had such an inc impressive number of uh downloads from from people wanting to wanting to try it out. Uh what what what would you what advice would you give to people who want to who want to play with it today?

1:07:46 Yeah. Uh we are so grateful for to everyone trying to get on you know are we you know we've got thousands of users and we were trying to optimize the experience for the users who have access. That's why we added the weight list and uh we're working very diligently to to get people off the wait list and you should be hearing something from us very soon.

1:08:08 Awesome. And if you're interested, kirao.dev, I believe, right?

1:08:11 Yep. kira.dev.

1:08:13 Kira.dev. And you can join the wait list there. Wonderful. Uh Nikil and Richard, it been an absolute pleasure. Very very insightful. Thank you very very much for sharing uh for sharing your knowledge as well as as well as Kira and uh and the demo. Um, for those watching online, uh, sorry, for those listening only, uh, on to the podcast, do check out the YouTube video cuz it's there's a ton of value, uh, in the demo that was, uh, that was shown today. Really appreciate you both joining. Thanks very much.

1:08:39 Thanks, Simon.

1:08:40 Thank you.

1:08:41 And thanks very much for listening and tune in to the next episode.