Amit
00:00:00.000
if I was to build a very simple app that uploaded, files to S3 and allowed me to download them on a different device. It's a simple web app. I can drag and drop a file into the webpage, and then it'll be uploaded, and then I can drag and drop it onto my other desktop and it'll be downloaded. That's a simple app, right? And anyone can go in and say, that's what I want as a feature. It takes, knowledge and experience to know that, first of all. You want to protect that bucket with some kind of security. So not random people can't read your files. you may want to think about encryption at rest, which S3 does by default. You may want to think about encryption in transit. You may want to think about certificate exchange and KMS and all of those kind of things. all of that. Isn't by default the thing you get out of the LLM without you asking for it.
Darin
00:01:48.538
On today's show, we're gonna be talking with Amit Patel from Kiro. Amit, how you doing?
Darin
00:01:56.003
Good to meet you as well. some people may have heard of Kiro, some people may have not. Lemme see if I can sort of make a call of what Kiro is, where, when it came to about, and then you can correct me on everything that I've completely said wrong. Kiro. Is under the AWS umbrella. So far So good. Right?
Darin
00:02:24.178
from a, an early access preview, whatever, but then ga somewhere around November-ish, 25.
Darin
00:02:35.876
And the question now is, uh. Is it running itself? Why is there any humans actually working on Kiro at this point?
Amit
00:02:43.184
that's actually a more general question than just about Kiro. The whole ai, development, the way of software development is changing is, is actually super interesting and Even in the short time that we've been building and operating kiro, things that were happening even 12 months ago have completely transformed to what's happening now. And I suspect in 12 months it'll be different again. I don't think we're quite at the point in the industry where all the humans are going away. I don't think that's actually a, desirable state, quite frankly, because, You know, the way I'm, I'm seeing the current evolution of, AI is, more about, improving the level of abstraction rather than necessarily, you know, some way of, replacing, Software developers. So, so I think, what AI has done for, people is increase the velocity of software development, increase the quality of software development in many cases. that I think is gonna continue to happen and, and people are gonna be more and more productive and build, bigger and better things.
Darin
00:03:41.351
Now if you take a look at the about page on kiro.dev, by the way, if you don't know how to spell Kiro, KIRO, think Kiro, but Kiro, it says it is built and operated by a small, opinionated team within AWS. Now, when I think small and opinionated, I think back to my days of startups where it was three or four people in a garage, in a back corner, whatever. But with that extra prepositional phrase added on there of with or within AWS, is that prepositional? I don't know. what is a small, opinionated team within the confines of AWS to me? Is that 10,000 or
Amit
00:04:21.767
I don't think there's any, well, maybe there's a one or two teams that might be that big, but certainly not my team. no. So when we started out with, the original, product development, we were actually, the original team was only about six people. when we launched it back in July of 2025, we'd grown the team, I think I wanna say about 14 or 15 people. So, and, and we're not much bigger than that right now. So we're, we're, we're still, able to fit into a small room or a small bay in the office, and work on the product together.
Darin
00:04:46.391
I always think it's sort of funny because AWS was the one, at least as my recollection, recollection, is the two pizza teams. I don't know what happens out on the West coast, but if you could think two pizzas are gonna feed a team, you know, that's two people to me. I'm from the south, you know, that's gimme two pizzas. So now what you're telling me basically is, is you've got a seven to eight pizza team.
Amit
00:05:11.309
if you are gonna say one pizza per person, then I, yeah, maybe seven or eight pizzas. but yeah, I mean, it's a relatively small team and, we've been able to iterate and build the product, quickly and, make decisions quickly as well, which helps us to, keep, advancing the ball and, delivering for customers.
Amit
00:05:31.810
Yeah, it was, uh, it was absolutely a, a greenfield project. So, we started out as with many of these ideas with a, document and we reviewed it with a few folks. And, uh, then we got to work figuring out how best to build it. We decided that, using codo SS and building on top of that would be the right approach. And yeah, we just went, with it.
Darin
00:05:48.944
So you started with that small team, that five or six. And I'm assuming Bedrock, which is your LLM hosting, for lack of a better term, was already in place, correct?
Amit
00:06:00.909
we had a number of different things already in place, which allowed us to focus on the actual. User experience and the agent development rather than focusing on the infrastructure. So Bedrock was in place. We also had, queue developer, which was, a product that was launched by AWS back in November, 2023. that had. Put into place a, a number of the backend features that we needed in order to access the models and, do things like, throttling metering and things like that, which are necessary for a, a product like this. So a lot of that stuff was already in place and we could just kind of plug into that and build a client on top of it.
Darin
00:06:34.758
So what was the real problem you were trying to solve? did you just see like, okay, everything's headed towards agents and we don't have that, so we need to do that? Was that basically it?
Amit
00:06:45.816
no, actually we, we started off, and I think that, you know, when we started off back in 2024, second half of 24, agents were kind of emerging, but they weren't. what they are now in, in 2026. when we started out, there was a, a more fundamental problem that we were trying to solve, which is, obviously, we had engineers inside AWS that were using or trying to use the, software developer AI tools that were available at the time. the problem was that for anything that was, of medium or high complexity, was not. Uh, easy to do using AI agents at the time, because the, the sort of vibe, coding modality or the back and forth with the agent, and, losing track of what happened in the session or going across multiple sessions, always led to sort of a loss in fidelity of what the developer was trying to do, what the agent was helping the developer do. And, we were not seeing. Good results for medium high complexity projects. So one of the things that we wanted to do was to improve the way that we, enabled the user to provide, more insight into what their intent was. And that's where we kind of came up with the concept of spec driven development. we, obviously, we inside AWS, we, just in normal engineering terms, even before ai. the way we built software inside AWS was we, specified things and we designed them, and then we came up with the breakdown of the tasks and the architecture and we kind of wanted to take that, approach that we were doing manually before AI and bring it into the agent world. And, and, and that was the driver for that is to enable us to be much more intentional about what we wanted to build upfront. for medium and high complexity projects, that was super important and have a tool that was able to translate those, requirements and that intent into actual code and a, a system that we could then put into production. So getting medium, high complexity things into production is what we were aiming for with the tool, and that's what we set about building.
Darin
00:08:39.853
It's always interesting to me when. People start coding with ai, they start vibing, for lack of a better term, not a bad place to start, like get your feet wet, try to figure out what to do. But then especially if you, if you have come from a software development background, you think specs, the problem is. In the olden days, like two years ago, or 20 years ago, you would have a team of business analysts that would go off and write the specs. They would spend five years doing that, and by the time you actually start implementing it, it was, already gone. I've brought this story up before I was working with a team. They had worked on specs for five years. They developed it for five years, and by the time they launched it 10 years later, the rules were no longer the same. Obviously things are speeding up here, but I still think people writing specs can be done. I think it's great, but I don't think it's realistic. What do you think
Amit
00:09:38.584
Yeah. And, and, and actually we didn't think it was realistic from the beginning of this product, right? when we started out building the product, one of the things that we were experimenting with, and this was way before we launched it in 2024, we were experimenting with how do you, Enable the agent to understand your intent on a complex project. we, we experimented with, you know, shall we go back and forth Q and a? Shall we have the, user input, the information using a markdown file? We, we kind of walked through a whole bunch of things and then we kind of came to the, the realization actually that, the spec itself can be written by the agent. the user doesn't have to write it. so typically most of the projects that I've seen, my team is building the things that I'm building. we start off with a simple prompt in the chat window we say, okay, we want to build X, Y, and Z, create a spec for me that does X, Y, and Z. And then it'll produce some kind of set of requirements. And then you can say, okay, well actually, you know what I wanna. Make sure that, I have end-to-end encryption or I, I wanna make sure that, there are considerations to parallelize some of this work. then it incrementally improves the specification to add more and more of what you want as the output so you could refine your. iterating with the spec in a kind of vibe coding mode. Like, you know, you're not actually generating code, but you're generating the spec. You kind of iterate with that, and then once you're happy with it, you end up with a design, you end up with a set of tasks, and then you can get the agent to actually run through those tasks. So it's. a kind of, planning phase that happens before the code is written, allows you to, as the user to structure that, thought. You don't actually have to be involved in writing the spec. And actually, you know, most specs are produced in the space of 20 minutes of back and forth, and you've got a spec. You don't, you know, need to take much more than that. And then you just go through and execute that spec and, uh, you end up with, software typically within, two or three days depending on its complexity. and you're good to go.
Darin
00:11:30.323
if we as developers are the ones. Shaping these SPACs, we've effectively gotten rid of the business analysts or have we.
Amit
00:11:38.333
Well, it's actually interesting. I mean, we, we have in our, Organization at AWS, we have nu a number of different roles that build product. And we've had them even, since the beginning of AWS We had product managers who typically define the business requirements and the features. We have the UX team that, works on the user interface. And then we have engineers who build, the actual, software. the roles are still valid in this scenario as well. So for example, An engineer could be talking with the product manager and, you know, I, I'll, I'll give you a concrete example. a few months back, we were talking about, building some kind of improvement to the MCP feature so that, we could, um. have, the tools being loaded, dynamically and so on. the engineer was talking to the product manager and they were going back and forth and instead of the product manager going away for three days and coming up with some kind of definition of what the requirements were, they basically, you know, hashed it out in a half hour meeting in fact, the product manager was the one that went away and worked with Kiro to generate the spec, and was able to actually come up with a prototype the next day. And then they had a conversation about how to take it to production. So it's actually possible now for product managers not to just kind of, spend time right in the dock. They could actually come up with a prototype, a working prototype, and demo it to the rest of the team and get them to put it to production. so the roles are kind of, becoming more dynamic. I don't think that the value is in the actual writing of the document or writing of the code, but actually the definition of what the customers need and what the intent of the feature or the product needs to be. So, so the value is, in that, and I think that those roles are still relevant in this new world.
Darin
00:13:06.883
Isn't that where the value was all along? Even before all of this? We just didn't wanna believe it.
Amit
00:13:11.633
Yeah, but we measured the value by the output. we had all kinds of different metrics about, how much code coverage do you want, uh, to have and, what kind of, doc writing skills do you have? And, you know, are your docs readable and things like that. So we measured it differently. But the value, yes, it was always in, what needs to be built and, how can we deliver that and can we deliver a great experience to customers? That's still relevant today.
Darin
00:13:32.006
Well, it's even more relevant today. I will put it this way. I am glad that the. AI industry, for lack of a better term, settled on markdown and not some other silly, format for defining these things because I can't imagine you were talking about the product manager was able to do it. Well, pretty much EBI can write markdown. I mean, at least you would hope so. Right? You might not get all the tags right and whatever, but you know, it's plain text. Or if you don't like plain text, you can use an editor that creates markdown for you have Great, have a great day with that. Yeah. What do you think would've been the second optimal format for all of this spec writing to have occurred in?
Amit
00:14:14.818
I think that. at the very base of it, if it wasn't Markdown, I would've fallen back to just plain text. quite honestly, I think that there's no need for it to be any more complicated than that. the nice thing about. Markdown is that, especially when it comes to design, you're able to have architecture diagrams and tables and other things, which are super helpful for readability. So I think Markdown is really, an asset when it comes to human readability. Where it comes to the LLM. You could have easily written that spec in plain text and, LLM would've been just fine.
Darin
00:14:48.707
I mean, let's put it this way. I would still take plain text over any other format, right? It's sort of like one, two, and off we go.
Amit
00:14:58.810
Yes. Uh, we have, extensive, adoption throughout the company at this point. Um, we actually made it available, quite, I think it was. After we came back from reinvent, so early December time, we made it generally available to, everyone in the company to use. And, apart from the quiet period over Christmas, the adoption has been. Going up steadily week over week and, I dunno the exact numbers, but a large percentage of the company is now using Kiro. we actually have, you know, the Kiro IDE and we also have the Kiro, CLI. So depending on what, you want to use as an engineer in the company, you can use the CLI, the IDE or both.
Darin
00:15:34.958
If you're an engineer and using an IDE in this time of year, maybe it's time to go back to green screens. So let's just put it that way. Everything's ACL I, come on. Everything is ACL I. You can tell where my biases are. interesting that you have people and you said even during the quiet period. I imagine your quiet period probably wasn't as quiet as it as it was in the past because they had these tools to play with.
Amit
00:15:58.721
Yeah. I mean, folks are, uh. Uh, doing a lot of hobby and home projects. a lot of folks in my, team itself, you know, one of the guys came in yesterday, Monday morning and said, Hey, look what I did over the weekend. I'm like, okay, thanks for doing that, but you didn't have to spend your time over the weekend doing that. He said, oh, it was really fun. And I enjoy, building this stuff. So, yeah, I mean it's, it's bringing, uh, both the kind of personal benefits and also benefits to, organizations that are deploying these tools.
Darin
00:16:22.821
Isn't that dangerous though? I mean, I, I fall into the same trap is I'll sit down, I'll tell you a story that I had recently. I sat down seven o'clock Sunday night to just make some notes for something I wanted to do. Six hours later, I'm still working on the specs. I had been up since 5:00 AM I keep going through these cycles of, oh, I gotta do this, I gotta do this, and I'm not getting the other things done. It's like, it's, it's almost like a new drug now to sit here and keep going.
Amit
00:16:52.588
tell you a similar story on, my side, which was, you know, when I started using Kiro, before that I wasn't, Too enamored with some of the tools that were out there. But when I started using Kiro, the first thing I told it to do was, build me a, chess application, as a web app. And it kind of built me a chess application in, it took me less than a three hours, half a day. it was a fully working application that played chess with me. And I thought, if I wanted to do this without AI, it would've taken me. Three months of learning JavaScript and another three months to build a thing. And it kind of was almost, so. Energizing to see how a little bit of input can create such huge amounts of, output, uh, that I wanted to build the next project or the next project. And I started building things in rust and c plus plus and this and that, and the other half of these languages I never used in my life before. And if I looked at the code, I'd never be able to figure out what the code was doing, but the applications were actually working. So, so I, I kind of agree with you that, people have. First of all, taken to the tools, they are seeing incredible benefits from using the tools. And, sometimes you can kind of lose yourself in the tools because it's just so energizing to kind of keep coming up with result after result after result. And, and, you know, you can have a idea on Friday and have it working by Monday nobody's asked you to work over the weekend, but you kind of had the idea on Friday and you've got it working on Monday. And I'm seeing, I'm seeing a lot of that. So, I think it becomes a problem if people are, Forced to do something that they don't feel comfortable doing. But I think, people genuinely enjoy working with these tools.
Darin
00:18:20.496
plus and minuses. I mean, yes, the dopa dopamine hits are great, but if people are always working and they're never disconnecting, especially from a true work perspective, they're not being comped for it, paid whatever it is. Isn't this where upper management's gonna have to be really careful? It's like, Hey, look, we didn't ask you to do that, but you brought it in and you actually, you know, we beat time by this much time. You need to go away now. Is this gonna become a real people problem that we've gotta manage differently than we have in the past?
Amit
00:18:48.820
we are actually, at least you know, in my team and in other teams that I work with, we typically with AWS we have kind of big releases that happen at reinvent and there's a downtime that kind of follows the reinvent launches. you know, when we came back from reinvent, we actually encouraged people to just, go back, recharge, come back after a couple of weeks and then, you know, get back on the horse. So, yes, we, we have to actively manage it. Very often we have to kind of say, okay, you know, that's enough. You know, let's, take a couple of days off before going on. as responsible, employers and, working with our colleagues, we wanna make sure that they're enjoying what they're doing and also that they're balancing their lives, appropriately and not being pushed into unnatural working hours and things like that.
Darin
00:19:30.667
But like I was saying earlier, it's easy to end up in those unnatural hours probably like you too. You probably was like, oh, let's go and do this, and you look down and it's like, oh, it's been three hours and you think it's 15 minutes. That's the scary part.
Amit
00:19:43.497
I mean, you can, you can get lost in it, but I think most people are, getting used to it and are fairly sensible with things. So, I haven't seen a, you know, real kind of case, at least in my area of, uh. People losing themselves completely. So I think people are sensible. They, find the balance.
Darin
00:19:56.712
I hope so. Uh. If our AI agents are now writing code for us and writing our specs for us, what do the humans have to do now other than making sure they're actually doing the right thing?
Amit
00:20:08.052
Yeah. And, and I think that this is actually really where, where we're heading, right? So. I kind of think of it like bookends where at the beginning of a, particular task or project or app or whatever it is you are building, there is this whole kind of, uh, understanding intent phase. Right. I'm kind of making up some terminology here, but, the way I kind of frame it is providing some understanding of what your intent is. is one of the two things that are gonna be super important going forward. The second piece of it is on the other side of the project, which is, is the code and the specification matching the intent and has it been implemented correctly? So there's this kind of verification piece at the end, and I think that where we are likely heading, as LLMs improve agents, improve multi-agent orchestration becomes a real thing. where we are gonna end up with is. having the, people with the right judgment to understand, or define what the intent of the project is and validate at the back end of it that the intent has been correctly implemented. the tooling is gonna help you with things in the middle of that and make things in the middle easier to do. but it's really not gonna be able to define the intent, nor is it gonna be able to fully validate. that the intent has been actually achieved. so I think, I think that's, uh, ultimately where this could end up, especially with the improvements that are coming with the LLMs and the agents. I think that right now a lot of the tooling and, the way that people build software is actually, being. Either improved or, replaced by some of the things that the AI can do for you. was in a, meeting, this morning and we were talking about an issue that happened where, we hit a limit on one of our dependencies and, we didn't have an alarm for it. One of the things that team members said to me is, Hey, you know what? we could actually put, an agent to look at our, code as it is checked in to ensure that any dependency limits are, automatically, alarmed on, and, and we have a metric for, those are the kind of things where, typically you'd have to do that manually in the past, and now you can kind of automate, a, a lot of these kind of, repetitive tasks.
Darin
00:22:23.747
But even in those automations, it's great. I mean, we, we figure these things out and it's all iteration. Again, this is nothing new. It's just a new way of doing things. Instead of having to now get an SRE or a data center person, as I used to call them in the middle of the night saying, Hey, go punch this button, or go do this thing. It's like, okay, now things are watching. I mean, we, we went from human to basic automation to now in theory it's smart automation. I'm air quoting that very hard. Uh, you know, all these skills have changed over time. The base skills are still there, but as a human, I'm still trying to figure out, okay, what is the skill I need to do now? Because to me, if I'm within an organization, it feels like I need to know the business better than I've ever need, needed to know it before.
Amit
00:23:10.286
If you're in a product, organization, and KIRO is a product organization, I've worked in a number of different product organizations, whether it's an engineering discipline or a product management discipline, my expectation of the team, and typically for most organizations that are building, developer facing products like Kiro or other developer facing products, is that our engineers should also understand what. Customers want, and in many cases the people building the product and the people using the product are actually the same. I don't think that successful engineering teams can avoid being aware of what the product needs to do, the roadmap should evolve. You know, a lot of the features that we, added to Kiro over the last six months after its launch. A lot of them, I would say a majority of them. The ideas and the evolution of those features came from the engineers, not from the product managers. We, typically have one product manager for 20 engineers, so. the majority of those features were defined by the, engineers. So, I, I think at least in product organizations, especially product organizations that are building for developers, the role really doesn't change that much. the developers still need to know. What their customers are gonna need. They need to understand how they can improve, the feature set and the capabilities of the product that they're building. And they need to translate that into, something that the LLM can actually help them to then get to production. So, I don't, I don't think I am, I am actually that concerned about, that piece of it changing for developers. They'll just have more time to do that, and deliver more features and deliver better features and deliver things quicker to customers. I think that would be the, outcome of, this.
Darin
00:24:50.620
Let me give you another scenario. Tell me what you think. I was working on a small bug fix in my mind, a small bug fix and found that there was no test coverage for my fix. Like there was, there were no tests at all in this area. So I figured, let me go ahead and have the LLM create some new test for me. Okay, great. It created within what I, considerable reason, 'cause it was dealing with date math. Date meth is always bad. So I was testing all the edge cases. It was around leap years. It was leap years and daylight saving time. Yes, it's saving time, not savings time. Just remember that saving time.
Darin
00:25:27.970
I'm not saying that to you on that, but you know, people will get in arguments about that. I put in the pr. It's not my project, it's, it's just a project that I was contributing to, and I got a response back. It's like, okay, we need you to explain every one of these tests that you did because we don't believe you need this many tests. Now I'd reviewed all the tests. I had reviewed the actual code, which was basically just two lines of code that had to be fixed, but I wanted to test all the edge cases because daylight saving time and especially around other times of the year, can be tricky, especially when you have halftime zones and places that don't support it. All the different, like I was testing, you know, in Indiana and Arizona, which don't follow DST. Was I wrong in putting that in? Should I have not put the tests in? Should I just get rid of 'em and just give 'em the code and be done with it?
Amit
00:26:22.070
actually, no is the short answer. I, think that, one of the things that we have been working on, I don't know if you, have been following, the roadmap closely enough, but, just before Christmas, we launched, what we are calling property based testing as part of. that is different from, doing a whole range of unit tests. Property based testing is gonna allow you to, be much more thorough about the different use cases and, scenarios that need to be tested for. And, uh, I encourage people to kind of look into that. It's, based on, uh, automated reasoning and math and so on, to actually scientifically prove that what you are trying to do is what is actually being done by the code. So. We are of the. Opinion, and we'll be doing more of this as we go forward, using formal methods to actually verify that the LLM is producing correct output. That's gonna be one of the key tranches. I I mentioned earlier that, the bookend thing where you wanna verify at the end of the output whether the output matches the intent. Well, property based testing is one way to do that. There's a whole bunch of, other formal methods, that will allow us to verify the outputs of the LLM. So, Testing continues to be important. Making sure that the, code that's produced by the LLM is, not just syntactically correct, but functionally correct. and it matches the use cases and the intent of the user. all of those things need to be tested for and, we want to make sure that, the tooling is available to, test those scenarios, especially in a world where. generating code is cheap. getting to really, high quality code and, well operating systems is gonna be even more important. So, testing is a, is actually a big thing for us in our roadmap.
Darin
00:27:55.283
So if our. Agents, our LLMs can write our code, write our specs, write our tests. We've already talked about, okay, as a developer, I probably need to understand the business even more. Where does this leave kids fresh outta college or Boot camps? What? What are they gonna do?
Amit
00:28:14.756
as AWS, as an organization, we are constantly, And have for many, many years, been bringing in college hires and interns in the summer and and so on. And we continue to do that at the same rate that we have in previous years. you know, even in the upcoming summer we're gonna have interns and, and new college hires starting with the company. the roles for those people are again, gonna focus on. Some of the, the fundamental principles of software development, like, you know, how to distributed systems work. What kind of things do you have to think about when you're talking about performance? Uh, security, a good example, if I was to build a very simple app that uploaded, files to S3 and allowed me to download them on a different device. It's a simple web app. I can drag and drop a file into the webpage, and then it'll be uploaded, and then I can drag and drop it onto my other desktop and it'll be downloaded. That's a simple app, right? And anyone can go in and say, that's what I want as a feature. It takes, knowledge and experience to know that, first of all. You want to protect that bucket with some kind of security. So not random people can't read your files. You, you may want to think about encryption at rest, which S3 does by default. You may want to think about encryption in transit. You may want to think about certificate exchange and KMS and all of those kind of things. all of that. Isn't by default the thing you get out of the LLM without you asking for it. I can ask for the LLM to generate me all the code, to do all of those things I just said, but if I don't ask for it, I'm just gonna get a simple web app that uploads a file and downloads a file and none of that stuff will be in place. So. Engineering and understanding how systems work and, ensuring that the right intent is provided to the LLM comes through experience. And, and, you know, junior developers need to become senior developers and they need to learn through experience and, that is still gonna be necessary. as long as the, intent definition piece of things is still relevant, which I think it will be in the current world of lms, that's still gonna be necessary for many, many years in my view.
Darin
00:30:15.395
I think I could argue maybe not too strongly yet, but I would say I could argue strongly in a year to two that a well-written agent in your S3 example would do all of those things for me, and I wouldn't even have to remember to tell it to do those things.
Amit
00:30:33.114
Someone would have to write the agent, first of all, uh, or, or some, someone would have to, provide the steering files. typically, you know, one, one of the things that I would expect to see even in today's environment is if you're working in a company of 10,000 people, there'll be enterprise-wide steering files that, the company will provide. And, those will kind of have common best practices that the LLM should work towards. So I, I think, yes, your rules will get more sophisticated, your agents will get more sophisticated. but I, still feel that especially for medium high complexity systems, having an understanding of how things actually work. It is not something, that the agent is necessarily gonna be able to reason about, flawlessly every times. the intent part is still gonna be important for us to have, skills in and, for junior developers to be around to learn those skills, from more senior people and so on. So, I'm optimistic. I, I, I think I'll say that I'm optimistic about, the benefit of the tools that we're building. And I'm also optimistic that, engineering as a, craft is still an important craft even in the world where these tools are super powerful.
Amit
00:31:41.260
Yeah. We need people to reason about the unknowns. We need people to, to kind of weigh the pros and cons of doing certain things, certain ways and other things, other ways. I think that, at least my understanding of l LM said I'm not an LLM expert, is that they're not super good at reasoning, they still require some guidance and direction in order to come up with the best results.
Darin
00:31:59.364
I agree with that. That's what I see. But it knows how to write a Mac desktop app for me without even blinking.
Darin
00:32:06.774
so it's those kinds of things. It's like, and it knows, but again, one of the examples I'm working on right now is, okay, it wasn't doing linting, it wasn't building in the right test, it wasn't doing integr. I mean, the basic things, as a software developer that I've known of for 40 years, now I can, it's like, okay, nudge, nudge, nudge, nudge. Okay. And now anytime I. Greenfield, a new project. All that stuff's already there now. I mean, I still have to remind, it's like, oh yeah, I forgot. Okay. Well, okay. It, it's good to know that they all s forget too.
Amit
00:32:37.931
And they, they do need to be n we often have this thing, uh we have the steering file, but it completely ignored my steering file. I said, steering adherence is an art in itself when building agents. So, uh, we're seeing that, with these non-deterministic lms, it's, gonna happen.
Darin
00:32:50.855
is just like humans. We'll ignore the instructions too and go and do whatever we want.
Darin
00:32:56.473
So looking ahead, you've mentioned about properties that are gonna be showing up on the roadmap. What other roadmap things can you. Talk about now, again, it's hard to talk about roadmap stuff. I get it. But is there anything going like, oh we're still playing catch up to the, the other guys and we're trying to help push the thing forward. Like the Agent MD is the new standard, what else is, like, where, where do you see the space? Like it's, it's almost like there's a reasonable level of coopetition right now. That's going on of like, we're trying to get the standards just right. Somebody will do something a little bit different. Somebody will do, that's all fine. But it's like, how are we still trying to rise this boat right now?
Amit
00:33:33.237
talk more generally about the things that we think are, gonna be happening, and again, my time horizon is, especially in this environment where things change every couple of months there's something new and there's something amazing. I try not to make, Three-year plans or anything like that. 'cause that's, none of that's gonna hold. But what I, can talk about a little bit is what I'm seeing based on our experience with Kiro and, some of the tools that we are building. first of all, the ux, of these tools is still gonna be super important. And the way that. Developers will interact with the tools, is, a constant area for innovation and improvement. One of the things that I've seen in the last few months is, as these agents have become more and more powerful, they're running for longer and longer and taking more and more turns to get to better and better results. Things that we've been thinking about and things that are emerging. in other places as well. So, things like, for example. asynchronous execution and parallel execution. understanding when an agent can run things in parallel versus when it has to do things sequentially. so improvements in the way that the agent is analyzing the tasks in front of it, optimizing them. Um. Handing them off to subagents, things like that. A lot of that is gonna be, important to flesh out in the coming months. and then having the UX that allows the user to actually see what everything is happening in the background with the agents, what the agents are working on and what the outputs are, and how to, to kind of verify what outputs are coming out of the agents and so on. So. the UX and the agent evolution, I think is gonna be, super interesting over the next, six to 12 months. Those are the things that we are thinking about. there's probably other areas, where, things will emerge that are either industry standards or things that we want to kind of work on. one of the things that, we've been. Working on in the past has been obviously MCP and how to improve MCP and more recently we're working with skills and, we have improvements there as well in, terms of the, powers feature that we launched. there's a lot of things that we want to, collaborate with in the industry and also, a lot of, innovation that we think we can bring to the table in this space.
Darin
00:35:42.280
Thinking about it from a 50,000 foot view, and I think about your competitors, it feels like AWS has a, I'm gonna say a leg up. I don't know that leg up is the right word, but with bedrock, you're slurping in all the different models. Officially, right. It seems like that's sort of something that sets y'all apart and it may set kiro apart over time is because, let's say a new anthropic model, outdoes an open AI model. Again, I'm using these as examples. Nothing against either one, but you know, one nudges ahead and Kiro can say, oh, for this type of thing, let's go nudge it over to this model versus this model. I think other people would have to build that, whereas it would just be a natural thing within Kiro.
Amit
00:36:32.237
We have good LLM coverage, via bedrock. certainly it's easier, you know, when Bedrock adds a model, it's easier for us to adopt it and bring it into the tool. Typically, for the last three or four model launches we've been. Available on day one. So as soon as it's available in Bedrock, it's available in, Kiro. that's really useful and powerful for folks to try out new models, to see what works for their particular use cases and, and so on. and I think that's important for us to deliver those benefits to the customer as soon as those models are available and we're working, to ensure that that happens on day one. I think that the, innovation and benefits also are. Coming from the agent work that we're doing to make sure that, it's not just a single call to the LLM that makes a difference, but how you combine those LLM calls into an actual workflow. things I talked about earlier around asynchronous subagents and all, all those kind of things. so a lot of the, the invention and the, innovation is gonna be around, how the agent interacts with the LLM. And that's, one of our key areas of focus.
Darin
00:37:30.623
everything about Kiro can be found@kiro.dev. That's KI rro.dev and all of Amit's. contact information will be down in the episode description. Anything else today,
Amit
00:37:42.608
been really great speaking with you. I've, enjoyed the conversation. it's been a while since I've had such a, interesting dialogue about these topics. Uh, it was a bit freeform. I hope, folks, uh, listening to this enjoy it.