NathanKP

The original submission to HN stated that it was from Amazon / AWS in the title of the submission, however that has since been edited by a moderator to match the title of the blogpost, which does not mention Amazon / AWS.

To be clear, we have no intent to hide that Kiro is from Amazon / AWS, that's why you'll see Matt Garman, for example, posting about Kiro: https://www.linkedin.com/feed/update/urn:li:activity:7350558...

However, the long term goal is for Kiro to have it's own unique identity outside of AWS, backed by Amazon / AWS, but more friendly to folks who aren't all in on AWS. I'll admit that AWS hasn't been known in recent years for having the best new user or best developer experience. Kiro is making a fresh start from an outsider perspective of what's possible, not just what's the AWS tradition. So, for example, you can use Kiro without ever having an AWS account. That makes it somewhat unique, and we aim to keep it that way for now.

I have a personal deployment of the game, but it costs money to run the LLM so I'm not sharing that with all of Hacker News haha. I've got an appsec ticket open to host an "official AWS" version where AWS pays the LLM bill, but that might take a while longer to get approved. For now the best way to experiment is playing with it locally.

I'm also thinking of creating a fork of the project that is designed to run entirely locally using your GPU. I believe with current quantized models, and a decent GPU, you can have an adequate enough fully local experience with this game, even the dynamic image generation part.

Yeah it would be nice if there was one way to specify the rules and intent, but you know how these things go: https://xkcd.com/927/

In all seriousness, I'm sure this will become more standardized over time, in the same way that MCP has standardized tool use.

I've long been interested in something that can gather lightweight rules files from all your subdirectories as well, like a grandparent rule file that inherits and absorbs the rules of children modules that you have imported. Something kind of like this: https://github.com/ash-project/usage_rules

I think over time there will be more and more sources and entities that desire to preemptively provide some lightweight instructive steering content to guide their own use. But in the meantime we just have to deal with the standard proliferation until someone creates something amazing enough to suck everyone else in.

Unfortunately, midway through the project I lost the file where I was keeping track of all the prompts I used as I built. I do have some of them, plan to publish a wrap up analysis of those at some point.

If you were referring to the prompts inside of the game, you might find those fun and interesting. This one in particular is the heart of the game: https://github.com/kirodotdev/spirit-of-kiro/blob/main/serve...

It has grown over time as Kiro has developed. Many of the most recent features in Kiro were developed using Kiro specifications. We have a Twitch stream scheduled with some engineers from the Kiro team where we plan to take live Q&A about this in specific, how they are using Kiro to build Kiro, etc. I don't have the schedule setup yet, but we've got the channel setup here: https://www.twitch.tv/kirodotdev

At the prompt: "I have extensively used Copilot, Continue, Cursor, Cline, Aider, Roo Code, and Claude Code. I do not want to move my files over again for Kiro [even if it's as simple as dragging and dropping files]. Do it for me"

Kiro will do it for you automatically.

Thanks a lot! I plan to fork the project and make a generic version that runs entirely locally using your GPU to do everything. My early tests ran pretty well on NVIDIA 5070. So that's next on my project list to open source in my free time. The only thing more fun that building an AI agent, is using it to build your own ideas!

It's hard to directly compare, but 3000 interactions should be very, very high. Think of each of these 3000 interactions as you supplying a prompt that potentially runs for 3-5 minutes of Kiro iterating away on writing code. With appropriately sized prompts (most likely aided by spec mode), you could write a ridiculous amount of code.

For reference 3000 interactions * assumed 3 mins of AI work per interaction / 60 mins per hour / 8 working hours per day equals 18.75 working days of nonstop back to back AI coding. Typical month has 20-23 working days. But realistically you likely won't be using Kiro nonstop all day back to back, so 3000 interactions per month should more than cover your work month.

> Does Kiro have some special sauce for making this approach work better?

I'd like to think so, but you'd have to compare the results to what you are currently doing to see how you feel about it. I personally love the format that it uses to define requirements, and the details of the software design docs that it writes (including mermaid diagrams)

> will pricing essentially be bedrock pricing, or will there be a value-add margin tacked on?

The pricing is a flat rate, with a cap on number of interactions per month. Each human driven "push" for Kiro to do something is an interaction toward your limit, but Kiro may work autonomously for many turns based on an interaction, and will produce significant amounts of code from a single interaction.

More details here: https://kiro.dev/pricing/

MCP is great, but it adds a lot of extra latency. The MCP servers themselves will stuff your context full of tool details, taking up valuable tokens that could be spent on code context. Then at runtime the LLM has to decide to call a tool, the tool call has to come back to your machine, the data is gathered and sent back to the LLM, then the LLM can act on that data. Multiply this by however many rounds of tool use the LLM decides it needs prior to taking action. If you are lucky the LLM will do a single round of parallel tool use, but not always.

