Kiro - AWS's Agentic AI IDE: The good, the bad and the ugly end of august 2025
Another “magic” IDE?
Recently, AWS has announced the availability of Kiro, it’s very own version of Cursor/Claude Code/<enter other random competitor name here>. Kiro promises developers to help them build faster and better software.
In this article, I’m sharing my perspectives and experiences, my feedback and thoughts on the current state of the new AWS DevTool end of august 2025.
Kiro is, at the time of writing this post, in “Preview”. Kiro is built on top of Visual Studio Code and available as a standaalone binary for download in (most) of the major platforms. As of today, you need an invite code to be able to use it.
A short introduction
Kiro comes as a basic IDE and when you start it for the first time, you feel “at home” if you’ve previously worked with Visual Studio Code. Because of that, you can extend it with existing Visual Studio Code extensions. Kiro shows a warning when you do that, but extensions aren’t blocked.
Looking at the UI, you can see the “usual” bar of an IDE on the left: explorer or source control, extensions and the Kiro-specific view, that allows you to configure specs, agents and MCP servers (more to that later).
On the rightern side, you can see the “chat” interface, your entry point to either “vibe” coding or “spec based development”.
The good
Simple start
Assuming the Preview phase ends soon, Kiro gives you as an individual developer the possibility to get started with your existing Github or Google account or with your AWS Builder ID. The UI also shows an option to authenticate with your existing AWS Identity Center (IDC). This however seems to not work properly today, using my Identity Center in Frankfurt I cannot authenticate to Kiro.
With offering the possibility to use Kiro with an AWS account (through Github or Google login), AWS was able to create a big traction on the tool initially as many developers wanted to try it out.
Familar UI
Being built on Visual Studio Code Open Source, Kiro brings everything you know and need with only minor improvements or changes. This is good, as it allows developers to directly feel comfortable.
Code quality
Kiro currently uses Cloud Sonnet 4.0 under the hood and the quality of code generated by the model is actually surprisingly good. It understands simple and complex requests pretty well and is able to create also large portions of code. Code quality is a common problem for most of the AI agent tools and I am sure that the models will improve further in the next weeks and months. potentially, more and better Coding specific models will become available and that will further improve the code quality.
Responsiveness
Interacting with the Kiro agent through the “vibe” based experience (the simple chat interface) is really responsive and the answers from the backend are fast and reliable. Only for the first 1-2 weeks after the preview has started there were a bunch of situations where the backend was “overloaded” with too much requests and I needed to wait for a few minutes.
Autopilot
Kiro comes with simple configuration options to “set the agent free”. You can white-list only specific commands or white-list commands based on wildcards. If you do that, the agent gets more freedom about and possibilities to continue working without interactions with the users. By using the appropiate configurations, you can still ensure that it doesnt exectues “unsecure” commands. Known “security risks” can also not be white-listed and require manual approval before the agent can execute them.
This makes the autopilot safe but secure which allowes the agent to self-develop bigger features on its own - see next section.
Spec based development
The idea of making “spec based” development one of the key features for Kiro is great - it forces users to think about “specifications” for a feature or an application that they want to build. From a simple prompts, the agent generates specifications and writes them into Markdown. These are then given to the LLM (eg Claude Sonnet 4.0) which is then going to generate a “design”, also as markdown. That design usually includes not only a good description of the feature but also a few diagrams to illustrate the changes. Using the specifications and the design, the agent then creates “tasks” that need to be implemented.
The user then has the freedom to either implement the features himself or to delegate the complete implementation to the coding agent.
The initial flow of using this feature works really well and in my tests I was able to run quickly through a complete set of tasks being implemented without manual intervention - Amazing!
The bad
I’ve spent alot of hours in Kiro during the last weeks and there are a few things that I found that can be improved.
Spec based development - end to end
Above I’ve called out the Spec based development flow “good”, but that’s only for the “initial” walk through. What happens if your applicaiton matures and you need to change some specifications? Changing specifications influences the design which influences the tasks which - ultimately - influences the generated code. But - what if I have changed the code and the code is not according to the specifications anymore?
I’m not sure on how this can work together - other code generation tools like Projen use the approach of declaring files “read-only”, but Kiro doesn’t do that.
Should the code be the “master” or should the specifications be the “guiding star”?
Kiro today doesn’t give an answer - what do you think?
Either can be implemented in Kiro with so-called “Hooks” - you can give the agent the guidance to after you have updated code re-generate specifications, design and tasks or you can ask the agent to automatically re-generate the code after you have changed the markdown files for specifications, design or tasks - up to you!
This is one of the bigger “things to solve” that Kiro has today, I think.
Recovery from failed code creations
The Kiro agent struggles today from time to time to generate and update your code. Some times it gets stuck and continuously iterates, but for me the bigger issue is that some times it creates code that can not be compiled!
I think this is something that the agent should notice before sending the code back to UI. I am always disappointed when the agent finished a task or somthing I asked him to do but I can’t use it as it contains compile issues or missing pieces. As mentioned above, the code quality created by the LLM model is something that all tools share and the underlying model is the source of the problem, however I would hope for Kiro to do a quality check before it’s presenting the results.
No enforcement of best practices
Today Kiro does’t support or enforce best practices - it only gives access to a “stupid” model and LLM. In fact, if you compare the results from Kiro and Q Developer Pro or also other similar tools the generated code base is similar. I would have hoped to have “best practices” enforced, e.g. to create unit and/or integration tests for newly generated or update code, or e.g. the different “serverless patterns”. coding style, linting, etc. are also not supported out of the box.
Yes, of course, you can make that work by giving the agent steering information (another functionality of Kiro), but it’s something that users need to create yourself. I’ve written down some additional thoughts below - on the target persona for Kiro.
Missing custom models or RAG
Related to the “best practices” ask above, it doesn’t look like the model behind Kiro has been pre-trained or augmented wit AWS specific code or knowledge - I believe this would help builders to create better AWS specific applications.
No out of the box integrations to MCP servers
AWS has made a lot of MCP servers available already including the Cloud API MCP server - but when you start up Kiro, the list of MCP servers in the UI is empty:
I think it might be a good thing to include the available AWS MCP services by default and allow users to activate/deactivate them if they would like to use them.
No offline usage
As I’m writing this article while being offline, I am thinking about a possibility to allow portions of the functionality to be used offline - similarly to Olama with a smaller model maybe? An “offline” or “local” mode would be cool :-)
No use in browser
Kiro today is only available on your desktop, and there is no support to continue your work in a browser to use it e.g. on your iPad :-) I’d love to have that possibility to be able to switch between devices, at least some times, or the possibility to “continue” my work from different devices continuing my session and conversation.
The ugly
In this section I’m calling out the “really ugly” things in Kiro that need fixing, some of them being minor things, others being more strategic things that the product team should address. In my role as an AWS Hero, I’ve also shared this feedback with the product team before.
I’d love to hear your thoughts and hear if I missed anythign that you believe needs to be addressed. Let me know by email or reach out to me on LinkedIn.
Pricing
If you’ve read this article until here I am sure that you have also seen and read the different announcements around the pricing for Kiro. You’ve also seen some back-and-forth if you’ve closely followed the product.
I believe that AWS needs to find a sustainable pricing for the tool, that allows everyone that wants to use it to try it out but at the same time covers for the costs of the generated GenAI services. While we don’t have any insights into those costs, we can only assume that most of the competitors are investing a lot of money into it’s usage. It’s hard to estimate how much the “preview” of Kiro is costing AWS, but given some of the reactions on socials it and the quick introduction of a waitlist after launch we can only assume that the interest was way higher than AWS expected and thus the preview must be a VERY high opex cost for AWS.
The pricing model needs to allow power users to use the tool as much as they want and still be affordable, and it needs to offer “small” users the possibility to pay only portions of the “power user” costs.
Since the pricing updates mid-august, I’ve also been thinking about the idea of “spec requests” vs. “vibe requests” - I find this a difficult differentiation as it gets really hard - some times a “spec request” gets to be a “vibe request” quickly and I am not sure it’s a wise idea to seperate those.
I’d like to acknowledge that AWS has reacted in a good way towards all of the feedback from the community (FROM YOU!) about the pricing, making Kiro free event until the 15th of september and re-funding already paid funds. The back and forth is difficult, but I hope that soon we will have a reliable pricing that works for most of us.
Kiro vs. Q Developer in the IDE / CLI
Kiro has created, in my view, an even bigger mess in AWS’ approach to developers and builders and on the generative AI tooling for them. Also, AWS seems to be working on both Kiro and Q Developer. With a lot of pressure on the teams to compete with other players on the market it seems like a strange approach to have more than one similar tool being developed by the same company.
With Kiro being newer I hope that AWS decides for “one strategy” instead of spreading the teams too thin - if AWS wants to be successfull, they will need to decide in which product to invest in as competitors have most probably more developers on a their tool than AWS has on Kiro today.
AWS needs to decide for a clear marketting and go-to-market strategy which brings me to my next point…
What’s the target persona?
Is Kiro targetted at Product Owners? Or at developers? At “starters” or at “senior developers”? As of today, Kiro tries to be one and everything and I think the picture needs to be clearer. Is the target audience “startups” that want to use it for rapid prototyping (using spec based development)? Or shuold it help seasoned developers to build complex solutions?
I’d hope that the Kiro team streamlines the market message and clarifies the audience of Kiro - it would help to understand the reasoning better.
While talking about Kiro with fellow AWS Heroes, we’ve come to the conclusion that Kiro is a “general IDE” and meant to re-place “your” Visual Studio Code or your Eclipse :-)
This might make the “target persona” a bit clearer as then “everyone” that develops or creates software is a “target audience” and that would then also make sense. We’ll need to see if AWS puts enough commitment into Kiro to make it “good enough” so it can really replace “your” favourite IDE.
Individual developer or enterprise?
While Kiro seems to be targetted at individual developers like me (supporting Github, Google and Builder ID authentication) and being “off” the AWS console, Q developer is today targetted at the enterprise developer. Time will tell if this changes and if Q Developer gets completely replaced by Kiro.
While most enterprises have the “enterprise support plan” and will be able to reach the Kiro team through the usual AWS support mechanisms, AWS will need to build a completely different support channel for users using Kiro with a social login (Github or Google). Right now, even for Q Developer, it is difficult to get support by AWS. There needs to be a strong connection to the users and a guarantee that support cases (or Discor messages) are answered within minutes or hours.
It’s from AWS, but …
…no AWS service in integrations at all?
At launch there was (and still is) no possibility to integrate Kiro with AWS services. No possibility to directly interact with your AWS resources, to deploy your application to Amplify or S3 or to execute CDK or CloudFormation deployments. It feels like Kiro was built completely without any “connection to the mother ship” - and this is my biggest criticism about it.
Because of the fact that Kiro doesn’t come with any “AWS specific knowledge” or “integrations”, it’s just another Agentic AI IDE on the market. AWS completely missed the Unique Selling Point (USP) of integrating the IDE with their own services or of powering up the IDE with AWS knowledge. Also, Kiro didn’t replace the ancient Cloud9 integration of “Dev Environments” in CodeCatalyst. It feels like and incomplete product launch and a miss in the product strategy to not integrate the IDE into it’s own ecosystem.
Was this done on purpose? Most likely, but then…
It’s an AWS DevTool…
…and AWS has a track record of disappointing builders and developers with it’s Developer Tools: CodeCommit (deprecated), AppRunner (no major updates), CodeCatalyst (no major updates anymore), Gitlab/Github integration for Q Developer…
How much can developers “trust” on Kiro being there for the long run? Time will tell, but this influences my own take on Kiro heavily.
What I can see is that AWS has been publishing a lot of different MCP servers, e.g. for the Cloud Control API or the different services. We’ll need to see and experience how it feels integrating them into Kiro and using them as part of the IDE - I don’t know how “integrated” it will feel and work.
Key takeaways, wishes and expectations
Kiro is a great tool, that can compete with all other players on the market.
The launch was solid with a lot of good features and functionality, allowing developers to play around and experimient quickly. Kiro has helped me to develop some of my projects way faster than I was able before.
When I ran out of credits for Kiro, I switched back to Q Developer in Visual Studio Code, and while working with it was different, Q Developer was still able to help me in the same way as Kiro.
Kiro feels smoother and better integrated from time to time, but there are a few pieces that I like more in Q Developer. It feels like AWS will need to learn from the different products and potentially merge the two.
I’ve already expressed some of my wishes for Kiro - let me add one more: If you want this tool to be successfull, you will need to develop it closely with the community that you are building around it (in Discord and on socials). I urge you to tell us builders everything that you change - have a change log in public, that explains every tiny change you do (and potentially why). Share a public roadmap that is “somehow” reliable and that users can potentially vote on (check out how Descript does that) - this could be integrated in the AWS Builder Center…
Another wish that I have is that the pricing details and structure should be transparent and it should explain the reasoning behind the model better than the first two tries for a pricing model.
And as Sebastién always says in the podcast: Thank you for reading this post until the end, if you have any thoughts of feedback, please reach out to me, I’m eager to hear your thoughts on Kiro and other AWS DevTools!