In this New Builders conversation, RedMonk’s James Governor speaks with Deepak Singh, VP of Agents and Experience at AWS, about the evolution of developer tools, particularly in the context of generative AI and the introduction of Kiro. They discuss the journey of AWS in the container space, the importance of developer experience, and how AI is reshaping the way developers work. Deepak shares insights into the challenges of governance and collaboration in AI development, emphasizing the need for tools that facilitate teamwork and innovation.
This is a RedMonk video, sponsored by Amazon.
Links
Transcript
James Governor (00:04)
Hey, it’s James. I’ve got Deepak Singh from AWS and we’re going to be talking about Gen.ai and DevTools today. So, Deepak, welcome.
Deepak Singh (00:12)
Thank you for having me.
James Governor (00:13)
Yeah, no, I’m excited. I enjoy your journey. I think I respectfully, in terms of your journey at AWS, or maybe not, well, yeah, quite respectfully, I do tend to think of you and principal engineer Clare Liguori, as sort of the zealots of AWS. So if something good is happening, you might be somewhere in the vicinity.
Deepak Singh (00:26)
Yeah.
James Governor (00:42)
I first came across you in the world of containers. And so, you know, let’s start there because I think this is an interesting one. You know, a lot of people had this view that Kubernetes was going to, uh, was going to be a huge problem for AWS and that the rest of the industry, we’re going to be able to niche AWS with their Kubernetes standard. And apparently you had something to say about that. So tell me a bit about the journey you went on.
Deepak Singh (00:47)
That’s right.
James Governor (01:10)
in terms of getting AWS on that train.
Deepak Singh (01:16)
It was not that complicated actually. Back in the day, I used to be an EC2 at the time. You know, at AWS we like saying, we listen to our customers. There were customers who came and told us that, hey, we’ve started playing around with this thing called Docker and containers look very interesting. And I remember asking myself the question, hang on, containers have been around for a while. You had folks like Heroku running on LXC.
James Governor (01:39)
Mm-hmm.
Deepak Singh (01:43)
You had other teams using containers, the classic sort of Linux containers for various purposes, even within Amazon. And when customers started talking to us about Docker, we went digging and we realized very quickly that there was a bunch of folks who were further ahead of the rest of us who were starting to use this new Docker thing as a packaging system. And there were signs that it could also become
a way of running applications, because Docker was both a packaging system and a runtime. That was the beauty of the original Docker specification. So we talked to customers, it became pretty clear we needed to do something there. At that time, nobody really had an idea that containers would become that big a deal. But there was enough out there.
We started talking to our customers, finding out what they wanted. And originally, that was ECS, which was the first container service we launched. Around the time ECS launched, Kubernetes came out. And as Kubernetes became more popular and much more used around it, I remember one of my engineers and the ECS team coming in saying, you know what? We know how to run a container service. We’ve been doing it for a while. There’s enough of our customers who want to use EKS.
We should carve out a small engineering team and start building a managed Kubernetes service. And we went and hired some people whom you know, who knew Kubernetes well. And that’s around, that’s how EKS happened. And there was no, I don’t think there was even one second where somebody went, we shouldn’t do this. It just made sense to do it. And we did. it, you know, the thing we like to do and we know very well is how to build something.
James Governor (03:29)
Mm-hmm.
Deepak Singh (03:37)
that people can run on, that is reliable, that people can trust. know, EKS has been hugely successful. It’s still funny. I’m a little out of the container world now. It’s been two and a half years, but I keep an eye on them. And both, all our container services, whether it’s ECS with Fargate or EKS, remain massively successful and used by, basically from what I can tell everyone. So I take a lot of pride in it, but… I think a lot of it just comes down to, we like listening to our customers. Simple as that.
James Governor (04:10)
I mean, on that note, I do think it’s funny. There’s this sort of view, ECS failed because Amazon Web Services had to do Kubernetes, but of course, both pretty successful platforms in their own right.
Deepak Singh (04:23)
Yeah, I know and both. I always see CS and Fargate together because Fargate needs most ECS users use Fargate and it’s it’s it’s it’s it’s been great to see how and when and what decisions people make. And as I said, I’m a little out of it. They just launched managed instances recently, which is something we started talking about when I was still on still running the containers organization as great to see that.
and that came from the EC2 folks when they started seeing how people wanted to run containers and what they could do on the EC2 side to make that easier. I think that overall picture, especially on the infrastructure services side of what can we do both foundationally and above that foundation is it’s always going to be something we think deeply about. That’s been what we’ve been doing from the day that we were first started.
Other people might have said that it was not even. It was not even that complicated. As I like saying, was fairly obvious.
James Governor (05:25)
No, I’m just messing with you a little bit. So let’s talk about developer experience then. I mean, think one of the things that I got to know you and got to know you more deeply when you were certainly on the container side was your deeply held beliefs about the importance of developer experience, the sort of work you wanted to do there. So then it was an interesting…
move at AWS one, as you say, it’s like two and a half years ago when suddenly you’re like, I’m not over in container land. I’m going to do, I’m going to do dev tools and a couple of things there a, or at least developer experience in dev tools. I think a, the timing was weird and interesting because that was literally at the moment when AI began to fundamentally.
change how we think about developer experience. That was one. And two, and I’ll give you a little bit of a prod here or I mean… Obviously, Amazon has done an incredible job of selling infrastructure, but you haven’t always done such a good job with developers. was there any concern you were taking on a poison chalice?
Deepak Singh (06:48)
Not really. I’ll actually go back right to the early days of my falling in love with AWS. I was not at Amazon at the time. I was still in my biotech world. And I remember when EC2 got launched. I’d already started using S3, but I remember that when EC2 got launched, within like days, couple of weeks of EC2’s original beta, I was sitting on a couch and launching EC2 instances and…
If you go back to it, what AWS really did was get developers interested. People like me who were just building applications, doing fun stuff and wanted to do with it. It was very simple, right? Because you had the EC2 CLI. Some of you will remember this tool called Knife from the Chef. Folks, which is something I use heavily. There was this Ruby library called Fog. I’m going back to the real dark days of the cloud. Really early. Yeah.
It was tons of fun. So I’ve always appreciated and enjoyed sort of the roots of AWS as something that let an average developer, and I’m not even average and below average, do interesting things in the cloud. And that’s always stayed with me. It’s always been important. And I think it’s partly because I’m not an expert developer. I need ease of use to be effective. I need things to be simple and to do anything meaningful.
James Governor (08:12)
Okay.
Deepak Singh (08:17)
And I’ve had some partners in crime at AWS. You mentioned Clare earlier, who share some of those same beliefs, except from a much higher vantage position. They actually know what they’re doing.
James Governor (08:30)
And Clare, and listen, you’re being unfair to yourself, but Clare clearly is an amazing developer. that’s a, yeah, that’s a different, that’s worth noting.
Deepak Singh (08:35)
Yeah, and when the change was not a coincidence, it wasn’t I suddenly decided one day I want to do developer tools. It was this deep belief that AI was going to change how developers operate and how developers are going to function. I have said often that the success of generative AI and LLMs is as much a user interface problem as it is about the science.
James Governor (08:50)
Mm-hmm.
Okay.
Deepak Singh (09:06)
The science has always existed. If you even go back to the Docker thing we were talking about, containers have always existed. It took Docker to make containers mainstream. Large language models have always existed. It required this interface that anybody, anybody, my mother included, could interface with to make LLMs a thing. And as LLMs have evolved into agentic systems, the user experiences built around them and the capabilities they enable,
or something I believe very deeply are still in their early days. But I wanted to be part of that, especially because I love making developers happy and get excited by it. So it felt as much as a fun new challenge as anything else, but also one that’s going to be very important to AWS. So that’s one where I am now.
James Governor (09:55)
Yeah, a hundred percent.
Like literally this intersection, at least from the market’s perspective at large and know, markets take a while to understand how things are changing and so on. But, you know, I mean, think the whole industry when chat GPT dropped just assumed that, okay, OpenAI is the thing. know, obviously we’ve seen from model perspective, the rise of Anthropic kind of Google getting in the game with Gemini. You know, we’ll see, we’ll see what happens with Amazon.
But I think that intersection of AI and developer experience is so interesting. So from a tooling perspective then, you did have a few tools out there. So on the infrastructure side, we had multimodal, governance and everything else, something like Bedrock, not really a dev tool. But then there were some tools and they weren’t necessarily getting, in some cases, the attention they might, the Q CLI.
But there were others where people, mean, think, know, Q Developer, sort of early versions maybe were not as strong as they needed to be. Developers kind of noped out pretty quickly. So you arrived. When you looked around in terms of owning some of this, what were some of the moves you you sort of felt you needed to make? And then, you know, at the risk of doing a bit of foreshadowing, how did this lead us to Kiro?
Deepak Singh (11:19)
Yeah. This world has evolved very, very quickly. Tools have been, you know, they have been AI driven coding tools around for a while. You know, we got involved internally somewhat early with the understanding that this was going to make an impact to end users. I’ll actually go back and say a few things that I think are tenets or points of view that continue to influence us to this day. One is,
James Governor (11:24)
Mm-hmm.
Deepak Singh (11:48)
Developer tooling and developer experience is something that has an unusual impact to us as a company as well. We are a company with very large number of software developers. It’s a population that is very important to our success and how we do, you know, with not just AWS, but Amazon as a whole. So having the right set of tools for them to be successful was very important. That is always one thing we had. Second, we learned from them.
because they use these tools that they’re not shy about telling you what they want. It’s something that’s helped us on the infrastructure side tremendously. But I actually think it helps us even more on the developer side because the kinds of complex problems we have to solve and the diversity, everything from simple websites all the way to folks building Dynamo and B-SQL, right? So big diverse set of use cases and a lot of internal applications as well.
So the things that have always informed us was we have a customer base that is broad and diverse outside Amazon, and we have a developer population inside the company that is very diverse and has a wide variety of applications, and it’s unusually important to us. The lessons we have learned over the last couple of years have been a few, and one or two of them have been super important to where, since you already mentioned Kiro, where Kiro ended up. One is developers…
want something that they can build on their laptop. think one of the early lessons we learned, but took us a while to internalize it is, and you see this with Kiro launching right off the bat with, hey, log in with the Gmail or your GitHub, not with requiring an enterprise type of identity, which is, think, big barrier to our, I won’t say a barrier, but it did hinder broad adoption earlier because I, as a developer,
Couldn’t sit on my laptop and just log in to one of these tools that people at AWS had come out with and just start using it. It required you to sign up and go into the console, sign up for an IDC, et cetera, especially if you wanted to play. And there was no sort of immediacy. can use my existing GitHub login and just get going. think that’s. Yeah. Yeah. So I think that was probably the single most important thing that we did with Kiro. Forget the technical stuff was just reduce the barrier to entry.
James Governor (13:58)
Yeah, the meantime to dopamine was definitely lacking.
Deepak Singh (14:11)
I think that’s been an important lesson that we have learned. But the second one, yeah.
James Governor (14:15)
Wait, I full shadowed, and you know what I should have done? I should have just said, Deepak, what is Kiro?
Deepak Singh (14:22)
Yeah, Kiro, well Kiro GA now. And when GA on Monday uh the 17th of November, I think it’s November, I said yesterday, I asked somebody, hey, it’s been a week since Kiro launched, how’s it going? He goes, it’s been 24 hours, like feels like a week.
James Governor (14:40)
Well, you know, that’s definitely AI era for you.
Deepak Singh (14:46)
Yeah, I think there was somebody else launched an IDE in the same time frame.
James Governor (14:52)
Uh-huh.
Deepak Singh (14:54)
Kiro is a set of agents that you can get in IDE desktop-like system. I hate calling it an IDE because code editing is probably the least important part of Kiro, but it appears in an IDE-like interface where you can talk to your agent, you can work with your agent to build software. You can get it in your terminal with the CLI, Kiro CLI.
It’ll evolve from there. It’s also, you know, it has its own website, kiro.dev. You can start off as I said with a Gmail or a GitHub login. But we also now offer enterprise billing. So if you’re an enterprise and you want to get invoices and, you know, do get everything, get discounts the enterprise way and buy a bunch of seats, you can do that too. But in the end, Kiro is a set of agents that are available in a set of surfaces that developers use every day. Today, it’s an IDE-like interface.
which I like to call Kiro desktop and a terminal which happens to be my favorite because I like I live in a CLI which is a Kiro CLI and so that’s at a high level. But Kiro, especially in the IDE, does something very specific. We learned a long time ago that when and this was from our internal learnings as well as what we learned from our customers to go back to the early days of these coding assistants. All they did was auto completion on steroids.
That’s what they did. started typing and they would write functions for you. You could then chat with them and get information. That never resonated with the best engineers I worked with. Like the best engineers that I know. They found it interesting but were never going to replace what they did.
Agentic systems change that reasoning LLMs change that once you had reasoning LLMs and agents combined, you were now partnering really partnering and driving the behavior of an agent and the agent was doing all the typing, but was essentially taking your brain and your thoughts and converting them into code. And so the thing we started talking about, and we’ve seen tons of success with that with Q CLI, which is now Kiro CLI.
we’ve had people build very advanced distributed systems inside Amazon and with our customers using CLI agents which would historically have the work that they did would have taken them 15 to 18 months and they were able to do it in less than three days, three months. Right. And you heard, I don’t know if you read some of the blog posts that that those very senior engineers have written about how it’s changed the way they even think about software development.
James Governor (17:31)
100%.
Deepak Singh (17:32)
And Kiro is very much an embodiment of those learnings, which is it basically answers two questions. One is. How do you build an IDE or an IDE? I’ll call it that for now. Where a human is not typing code. Most of the code is being typed by an agent. The human is driving the behavior of the agent. It’s providing the human’s job is to provide the right context and the human is the only one. It’s my favorite example.
You’re the only one who knows whether you want platypus or a bird. So the context that you provide will help the agent decide that it needs to build a bird or platypus, even though they both have beaks and web feet. Right. It’s my favorite trivial example. So that was one. And I think if you look at most systems there right now, that is the quote. They’re all headed there. The second one was. We started talking to engineers who
Let’s make the assumption they know what they’re doing, especially more senior ones, and said, what do do when somebody gives you a problem? And at Amazon, there’s a principal engineering tenant called Illuminate and Clarify. Principal engineers illuminate and clarify. And in my mind, that is, they’re able to break a problem up into smaller problems, and they’re able to explain to other people, their peers, more junior engineers, what that problem is, what is the real problem, and how should we solve it.
And one way they do it is by writing a specification. They’ve been writing on a whiteboard. They’ve been writing pseudocode. And it’s something we see all the time. And then the question was, how do you convert that into something an IDE can handle? So Kiro is foundationally what they call a specification-based development to spec-based development. I forget the term, which has become more common now. But the idea was, can you convert your thoughts and work with the agent to come up with the spec?
And a spec has a few advantages. One, 10 days after you wrote the code or the agent wrote the code, you actually remember why. Because if you’re just talking to an agent, I have no clue how I got where I did. Second, if you want to hand it off to somebody else, you can, because they know how and what you got there. And over time, that spec becomes the source of truth. Right now, it’s still the code, given the state of the word. But we want that spec to be the source of truth. are a set of requirements, technical designs, and set of tasks.
James Governor (19:33)
Yeah. Yep.
Deepak Singh (19:55)
that are created out of those, but really it’s the first two things in there. And how it evolves is still TBD. We are where we are right now. I still think it’s very early. And we’ve already made some subtle changes, but then specs allow you to do things like along with the Kiro GA, we launched something called property-based testing. Using mathematical approaches, we are able to extract a set of properties out of the spec and say, here’s what the code should be doing.
And now we can create these test scenarios on the fly. The agent is that these are not unit tests. These tested scenarios that basically try and verify is the application doing what your intention was with the code and that which is embodied in the spec. So there are things that come out of having the spec based approach that result in more robust maintainable code, which is what we want. That that’s sort of the high level thing. The sort of other tenant was.
Let’s not make it. Let’s keep it fun still, because part of what people enjoy about AI development is that it’s not the fun. Yeah.
James Governor (20:55)
It’s fun. That’s what, and for me,
that’s one of the things that I really struggle with when there are some naysayers out there, a lot of them on Bluesky, by the way, where anytime you mention AI, people will say, that is terrible. And they will give you a set of reasons and, know, maybe altering edge with those. it’s when a couple of things people will say, just doesn’t work at all. And you’re like, well, have you, have you used it? Because AI is definitely imperfect.
But in numerous contexts, it is capable of supporting you in doing interesting work. And to your point about fun, the biggest thing about sort of scolding people that AI is bad, scolding people not to have fun just never works. Like a big, big vector for why we’re going to adopt a technology is if it is fun. I mentioned Mean Time to Dopamine earlier. You’re talking about you sitting on the sofa.
Deepak Singh (21:30)
Yeah.
James Governor (21:55)
being able to use, you know, spin up, EC2 instances and being like, my goodness, this is, this is great. you know, my colleague Kate, yeah, big, big podcast listener. but, but, but since vibe coding tools have emerged, she kind of not, I, I, I’d love to see that, you know, a plot of her, the hours she spent listening to podcasts against, you know, hours she spends vibe coding. She’s now constantly.
on the lookout for tokens and the simple thing is, as she called it I think this year, is the endless, the endless vibe, the endless hot vibe coding summer. It’s fun and betting against fun I think is not a great idea.
Deepak Singh (22:36)
Yeah. Yeah. Even simple things like. I have a middle schooler and he loves science. I love science and this is a year year about a year ago, maybe six, nine months ago. When we started doing this, anytime I want to explain a scientific concept like you know, even the shook, don’t ask me why I was explaining the Schrodinger’s equation to him, but let’s talk about planetary motion. The way we do it initially in the old days I would do it on paper.
Now I just create an app. It takes 10 minutes. It’s not very sophisticated, but at least it helped me get my point across. Like, hey, these are how planets move relative to each other. This is blah.
James Governor (23:23)
I gotta ask you, have you forgotten anything? Because I’ve got, my daughter’s 15 and there’s stuff that I’m like, I really should remember this, but there’s some really basic science that-
Deepak Singh (23:26)
Good.
Yeah. It’s an excuse for me to get past the fact that I’ve forgotten all the science and I can’t write it down on paper anymore. Yeah, no, I’m not kidding. It’s like, hang on. don’t.
James Governor (23:38)
Building applications to teach yourself to reteach yourself science.
Deepak Singh (23:48)
Yeah, that is absolutely true. I forgot probably forgotten more than I remember. And. You know, so that’s that’s part of it. And I think the other part of it is software development is artisanship. I think software developers are artisans. Yes, there’s a lot of math. There’s a lot of technique, but you learn your techniques because you do things. They don’t happen theoretically, which is why I always.
call software developers, artisans, the best ones anyway. writing software with AI is also a form of artisanship. The best people, most effective people aren’t the ones who just randomly say, you can’t randomly say, build me the software. You have to learn. You have to learn how to work with an agent because they quirks. You have to learn to work around, make sure that you are providing the right amount of context with the right token efficiency. And these are things you learn over time.
Some of these are fighting against the weaknesses of the current technology. In some cases, they’re learning to maximize it, but it only happens when you do it and you get better as you do it. you know, we have one of our distinguished engineers says that I think his thing is I’ve become 4.91 times, that number may have changed, but I remember he said that, times more effective using AI tooling. In his case, it was
the CLI than he was before. And it’s because he’s become such an expert at using these agents. you just don’t randomly become 4.91 times more effective. You have to work your way towards that. And that’s the artistry.
James Governor (25:29)
I that is an amazingly, amazingly specific number, by the way. I mean, I mean, you know, I’m pretty sure I’d just say five, but there you go.
Deepak Singh (25:33)
Yeah, it is an amazing list, but I’m not surprised.
James Governor (25:43)
there’s a couple of things there. One is is the fun aspect and the other that we’re talking about is the fact that you’re actually learning what you’re doing. And so tell me a bit about, so you’ve got a specification.
Deepak Singh (25:47)
Yeah.
James Governor (25:55)
that’s cool. And by the way, to give AWS and your team, they’re due, you know, the spec based development thing is there were people reaching around it, but this is not one where Amazon was late to the party. think that you recognize it’s pretty early. So we’ll, you know, we’ll give you that credit, but in, terms of, of the, the, the fact that we’ve got the spec, you’ve got two modes, right? You, you, when you built the tool.
It wasn’t either or, you know, sometimes you’re feeling a little bit more YOLO. other times not so much. So tell me a bit about that and the balance between how do you use the tool? You’ve got the fun on ramp, but also the, am learning to be more effective in my use of agents. And what was the thinking there and how did you drive that into Kiro?
Deepak Singh (26:44)
Yeah. And one part was that just talking to an agent and communicating with it was something you didn’t want to lose. You wanted to maintain that partly because people are familiar with it. Partly, sometimes the immediacy of that is difficult to replace that. You can add any kind of spec based approach. And actually, think one of the areas that Kiro could evolve and improve is this interplay between prompting an agent
and building a specification. But surprise, developers figure out their ways around it or how to maximize it. So I’ll give an example of something that someone I know did recently where they started prompting an agent, they talked about the application they wanted, they started having a conversation about how to think about it. They had an existing code base, so they were looking at their code base. And at the end of it, they were very happy with how this was progressing. And they said, you know what?
convert this into a spec. They had created this markdown plan effectively. And they said, you know what? I like this one. Let’s convert this into a spec. once they had built this sort of scaffold for the rest of it, now they knew which direction they were going, they went completely spec-based. And it is this interplay between, you can always start, I’ll call it vibing.
James Governor (27:48)
Yeah, yeah.
Deepak Singh (28:11)
on this, on a little piece of an application and say, yeah, I like this. And you start prototyping it. And then you go, you know what? I like the germ of something. Convert that into a spec. I think the part that is going to evolve is how do, as we learning how developers interact between sort of just YOLO prompting and more structured specifications, there’s middle grounds in there. We’ve already taken some steps, for example, earlier.
I mean, I think this is one of the challenges with specs is once you go into spec mode, even a small changes become a little more complex because they’re going with the spec. How can you break a spec down? Can you create many specifications? you vibe, you know, maybe I’ll call it vibe code. Wipe code, there’s little change, but it’s all within the context of a specification and how people interplay. Like today, you can create a set of core tasks and tasks that are optional.
You don’t always have to run unit tests, for example, right? And so on and so forth. think those, that’s why I say it’s an interface problem sometimes. I think the interfaces we have and the interactions that we have will keep evolving, but it’s very clear that people like the fact that they can just vibe with an agent and somewhere along the way, once they know what they’re doing, convert into a more structured thing that then can become the artifact. That then the whole team, like one of the things about, it’s a good example. Yeah.
James Governor (29:35)
Yeah, team is an interesting word now. It’s like, we’ve been talking to individual developers, but I think the specification becomes much more important when it’s the context of a team and in terms of collaboration.
Deepak Singh (29:37)
Yeah. Yeah. When you’re part of a team. Yeah.
Yeah, in fact, if this is funny, the design concept in like you have a design spec in Kiro, like you start with requirements and you can run into a design. The design part comes from actually how teams sit down and review a design. It’s meant to be something you can print on a piece of paper, Amazon style or and and review or you put it in a wiki because it’s marked down.
And then you sit down and you sit down with the principal engineers or do a design review on this. Just the right design to work on. And we had that in mind, because that’s actually how teams work, and we wanted them to continue doing the things they did so literally can print out that artifact and sit with their teams with their team around the table reviewing the design like this was part of our thinking because our teams already work that way.
James Governor (30:36)
Okay, okay. yeah, that’s so critical and I think poorly understood. This is one of the things that as a, you know, I think, well, it’s funny a couple of things to just talk about another colleague. So in terms of that world you described, I’ve got both of those represented by Kate, who’s YOLO and then Rachel loves nothing better than writing a spec. So we’ve got those two individuals, we’ve got, you know, the…
Deepak Singh (31:03)
Yeah.
James Governor (31:03)
definitely lead with spec, definitely lead with the one shot and then meet in the middle. But Rachel’s been talking about, or researching, looking into from an organizational standpoint, this tension between what looks like significant individual productivity. You’ve got this developer saying we’ve got 4.91 % times as effective as previously, whatever that number is. But the organization’s ability to absorb that innovation. think Rachel has been talking about, I think she did it quite nice, a snake like a…
eating its prey, unlocking its jaws. Basically the code is bigger than the jaws, bigger than the eyes of the enterprise, its ability to sort of swallow, digest, roll out into production. I think that’s just an absolutely key, key challenge. And I suppose for Amazon, you do have one or two enterprise customers. yeah, trying to, when, so I guess the question there is you, at the moment, the tool is still, I think somewhat,
Deepak Singh (32:03)
Yeah. Yeah.
James Governor (32:10)
the tools are somewhat individually focused. You’ve you’ve got Kuro CLI, you’ve got Kuro desktop. Oh, there’s the, okay, I’ll finish this thought and then I’ve got to ask you another question. How does that become a more enterprise construct? When do we have some governance on top of the specs? When do we have central management of specs? When do we have, you know, know, yeah, enterprise diffs of specs.
Deepak Singh (32:28)
So. Yeah, all I’ll say is watch this space, but I’ll give you some sense of what people are doing. Specs are in the end something that can roll into Git. And the moment you can put things into Git, it’s a lot of the governance you have around code within your enterprise become valid. Who can check in code? What code can be checked in? Who has access to the repos, et cetera? I mean, if you look at the AI world in general, whether it’s MCPs, steering files or rules files, or some people call them.
James Governor (32:42)
much this space.
Deepak Singh (33:06)
You know, agents are MD type things. Those things proliferate like crazy. Yeah.
James Governor (33:11)
my god, you, you, you,
I’ve just, I’ve realized what’s going to happen. We’ve had DevOps, let me add GitOps. We’re going to have SpecOps.
Deepak Singh (33:23)
I would I I love you that I didn’t hear that.
James Governor (33:27)
Okay, well you’re going to build it. I don’t know what we’re going to call it. I would not be surprised to hear this from somebody other than me, someone smart, in the reasonably near future.
Deepak Singh (33:37)
Yeah.
So I think there’s gonna be a bunch of things that are happening that it’s not like they will happen, they’re already happening, which is, for example, how does an organization decide what are the MCP servers that developers are allowed to have access to? And they can’t be like a million and there’s no controls over them. Yeah, all of these will play into sort of these governance rules. In the end, what makes spec fine is they are just text.
James Governor (33:56)
Now MCP is a complete mess wedding.
Deepak Singh (34:07)
right, you the markdown files so they can be managed like code. So all your governance around code applies to MCP, to specifications. I think that’s one way of doing it. Having said that, I think people want, for example, in the CLI, you can do these custom agents. You can create agents that have personas effectively. You can have a custom agent for, I’m a front-end engineer. How do these best practice, like…
This is a classic. Every large organization has golden parts and paid parts and all of that stuff. I’m a new developer at an enterprise. How do I know what my paved path is to be a successful AI developer in the company? Where do I go? What do I have access to? What don’t I have access to? How do I put it into my training? All of these things are things that every enterprise that I talk to is listening, is either figuring out how to implement or already implementing. think…
us as providers of that tools will become better and better at helping them do that. For example, today, one of the very crude things we provide in the CLI is you can just shut off MCPs period. You can say, I am not allowed to use remote MCP servers in this company, not allowed. Or this person is not allowed. You can just globally shut it off. Obviously, that’s not the right thing. There’ll be much more fine-grained permissions.
James Governor (35:17)
Okay.
Deepak Singh (35:28)
The questions that come is, do you want to do it at the tool level or do you want to do it at the enterprise level? And those are not the same thing. The tools can inherit that. But if I am a large enterprise, have MCP servers being used for software development, but I also have them being used for financial planning. Do I have every tool implement their own way of governance or do I have a centralized? And that’s where things like agent core come in, because they are much more designed towards this center of excellence type concept. So I think that’s one area.
I think that this is the fun part is, actually, you’re right. A lot of these tools are very individual focused. How they translate to teams is going to be fascinating. You can already see a little bit of where they’re going with spec because a spec is an artifact that’s meant to be shared with the team. Today, we are doing it through things like Git. In the future, there’ll be other ways of doing it that I think, especially once you go beyond developers and get people like product managers involved.
will get very, very interesting because there’s nothing that stops a product manager who is somewhat technical, which is a lot of the product manager that companies like Amazon from writing a spec. And in fact, we have this today, that first prototype of a new idea. They won’t write it like a full doc on it. They’ll actually just build it and go to the engineering team and go, hey, what do you think of this one? And that’s going to happen.
James Governor (36:36)
Absolutely.
Yeah. mean,
basically engineering savvy companies now, they’re not hiring PMs that aren’t comfortable in that, in that sort of world. mean, yeah, writing decent specs is part of the job. Certainly in being a PM, I mean, I think then the interesting thing is how many other parts of the role does it touch? You know, is it something that, you know, somebody’s got to market the tool? Do they have some input? You know, it’s not always difficult to understand the spec.
Deepak Singh (36:57)
Yeah, I wouldn’t. I wouldn’t. Yeah.
James Governor (37:21)
So I do think that it potentially makes teamwork easier.
Deepak Singh (37:27)
Yeah, and also how I would say how companies operate and how teamwork works is going to change. You know, this on the blog post I mentioned allude to this right now. There’s a natural governor on AI velocity. AI driven software development velocity, which is human processes. Our processes within companies are designed for humans, objects and balances, etc. They have natural velocity or, you know, governors, no pun intended.
James Governor (37:45)
Mm-hmm.
Deepak Singh (37:56)
on how fast a team can move. The assumption is that you have processes in place that don’t slow down teams, but when a team is moving five times faster, they do slow down teams and we haven’t caught up. The rest of our processes haven’t caught up with the change in velocity from, and you can’t just willy nilly just keep doing things because they are, at least at the enterprise level, there are risks to that. I would argue even at a non-enterprise level. And so, you know, as simple
James Governor (38:11)
Yeah, another
Deepak Singh (38:24)
as everything as simple as humans need to sleep to how fast you can do application security reviews on code because AppSec is still mostly human and they can only work at a certain velocity. So those things start coming into play and a lot of the next, I would say year and a year, year and a half is going to be, I think we’ve unlocked something here. don’t think I know. What we unlocked is I think could be fundamentally could be as foundational and fundamental to.
the art of building as the cloud was, you know, 17, 18 years ago, and how we handle this as an industry and how we evolve is going to be super interesting. My assumption is it’s something that Rachel, for example, is paying close attention to, but it’s going to be very, very interesting on how we do it without coming in the way of the fun.
James Governor (39:13)
Yeah, no. that’s, mean, to your point, mean, Rachel’s been, I mean, financial background, been a DBA, compliance, definitely isn’t, you know, but also does like to have fun too. hopefully with these tools, we’re to be able to do that. Okay. So congratulations on the launch. GA is always a good place to be. and a bit of a word there. mean,
Kiro was a bit overly successful, wasn’t it? mean, you had too many people that wanted to use it. You bit of a denial of service attack of your own product.
Deepak Singh (39:40)
yeah. Pretty much on our own. It actually, in the end, I think it’s gonna be good thing. Like I like looking for the positives and things that were painful for a while. What it made us do was we ended up doing a ton of innovation on the backend about how efficient Kiro is. And you can see.
James Governor (40:02)
Mm-hmm. And what I’m talking about there is everybody internally wanted to use it and Deepak was like, yeah, we’re, we’re, we’re, we’re,
Deepak Singh (40:10)
Well, even externally, we just put this waiting list and like which at one point was hundreds. Hundreds of hundreds of thousands of folks, partly because there’s just we were just growing too fast and what it meant was there was a bunch of things that we knew we wanted to do on an efficiency perspective, which we thought we’d be able to do three months later. Could you have the time we had to do them in two weeks? And there are other things that we didn’t have in plan. So the team actually it’s kind of funny to.
James Governor (40:14)
The waiting list happened pretty quickly too, yep.
Deepak Singh (40:38)
get rid of that wait list and open it up to everybody, what became an interesting science and engineering problem. How can we become, if, as you noticed, doing this at the right cost structure is very, important. you know, sustainable, building a sustainable business is also very important. You have to do it in a way that you don’t suddenly decide that you don’t have a future because the cost structure is just not sustainable.
So we did a lot of interesting work, hopefully a blog about some of this and people will learn about what we’ve done to make Kiro really, really efficient in its credit consumption. So we believe we have, if not the most efficient, but one of the most efficient systems out there at current consumption, it allows us to off and in the end that included building our own agent called Auto. Yeah.
James Governor (41:26)
Anyway, see, there you go. You would make both Kate, the YOLO person happy because it’s going to be efficient and Rachel, the efficiency person happy. So, know, RedMonk will be happy. You know, you’ve got both sides.
Deepak Singh (41:37)
Yeah. Good. Yeah, that’s why we do these things. want to make I want to keep both Kate and Rachel happy and but yeah. And so but it was I will not deny that those the you know those two months where you’re getting all of this right and trying to figure out the right cost and pricing structure was not fun for me or the team.
James Governor (41:58)
I mean, it’s not fun, but you know, nice problem to have better than being like, I don’t understand why people are not adopting Q CLI or why not understanding, you know, huge demand. That’s got to be good. Listen, we’ve only got a few minutes left, but on that fun, fun note I did want to ask you like, Kiro is a little bit more playful. So we’ve got a different sort of login, but you’ve got the little ghost, you know, like what was some of the thinking about and, and, you know, design work around a bit of a more
Deepak Singh (42:04)
yeah. Yeah.
James Governor (42:28)
playful brand for Kiro.
Deepak Singh (42:30)
Yeah, there’s two parts to it. I think we talked about a little bit. One was this realization that we want to have that dopamine kind of thing. But I think there were two factors. One was letting the team have fun. The ghost sort of mascot for Kiro has existed from the early days of Kiro. And it was by the team itself and the designers on the team who came up with it, the product managers and designers, and they had fun with it and it stuck. Right.
The second part is our you’ve spoken to some of the folks in our marketing team, letting us and helping us be unique. So, you for us, Kiro is our developer brand. That’s one reason the CLI is now part of Kiro. For software developers who using AI, our products are going to be in part part of Kiro. You go to find them, you go to Kiro.dev. You’re signing up for Kiro subscriptions.
So we’ve had a lot of help and support from our marketing teams on helping us sort of build this thing that, for most of us, it’s something we’re passionate about. It’s a labor of love. It’s, you know, the Kiro team has built with Kiro from day one. The CLI team uses CLI every day. CLI is maybe used inside Amazon. And so… Anytime anything is that passion product is a passion project, it kind of shows up in things like having the ghost master because somebody created it one day and everybody loved it and it stayed.
James Governor (44:07)
Yeah, that’s important as you say. I mean, you want the team to be having fun as well. Okay, this has been a splendid chat. Definitely wanted to keep up, catch up with you on some of these issues. And we’ve got, you know, it’s gonna be very interesting to see how Kiro is received at re:Invent 2025 and onwards. But yeah, I’m grateful for your time Deepak. Thanks very much for joining us today.
Deepak Singh (44:36)
You know, always, thank you. And it’s always fun talking to you. So I’m not complaining.
James Governor (44:42)
Thanks
