Kiro After the Hype: What AI IDEs Actually Changed

Eight months after Kiro reached general availability, the durable idea turns out to be the spec, and the least durable part turns out to be the IDE. Kiro shipped as an agentic IDE whose pitch was that you work at the specification level and let the agent implement. The part that stuck is the artifact: a written statement of intent that a human reviews before code exists. The part that quietly lost is the assumption that the editor is where this happens. Kiro shipped a CLI at GA, added headless mode, and the terminal is where the interesting usage went.

I wrote about Kiro's GA at the end of last year in AWS Monthly (Dec '25): The Kiro Era Begins, with more enthusiasm than distance. Eight months is enough time to say which parts of that held up.

What actually shipped

Kiro went into preview in July 2025 and reached GA on 17 November 2025. GA was not a stability release, it was a scope release: property-based testing that derives test cases from a spec's acceptance criteria, checkpointing so an agent's changes can be rewound, multi-root workspace support, team plans managed centrally through AWS IAM Identity Center, and Kiro CLI, which put the agent in the terminal.

Since then the trajectory has been consistent and unglamorous. Kiro CLI picked up headless mode in April 2026, so the agent runs in pipelines rather than beside a human. The January 2026 CLI releases were about allowlists and blocklists for which URLs an agent may fetch, keyboard shortcuts for custom agents, better diffs. That is not a roadmap chasing a demo. It is a tool being fitted to production, and the shape of the fitting tells you what people are actually doing with it.

The spec was the good idea

Kiro's actual contribution is that it made the specification a file. Requirements, design, and tasks, in the repo, versioned, reviewable, diffable. That sounds like a small thing next to "AI writes your code" and it is the only part I would defend without qualification.

The reason is where it moves the review. Ungoverned agentic coding produces a large diff and asks a human to evaluate it after the fact, which is the worst possible moment: the work is done, the author is a machine with no memory of its reasoning, and rejecting it means throwing away something that looks finished. Reviewing a spec inverts that. You are reading intent, at the point where changing it costs a sentence. The economics of "no, not like that" are completely different before and after implementation.

That property has nothing to do with AI, which is precisely why it survived. It is design review with a shorter feedback loop, and it holds whether the implementer is an agent, a contractor, or you next Tuesday.

Where it did not hold

Three honest failures, and they were all visible early to anyone who used it on real work.

Specs drift

Requirements and design get generated up front and do not update themselves when implementation reveals that the design was wrong. Teams report exactly the dynamic you would predict: the code moves, the spec does not, and within a few weeks the spec is a document describing a system that no longer exists. That is not an AI failure, it is the oldest failure in software documentation, reintroduced by a tool that made the document cheap to produce and no cheaper to maintain. Cheap to write and expensive to keep true is the specific combination that generates stale artifacts.

The overhead does not fit small work

The blunt version, from people who tried it on a small bug fix, is that the spec workflow is a sledgehammer for a nut. Requirements, design, and task breakdown to change a validation rule is worse than just changing the validation rule. The ceremony is proportional to nothing, and most engineering work is small.

The rigidity is real

Spec-first assumes you know what you want before you start. A lot of software is written by people finding out what they want by writing it. For exploratory work, front-loading the specification is not discipline, it is a guess formalized into a document that now has authority it did not earn. The critique that spec-driven development reimports waterfall dynamics is not entirely fair, but it is not entirely wrong either, and the difference depends on whether your team treats the spec as a contract or as a draft.

So who is it for

The pattern that emerged is narrower than the pitch and more defensible. Specs earn their overhead when requirements are ambiguous, when the people involved are distributed enough that shared understanding cannot be assumed, or when traceability is an obligation rather than a nicety. In a regulated context, "here is the reviewed spec, here is the diff that implements it" is not overhead. It is the audit artifact you would have had to construct anyway, produced as a byproduct.

For a small team on a well-understood codebase, the overhead is mostly cost. That is not a criticism of Kiro. It is a scoping statement that the marketing was never going to make.

What AI IDEs actually changed

Here is the retrospective claim, and I hold it loosely.

The change was not that AI writes the code. That happened, it is genuinely useful, and it is now unremarkable enough that arguing about it is boring. The change is that the unit of human review moved upstream, from the diff to the intent. Kiro's specs are one implementation. AGENTS.md and steering files are another. The pattern is the same: humans author constraints and review intent, agents produce implementations, and the artifact humans argue over stops being the code.

The second change is that the IDE turned out not to be the right container. Kiro's own CLI and headless mode make the point better than any critic could. If a human is not reading each change as it lands, the editor is a UI for something that no longer needs one, and the agent belongs where the rest of your automation lives. The IDE was the on-ramp, not the destination.

The takeaway

Eight months post-GA, Kiro's lasting contribution is the specification as a reviewable, versioned file, which moved human judgment to the point where it is cheapest to apply. The costs are real and specific: specs drift because generating them is cheap and maintaining them is not, and the ceremony does not fit small or exploratory work. Use it where ambiguity or traceability justify the overhead and skip it where they do not. And notice that the agentic IDE's most useful output was a CLI, which is the industry telling you where this is going.