Kiro and Spec-Driven Development: Putting Requirements Back into AI Coding

Kiro was launched as a reaction to the limits of prompt-first coding

When Kiro appeared in July 2025, its launch message explicitly contrasted the speed of “vibe coding” with the difficulty of turning a quickly prompted prototype into software that a team can understand, maintain, and operate. Kiro was presented as an agentic IDE that could still work conversationally, but its distinctive argument was that requirements and design decisions should become durable project artifacts before implementation races ahead. The launch framed uncertainty about assumptions, behavior, architecture, testing, and maintenance as a coordination problem between developers and AI rather than merely a model-quality problem.^[1] That framing mattered because the first wave of coding assistants had made generation dramatically cheaper while leaving planning, review, and institutional memory largely outside the tool.

Specs turned an informal request into a sequence of artifacts

Kiro’s spec flow decomposed work into requirements, design, and implementation tasks. Instead of treating the initial prompt as the only source of truth, the system created files that could be reviewed, edited, versioned, and revisited as the feature evolved.^[1]

Spec-driven development changed what the coding agent was asked to optimize

In a prompt-only workflow, an agent can appear successful by producing plausible code quickly. A specification changes the target: the agent must satisfy stated behaviors, constraints, and design decisions across a sequence of tasks. Kiro’s early design therefore made planning an explicit part of the development loop rather than an invisible chain of reasoning. The point was not to reproduce heavyweight waterfall process. Requirements could change, and developers could iterate on the artifacts, but the decisions were made inspectable. That distinction became more important as coding agents began editing multiple files and handling changes whose correctness could not be judged from one generated function alone.

Hooks made project guidance executable rather than merely advisory

Kiro also introduced event-driven hooks that could run agent tasks when files were created, saved, or changed. The launch examples included updating tests and documentation or checking project-specific standards, turning team expectations into repeatable automation rather than instructions developers had to remember on every prompt.^[1]

General availability pushed the idea from individual workflow toward team practice

Kiro reached general availability in November 2025. By then the product had expanded beyond the original preview with a CLI, team plans, checkpointing, and property-based testing intended to check whether implementation behavior matched a specification.^[2] That progression is historically useful because it shows how quickly the category moved from “AI editor” toward a software-engineering environment. A spec was no longer only a prompt scaffold. It could participate in correctness checks, shared team conventions, and terminal workflows. Kiro’s pitch increasingly treated the agent as another participant in an engineering process that needed contracts and feedback rather than as an autocomplete system that happened to be powerful.

Property-based checks made the specification testable

The general-availability release tied specifications to generated correctness checks, reinforcing the idea that a useful requirement should constrain observable software behavior instead of remaining prose that nobody verifies.^[2]

Kiro later made the spec flow less rigid rather than abandoning it

One risk of specification-first work is that structure becomes ceremony. In May 2026 Kiro revised its spec workflow so clear tasks could move faster while ambiguous work could still stop for clarification, and independent tasks could be handled in parallel.^[3] That update is important to the history of the idea because it acknowledged the central tension in AI-assisted development: planning can prevent expensive mistakes, but forcing every small change through the same amount of process can erase the speed advantage that attracted developers to agents in the first place. Kiro’s answer was to make structure adaptive rather than optional.

The web version separated specification work from one local IDE session

Kiro Web, introduced in May 2026, extended the product into remote autonomous sessions that could clone repositories in isolated cloud sandboxes, make changes, and open pull requests.^[4] The structured spec workflow followed onto the web soon afterward. This shifted the meaning of “spec-driven” again. A specification could now be the handoff contract for work performed while the developer was elsewhere, not only an aid inside an interactive editor. Steering files and repository conventions also became a way to give remote sessions durable organizational context. The move connected Kiro’s planning emphasis with the broader trend toward asynchronous agents that work from a queue of delegated engineering tasks.

One year of Kiro showed that planning had become part of the product identity

On the first anniversary of Kiro’s launch, the team said more than 100,000 developers had tried the IDE in its first five days and described spec-driven development as the central idea that resonated with users.^[5] Company adoption figures should be read as vendor-reported evidence rather than an independent market measure, but they still reveal what Kiro chose to emphasize about itself. The product did not try to win by claiming that requirements were obsolete. It argued the opposite: as code generation became abundant, developers needed better ways to capture intent, sequence work, and keep human and machine collaborators aligned over time.

Structure became a response to faster generation

The paradox of agentic coding is that cheaper implementation can increase the value of explicit decisions. When producing another version is easy, the scarce resource becomes agreement about what the system should do and why.^[5]

Spec-driven AI was not a return to heavyweight software process

Kiro’s history is best understood as an attempt to insert lightweight engineering artifacts into a fast, conversational workflow. Its specs were generated and revised with the agent; hooks automated repetitive checks; later releases made tasks parallel and remote. That is different from treating a signed specification as an immutable contract. The useful historical distinction is between visible and invisible intent. Kiro made requirements, design, tasks, steering, and validation first-class objects that could survive beyond one chat transcript. Whether a team wants that level of structure depends on the work, but the system demonstrated that “agentic” did not have to mean “unplanned.”

Why Kiro belongs in the history of vibe coding

Kiro belongs in this history because it challenged one of vibe coding’s strongest early assumptions: that the shortest path from idea to software is always to keep prompting until the output looks right. Its alternative was to preserve the fluidity of natural-language development while reintroducing explicit requirements, design, tasks, project guidance, and checks.^[1][3] By 2026 those artifacts were also being used to supervise autonomous cloud work, showing how specifications could become interfaces between humans and agents rather than documents written only for human teams. The larger lesson is not that every change needs a formal spec. It is that faster code generation makes the quality of the handoff more important, because an agent can implement a misunderstanding just as efficiently as it can implement the right idea.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES

1. 01
   Kiro — Introducing Kiro ↗kiro.dev
2. 02
   Kiro — Kiro Is Generally Available ↗kiro.dev
3. 03
   Kiro — Specs Just Got Faster (and Smarter) ↗kiro.dev
4. 04
   Kiro — Introducing Kiro Web ↗kiro.dev
5. 05
   Kiro — One Year of Kiro ↗kiro.dev

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.