Kiro Development Environment Is A Big Shift In AWS Developer Strategy

Forbes

a day ago

New Kiro projects can leverage vibe or spec-based coding.
Over the past 12 months we have seen more activity in developer tools than in the previous 15 years. This is largely due to generative AI and its ability to automate application development at all levels. The innovation has been rampant, with AI usage evolving from coding assistants led by GitHub Copilot to next-gen vibe coding tools like Cursor and Windsurf (all, coincidentally, built on top of Microsoft's open source VSCode IDE).
Interestingly, AWS has not gained much momentum among developers for its contributions to the AI development movement. And that's too bad, since AWS was the first company to adopt a multi-model strategy with its Bedrock API; it was one of the first to adopt MCP; and it even had agentic coding functionality before GitHub Copilot did, as I covered in May. Probably needless to say, the AWS team was frustrated by this; they recognized that maybe a new and more aggressive developer strategy was required. Which brings me to its new release — Kiro — which is arguably the biggest shift in developer strategy for AWS in years.
(Note: AWS is an advisory client of my firm, Moor Insights & Strategy.)
What Is Kiro?
Kiro is a new IDE built upon a fork of VSCode and, like a lot of other IDEs, it's vibe-friendly. But that definition is too limited when we consider the grounding assumptions that led to the development of Kiro.
Pre-release build of Kiro welcome screen
Does The World Really Need Another IDE?
I was approached in April to join a small group of non-AWS people to learn about and try Kiro before it went into preview mode. To be honest, my first reaction was 'Why do we need yet another IDE?' — and it took me a while to figure out my answer. After using Kiro and having further discussions with the team, I realized that Kiro does have a place and a perspective deserving of consideration from the enterprise. My rationale is as follows.
When I speak with devs today about vibe coding, I hear two conclusions. First is that vibe is great for building demos and MVPs, but the technology and tools aren't yet robust enough for scalable production code. Second is that the leading tool vendors of the vibe movement are startups that may ultimately end up being acquired by companies without enterprise credentials.
Clearly, AWS has the scale and enterprise experience to address both of those concerns. And AWS's experiences with AI development suggest that enterprise-grade vibe is a worthy and achievable goal. But the true mark of success will be enabling next-generation AI apps to be built with higher quality and bigger scale. Scale will come from better tools and access to services, which the Kiro team is suggesting they can achieve. Quality may require a different approach to vibe.
When I met with the Kiro team, I complained about the overemphasis on a single developer working with basic prompts. High-quality applications that get real-world adoption are the product of many stakeholders that provide very solid requirements for building not just code but also test plans. The fact is that when considering an enterprise app, a developer needs a mountain of different artifacts to shape the work and the app itself. In other words, the idea of someone just whipping up an app in a vibe-fueled vacuum is out of step with reality.
The team agreed, and that is why spec-driven development is more central to the Kiro experience. When you start a new folder, you can choose to work off of a spec or the prompt. And you can easily upload a wide range of artifacts to create the spec. I also was impressed with the Kiro team's take on using vibe to work with existing codebases. All too often, we see vibe in the light of starting at a Day 0 prompt, but again, in reality most developers spend most of their time working with code that is already established.
Having its own IDE opens up the Kiro team to have a lot more influence on the overall experience. Kiro includes: new windows for agent development such as accessing MCP servers; Agent Hooks, which are triggers to invoke agents or code; and agent steering, which is a way to globally inject context and scope into agents. These types of features were not available when limited to the plug-in-only model. Or a different way to look at this is that Kiro may be a vibe-oriented AI IDE, but you can still do all of your other work on it the way you'd like — as opposed to using a suite of different tools for different projects.
Kiro Has Real Potential
There's a lot to like about Kiro, especially if you are an enterprise developer. Yes, other vibe tools have a lot of similar capabilities, but I think the combination of vibe's ease of use combined with enterprise-class services is powerful. That said, this is a preview product and, as I have written before, preview products are in preview for a reason. So, after a few hours of testing and meeting with the team, here's what I would like to see next from them.
While I was initially skeptical, I am impressed by what I have seen so far with Kiro. I also am impressed that AWS was able to deeply consider where it wanted to go with developers and divorce itself from some long-held assumptions. There is a long path ahead, but I am excited to hear more about how Kiro matures and especially look forward to seeing what we learn at the AWS re:Invent show later this year.