The advantage of something more purpose built for gathering context from the IDE is that you can skip a lot of roundtrips. Knowing the user's intent upfront, the IDE can gather all the necessary context data preemptively, filter it down to a token efficient representation of just the relevant stuff, add it in the context preemptively along with the user's prompt, and there is a single trip to the LLM before the LLM gets to work.

But yeah I agree with your point about CLI capabilities for running in parallel, integrating in other places. There is totally room for both, I just think that when it comes to authoring code in the flow, the IDE approach feels a bit smoother to me.

I'll look into this. Kiro is supposed to be doing progressive reindexing. When you make a change it should only have to reindex the files that changed. If you have any logs or other data you are willing to share, to help the team investigate you can use the "report a bug / suggest an idea" link at the bottom, or open an issue at: https://github.com/kirodotdev/Kiro/issues

I've got a longer personal blogpost coming soon!

But in the meantime I'm also the author of the "Learn by Playing" guide in the Kiro docs. It goes step by step through using Kiro on this codebase, in the `challenge` branch. You can see how Kiro performs on a series of tasks starting with light things like basic vibe coding to update an HTML page, then slightly deeper things like fixing some bugs that I deliberately left in the code, then even deeper to a full fledged project to add email verification and password reset across client, server, and infrastructure as code. There is also an intro to using hooks, MCP, and steering files to completely customize the behavior of Kiro.

Guide link here: https://kiro.dev/docs/guides/learn-by-playing/

I believe that the file indexing exclusion is based on .gitignore, not files.watcherExclude, but let me check on that and confirm.

You can do that!

There is an AWS IAM Identity Center option for login as well: https://kiro.dev/docs/reference/auth-methods/#aws-iam-identi...

We really need to add some more step by step docs for setting this up, but it's very similar to the Amazon Q Developer integration with AWS IAM Identity Center if you are familiar with that: https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/sec...

Stay tuned! I think there is definitely room for a CLI version as well. That said, IDE's have a significant advantage over CLI because of the features available to them. For example, the reason why IDE's feel "slow" is often because they just come with more features: automatic linters and code formatters, type checkers, LSP servers.

An agent running in the IDE can make use of all this context to provide better results. So, for example, you will see Kiro automatically notice and attempt to resolve problems from the "Problems" tab in the IDE. Kiro will look at what files you have open and attempt to use that info to jump to the right context faster.

The way I describe it is that the ceiling for an IDE agent is a lot higher than a CLI agent, just because the IDE agent has more context info to work with. CLI agents are great too, but I think the IDE can go a lot further because it has more tools available, and more info about what you are doing, where you are working, etc

A few things:

1) It's normal for Kiro (and almost every AI editor) to use a lot more CPU when you first start it up, because it is indexing your codebase in the background, for faster and more accurate results when you prompt. That indexing should complete at some point

2) On initial setup of Kiro it will import and install your plugins from VS Code. If you have a large number of plugins this continues in the background, and can be quite CPU heavy as it extracts and runs the installs for each plugin. This is a one time performance hit though.

3) If your computer is truly idle, most modern CPU's get throttled back to save power. When the CPU is throttled, even a tiny amount of CPU utilization can show up as a large percentage of the CPU, but that's just because the CPU has been throttled back to a very slow clock speed.

In my setup (minimal plugins, medium sized codebase, computer set to never idle the processor clock) I rarely see Kiro helper go above .4% CPU utilization, so if you are seeing high CPU it is likely for one of the above reasons.

Realistically, none of the models can function fully autonomously at this point. You still need a skilled human at the helm. However, AI tools definitely change how the human works. I find that I spend a lot less time thinking about easy things, and a lot more time thinking about hard things.

Basically, the AI fast forwards through the easy stuff and I just spend all day jumping directly from hard problem to hard problem.

It works great in really large codebases!

I've published a sample project that is medium sized, about 20k lines encompassing a game client, game server, and background service: https://github.com/kirodotdev/spirit-of-kiro This has been all developed by Kiro. The way Kiro is able to work in these larger projects is thanks to steering files like these:

- Structure, helps Kiro navigate the large project: https://github.com/kirodotdev/spirit-of-kiro/blob/main/.kiro...

- Tech, helps Kiro stay consistent with the tech it uses in a large project: https://github.com/kirodotdev/spirit-of-kiro/blob/main/.kiro...

And yes, the specs do help a lot. They help Kiro spend more time gathering context before getting to work, which helps the new features integrate into the existing codebase better, with less duplication, and more accuracy.

Thanks for the additional info!

Thanks so much for your feedback Corey! That's one of the big goals of Kiro: to add a bit more of the rigor required to keep your code projects sane as they grow over time. I think Kiro hits the best of both worlds: the easy fun of "vibe coding" at first but then when its time to do some software engineering, Kiro is there to help dig deep into the technical requirements, write the architectural design, and break the big project up into reasonable tasks.

