Companies would benefit a lot by creating better onboarding flows that migrate users from other applications. It should either bring in the rules 1:1 or have an llm agent transform them into a format that works better for the agent.
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.
“Kirk is actually quite good at this: you just have to do X”
“…”
Kiro will do it for you automatically.
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.
Was it built to only adhere to what is in .kiro folder?
As for a hypothetical new "context setup" protocol like you posit, I suspect it'd benefit from the "cognitive tools" ideas in this awesome paper / project: <https://github.com/davidkimai/Context-Engineering>
^ inspiring stuff
Then I add it as a git submodule to my projects and tell whatever agents to look at @llm-shared/ and update its own rule file(s) accordingly
That way I can just add new stuff to llm-shared/, commit, push and other projects will get the same things. It also forces me to keep it generic so it fits every project.
Then I just tell whatever LLM to look into @llm-shared/ for instructions and refer to files there when needed instead of having them in the "main" context file.
I found this approach to be quite poor from the standpoint of cloud seems to treat user instructions very differently than other agentic code assistants and I think it’s because their system prompt is so long. As a result, I’m getting some pretty poor adherence to my claude.md file and I’ve noticed that very rarely if ever have I seen it reverse the file to any of the nested paths.
So.. im going to try to refactor my files to keep it all in the same file, with some heavy “LOOK AT ME” prompt engineering.
How about you?
We are a few months into widespread use of this class of technology. Now is a terrible time to introduce standards. Would be a small short term gain delivering huge long term pain.
My CLAUDE.md and GEMINI.md both just say "See AGENTS.md".
The idea of having a bunch of A100 GPU cycles needed to process the natural language equivalent of a file pointer makes me deeply sad about the current state of software development.
Creating a MCP server that all the agents are configured to retrieve the rules from?
you can do this today though.
Some agents have multiple prompts that are used for different modes; I’ve typically seen this stored as JSON that is agent specific and wouldn’t necessarily apply to different agents.
The only agent specific thing I’ve ever included in a context file is referring to a specific tool. I probably could have abstracted that by describing it as “the tool that does X” or by just telling it to do the function that the tool does.
>overage charges for agentic interactions will be $0.04 per interaction, and if enabled, will begin consuming overages once your included amounts are used (1,000 interactions for Pro tier, 3,000 for Pro+ tier). Limits are applied at the user level. For example, if you are a Pro tier customer who uses 1,200 requests, your bill would show an overage charge of $8 (200 × $0.04). Overages for agentic interactions must be enabled prior to use.
What is defined as an interaction?
EDIT: RTFM
>Whenever you ask Kiro something, it consumes an agentic interaction. This includes chat, a single spec execution, and/or every time an agent hook executes. However, the work Kiro does to complete your request—such as calling other tools, or taking multiple attempts—does not count towards your interactions.
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
How does Kirk deal with changes to the requirements? Are all the specs updated?
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.
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.
This recent OpenAI presentation might resonate too then:
Prompt Engineering is dead (everything is a spec)
In an era where AI transforms software development, the most valuable skill isn't writing code - it's communicating intent with precision. This talk reveals how specifications, not prompts or code, are becoming the fundamental unit of programming, and why spec-writing is the new superpower.
Drawing from production experience, we demonstrate how rigorous, versioned specifications serve as the source of truth that compiles to documentation, evaluations, model behaviors, and maybe even code.
Just as the US Constitution acts as a versioned spec with judicial review as its grader, AI systems need executable specifications that align both human teams and machine intelligence. We'll look at OpenAI's Model Spec as a real-world example.
Have you considered a fourth file for Implemented such that Spec = Implemented + Design?
It would serve both as a check that nothing is missing from Design, and can also be an index for where to find things in the code, what architecture / patterns exist that should be reused where possible.
And what about coding standards / style guide? Where does that go?
Coding standards / style guide are both part of the "steering" files: https://kiro.dev/docs/steering/index
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.
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!
I think Auth can be a bit of mess, but yes Its still absolutely great that I can just login with github and it just works, I am trying out Kiro right as we speak!
Same error as for Google
Then in Kiro I see "There was an error signing you in. Please try again.".
FWIW, I've tried GitHub & Google, in different browsers, on different networks.
I personally run my proxy there and overall I'd take some > 10000 port for such kind of stuff
Or can you join the Discord and message me directly @swaminator
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...
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.
That said, thanks for being willing to demo what kinds of things it can do!
It actually has a pretty decent free tier, and maybe the subscription is better value than Claude Code, but hard to tell.
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
IDEs don't feel slow, they ARE slow
because written in HTML and Javascript
go and try Delphi from 2005, it's blazing fast (and more functional...)
In my opinion, CLIs have a higher ceiling, and then they are easy to integrate into CI/CD, run them in parallel, etc.
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.
What people do to avoid what you discussed, is multi-agents. The main agent can build up context, plan, than delegate execution to other agents, etc.
In my opinion, the benefit of the IDE is really just in the possibility of an improved UI/UX over a TUI.
- cmd-t fuzzy finding files of cmd-p finding symbols to open the various files that are relevant
- selecting a few lines in each file using fast IDE shortcuts to move and add
- drag and drop an image or other json files into prompt
- not leave the editor im already working on
Not to mention:
- viewing the agents edits as a diff in the editor and all the benefits of easily switching between tabs and one click rejecting parts etc
- seeing the sidebar of the agents thoughts and progress async alongside the code as I keep looking at things
- pausing the agent and reversing back steps visually with the sidebar
- not having to reconfig or setup my entire dev environment for some CLI - for example the biome v2 lsp just works since it’s already working in code which has the best support for these things
And really the list of reasons an editor is far better just never ends. Claude is ok, but I’m way way faster with Cursor when I do need AI.
Also,I don't mean to be rude to cursor but the fact that they are literally just a vscode wrapper still, to this day makes me really crazy thinking that the value of an AI editor could be so high..
I think it was the lack of competition really, Cursor (IMO) always felt like the biggest player, I think there was continue.dev before that, but that's all I know before Cursor.
After Cursor became a hit, there are lot more things now like (Void editor?) etc.
Also, if you Find Vscode editor slow, try zed. But like my brother said to me when I was shilling zed, Vscode is just for manipulating texts and using LSP. He personally didn't feel like it was there any meaningful slowness to Vscode even though he had tried zed. Zed has Ai stuff too iirc
Now Sure, they could've created CLI, but there are a lot of really decent CLI like SST/opencode and even gemini cli. Though I have heard good things about claude code too.
Honestly, I just think that any efforts in anything is cool. I just like it when there are a lot of options and so things stay a little competitive I guess.
Isn't that like all software. Before Claude 4 and Copilot agent mode, Cursor/Cline did a lot of work under the hood to achieve the same agentic capabilities, that stuff has nothing to do with VSCode.
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.
Is there any way to control this? I have my files.watcherExclude setting, does it respect that?
However with a large project, it seems that it indexed, then dropped CPU, then I started opening up files and working with them, then the CPU spiked again.
ActiveX and Java Web Start, etc all tried to do this, and all of them ended up deprecated and out of favor for native web solutions.
Java IDEs did a lot of this for many years (Eclipse, IntelliJ, NetBeans, JDeveloper, etc) and they worked reasonably well on the desktop, but had no path to offering a web hosted solution (like gitpod or codespaces)
There are not a lot of options here, compiling down a native solution to wasm and running it in the browser would work, I'm not sure if the performance would be substantially better or more consistent across all OS'es and web unfortunately.
So we are where we are :)
Qt is pretty good at this actually. I don’t have a Mac, but building the same codebase for windows, linux, and a wasm target was pretty neat the first time I did it.
Not really. Electron is basically web browser.
The issue is that a cornerstone of modern development is basically "don't rewrite what already has been written", however the problem is that you always get optimization creep because of this - people just build shit on top of other shit continuously and never go back and optimize.
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/
This, along with the "CHALLENGE.md" and "ROADMAP.md" document, is an incredibly cool way to show off your project and to give people a playground to use to try it out. The game idea itself is pretty interesting too.
It would be awesome if I ... didn't have to deal with AWS to use it. I guess maybe that might be a good use case for agentic coding: "Hey, Kiro - can you make this thing just use a local database and my Anthropic API key?"
Complaining aside though, I think that's just such a cool framework for a demo. Nice idea.
Neither VSCode nor Cursor do this, so even if it's an extension triggering it somehow, the behaviour in Kiro is different to those other two.
I wrote more about Spec Driven AI development here: https://lukebechtel.com/blog/vibe-speccing
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.
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...
I integrated[1] the recently released Apple Container (instead of shell) to run codes generated by Kiro. It works great!
1. CodeRunner: https://github.com/BandarLabs/coderunner
HN comments aren't an ad network...
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.
Looks like YC founders bully people coming over to HN for commenting.
not sure why you brought up YC, not relevant at all
I think its because you didn't have hard expectations for the output. You were ok with anything that kind of looked ok.
Just because you use AI does not mean that you need to be careless about quality, nor is AI an excuse to turn off your brain and just hit accept on the first result.
There is still a skill and craft to coding with AI, it's just that you will find yourself discarding, regenerating, and rebuilding things much faster than you did before.
In this project I deliberately avoided manual typing as much as possible, and instead found ways to prompt Kiro to get the results I wanted, and that's why 95% of it has been written by Kiro, rather than by hand. In the process, I got better at prompting, faster at it, and reached a much higher success rate at approving the initial pass. Early on I often regenerated a segment of code with more precise instructions three or four times, but this was also early in Kiro's development, with a dumber model, and with myself having less prompting skill.
If there was such a thing you would just check in your prompts into your repo and CI would build your final application from prompts and deploy it.
So it follows that if you are accepting 95% of what random output is being given to you. you are either doing something really mundane and straightforward or you don't care much about the shape of the output ( not to be confused with quality) .
Like in this case you were also the Product Owner who had the final say about what's acceptable.
If they are saying the code in this project was in line with what they would have written, I lean towards trusting their assessment.
> in line with what they would have written,
point i am making is that they didn't know what they would've written. they had a rough overall idea but details were being accepted on the fly. They were trying out bunch of things and see what looks good based on a rough idea of what output should be.
In a real world project you are not both product owner and coder.
I am not, and don't expect to be able to do that for many years yet. The models aren't that good yet.
I would estimate that I accepted perhaps 25% of the initial code output from the LLM. The other 75% of output I wasn't satisfied with I just unapplied and retried with a different prompt, or I refactored or mutated it using a followup prompt.
In the final project 95% of the committed lines of code in the published version were written by AI, however there was probably 4x as much discarded AI generated code along the way that was also written by AI. Often the first take wasn't good enough so I modified it or refactored it, also using AI. Over the course of using the project I got better at providing more precise prompts that generated good code the first time, however, I rarely accepted the first draft of code back from Kiro without making followup prompts.
A lot of people have a misguided thought that using AI means you just accept the first draft that AI returns. That's not the case. You absolutely should be reading the code, and iterating on it using followup prompts.
Will be trying Kiro, excited to see how you approached implementing a similar idea!
I love this approach using specs and steering. Just curious how it would work in a huge monorepo with many apps and packages in one physical repo. Several hundred devs work with that repo.
Is it possible to have two layers of steering, which is monorepo specific and then app specific? And also regarding specs, would the different apps and teams interfere with each other?
Best, Icereed
In specific, I'm really proud of "spec driven development", which is based on the internal processes that software development teams at Amazon use to build very large technical projects. Kiro can take your basic "vibe coding" prompt, and expand it into deep technical requirements, a design document (with diagrams), and a task list to break down large projects into smaller, more realistic chunks of work.
I've had a ton of fun not just working on Kiro, but also coding with Kiro. I've also published a sample project I built while working on Kiro. It's a fairly extensive codebase for an infinite crafting game, almost 95% AI coded, thanks to the power of Kiro: https://github.com/kirodotdev/spirit-of-kiro