Spec-Driven AI Coding — Why Kiro's 'Describe First' Workflow Breaks the Cursor Pattern

AWS shipped Kiro to general availability last month after a nine-month startup-only beta, and it is the first IDE from a hyperscaler that meaningfully changes the shape of the developer workflow rather than just wrapping a model in a sidebar. The interesting thing isn't that Kiro is "another AI IDE" — we have roughly seven of those now — but that Kiro is the first one to make a clear bet on a different primitive: the spec.

Most of the AI IDEs you've tried this year — Cursor, Windsurf, the Claude Code CLI, the GitHub Copilot Workspace beta — work on a "chat-then-edit" loop. You describe what you want, the assistant proposes changes, you accept or reject, and you repeat. It's productive. It also has a quiet problem: the intent that drove the change lives in a chat transcript that no-one ever re-reads, and the codebase diverges from the thinking that produced it.

Kiro's spec-driven workflow flips this. Before any code gets written, the assistant turns your description into an executable specification — a structured artifact that lives in the repo, gets version-controlled, and becomes the thing the code is measured against. The code is then generated, or hand-edited, in reference to that spec. When something breaks, the conversation starts with "is the spec wrong, or is the code?" rather than "what did we talk about three weeks ago?"

What just shipped

Kiro reached general availability in March 2026 after an unusually patient beta. It's built on VS Code (so the muscle memory and extension ecosystem come for free) and powered by Claude through Amazon Bedrock. Pricing is generous at the low end — there's a usable free tier — and scales through a $20/month Pro plan to a $200/month Power plan for heavier agent usage.

Three capabilities differentiate the product:

Spec-driven development. You describe a feature, Kiro turns it into a structured spec, and that spec is the source of truth. Changes to the code are checked against the spec; changes to the spec propagate into tasks for the code. The whole loop lives in the repo.

Agent hooks on file events. Hooks run AI tasks automatically on save — update docs when a function signature changes, regenerate tests when behaviour shifts, flag drift from the spec. The key word is "automatically": you don't have to remember to ask.

Multimodal input. Paste a screenshot of a UI you want to match, or an architecture diagram, directly into the chat. Kiro works off the image as first-class context rather than requiring you to describe it in prose.

Why this matters now

The AI IDE market is in a strange moment. Cursor and Windsurf both proved that a chat sidebar plus a strong model is enough to beat vanilla VS Code — and then every hyperscaler copied the pattern, which means "AI IDE" is now effectively undifferentiated on that axis. The question isn't whether your editor has a Claude or GPT sidebar. It's what shape of workflow the editor is organised around.

Spec-driven development is a real answer to that question. It's also not a new idea — behaviour-driven development, test-first, RFCs, design docs all sit in the same family. What's new is that an AI can now turn a loose description into a serviceable spec in under a minute, and keep it in sync with the code as both evolve. The spec was the bottleneck in the old pattern. Kiro collapses it.

This lines up with a broader shift. Teams that tried "vibe coding" — let the LLM write everything, review superficially — are hitting the predictable wall six to nine months in. Production codebases are accumulating subtle drift: functions that work but violate invariants no-one ever wrote down, tests that pass but miss the cases the original author cared about. Teams want the speed of AI-assisted work without the review debt. Making the intent explicit and version-controlled is the obvious fix. Kiro happens to ship it as a product.

How it compares

Against Cursor and Windsurf, Kiro is slower to start on small changes — the spec step adds friction on a two-line fix — but dramatically stronger on features that span multiple files or require the team to agree on behaviour before writing code.

Against Claude Code (the CLI), Kiro is the GUI alternative with state-management and spec tooling layered on top. You give up some of the raw flexibility of a terminal agent in exchange for a workflow that survives contact with a team.

Against GitHub Copilot Workspace, Kiro is further along on the "agents that work in the background" axis — the hooks are the feature GitHub is still working out how to frame — but behind on native GitHub integrations like PR-level review.

And against just-using-Claude-in-the-browser, Kiro is obviously a more integrated experience, with the cost that you're now tied to AWS for billing and Bedrock for model routing.

Where the caveats live

The spec is only as good as the review. An AI-generated spec you rubber-stamp is a chat transcript with a different file extension. The value of the pattern is that specs are short enough to read carefully. If your team won't read them, Kiro doesn't rescue you.

Bedrock is the model router. That's a feature if you're already on AWS and want one vendor relationship. It's a friction point if you want to freely route to the cheapest model of the week — Kiro is not trying to be OpenRouter.

Hooks can fire a lot. Agent hooks triggered on every file save sound great until you have a reformatting pass that touches 400 files. Start with a small hook footprint and expand deliberately.

Who should actually use this

Teams that have already tried "AI writes everything" and want the next posture. If you've felt the drift between intent and implementation over six months of heavy AI-assisted work, spec-driven is the pattern worth trying next.

AWS-anchored engineering orgs. Bedrock-native tooling, AWS SSO, enterprise billing — if you're already there, Kiro is the lowest-friction AI IDE to standardise on.

Solo developers shipping multi-feature projects. The spec step is most valuable when you're juggling several features at once and losing track of what each was supposed to do. Less valuable for single-file scripts.

Kiro is a cleaner bet for teams with a few engineers and a codebase they plan to keep for a year or two. It's overkill for hackathon projects and underkill for huge monorepos that already have strong RFC cultures.

The signal

Spec-driven AI coding is going to be the default shape of the workflow by the end of 2027. The industry is visibly reaching for something beyond chat-then-edit, and "intent as a version-controlled artifact" is the obvious next primitive. Whether the category converges around Kiro, a future Cursor release, or something Anthropic ships directly into Claude Code is the interesting question. AWS's advantage is that they're first, and that the ecosystem of teams already on Bedrock makes adoption cheap. The risk is that specs are a feature a strong competitor could absorb in a quarter.

For now, Kiro is the cleanest expression of the idea, and the free tier is generous enough that trying it on a real project costs nothing.

If you want to see where Kiro sits alongside the other developer-tools picks we track: the Kiro listing has the specifics, and the Developer Tools category is where we surface everything adjacent — Claude Code, Cursor, and the agent-layer tools like CrewAI — to pair it against if you're making a 2026 tooling call.