Thanks for the report! I'll keep an eye on it. So far we aren't seeing any other reported issues, so it's possible that a browser extension, or something else in your setup is messing with the SSO flow.

Redirect back to localhost:3128 is normal, that's where Kiro is watching for a callback, but the missing state is not normal. Something may have stripped the info out of the callback before it occurred, which is why I suspect an extension in your browser.

Will keep an eye on this though!

This is much more tricky than you'd think. Claude Code and other similar tools only work as well as they do because the prompts that power it have been tuned to match a specific model.

When you make a tool that is "model agnostic" you also make a tool that is unable to play to the individual strengths of each model, or you set yourself up for a massive, multiplicative effort of trying to tune your tool to every single popular model out there, even though some of the models are drastically less capable than others.

Kiro does have autocomplete. It's just not advertised on the product page as a star feature.

In my experience using Kiro you are still going to be hands on with the code. Personally I choose to turn AI powered autocomplete off because when I do touch the code manually it's usually for the purposes of working on something tricky that AI would likely not get right in autocomplete either.

However, the Kiro autocomplete is average in capability in my experience, and you can absolutely use it to write code by hand as well.

I love Claude Code too, and it definitely has it's place. I think that IDE's have a few advantages over CLI tools though. In specific the IDE has a lot more contextual information such as what files you have open, warnings from linters or type checkers, information from LSP, etc.

I think it is entirely possible to build a fantastic CLI tool for coding, and the CLI tools for coding already work well enough, but there is just more context info available inside of an IDE, therefore the ceiling is higher when working with an agent that runs inside of the IDE. Context is king for LLM results, and IDE's just have more context.

Over time I'm sure we'll see tools like Claude Code support everything that an IDE can do, but for now if you want to reach the same ceiling you still have to glue together a very custom setup with MCP tool use, and that has the downside of introducing additional tool use latency, compared to an IDE that is able to source context directly from the IDE's internal API, and provide that to the LLM nearly instantly.

Kiro is created by an AWS team, and originates from AWS expertise. We are using Kiro internally as one of our recommended tools for development within AWS (and Amazon). So Kiro is an official AWS product, however, we are also keeping it slightly separated from the rest of core AWS.

For example, you can use Kiro without having any AWS account at all. Kiro has social login through Google and GitHub. Basically, Kiro is backed by AWS, but is it's own standalone product, and we hope to see it grow and appeal to a broader audience than just AWS customers.

At this time Kiro is a standalone product that does not require an AWS account at all. Kiro is powered by Bedrock behind the scenes, but it has a layer of abstraction between Kiro and Bedrock, which includes system prompts and additional functionality. I can definitely take this as a feature request though!

You will be happy to find out that Kiro is quite good at this! One of my favorite features is "Steering Rules". Kiro can help you write steering rules for your projects, and the steering rules that it auto generates are actually super great for large projects. You can see some examples of auto generated steering files here in one of my open source projects: https://github.com/kirodotdev/spirit-of-kiro/tree/main/.kiro...

Also these steering rules are just markdown files, so you can just drop your other rules files from other tools into the `.kiro/steering` directory, and they work as is.

Currently specifications are mostly static documents. While they can be refreshed this is a more manual process, and if you do "vibe coding" via Kiro it can make code changes without updating the specs at all.

I find the best way to use specs is to progressively commit them into the repo as an append only "history" showing the gradual change of the project over time. You can use Kiro to modify an existing spec and update it to match the new intended state of the project, but this somehow feels a bit less valuable compared to having a historical record of all the design choices that led from where you started to where you now are.

I think in the long run Kiro will be able to serve both types of use: keeping a single authoritative library of specs for each feature, and keeping a historical record of mutations over time.

There is a model picker that currently allows you to switch between Claude Sonnet 4.0 and Claude Sonnet 3.7

And yes, Kiro is agentic, so it can (and often does) execute a long running multi-turn workflow in response to your interactions, however, the billing model is based on your manual interaction that kicks off the workflow (via chat, spec, or hook), even if that agent workflow takes many turns for Kiro to complete

Actually yes! I saw this post some months ago, and thought to myself: "Wow this is really close to what we've been building". Kiro uses three files though: requirements, design, and then tasks. The requirements doc is a bunch of statements that define all the edge cases you might not have originally thought of. Design looks at what is currently in the code, how the code implementation differs from the requirements, and what technical changes need to happen to resolve the difference. Then tasks breaks the very large end to end development flow up into smaller pieces that an LLM can realistically tackle. The agent then keeps track of it's work in the tasks file.

Realistically, I don't think that Harper's statement of "I get to play cookie clicker" is achievable, at least not for nontrivial tasks. Current LLM's still need a skilled human SDE in the loop. But Kiro does help that loop run a lot smoother and on much larger tasks than a traditional AI agent can tackle.