vibe·code24/7
← all news
·4 minawskiroidespec-drivenagentstoolingamazon-q

aws kiro is generally available — spec-driven development replaces amazon q developer

AWS Kiro launched GA on May 7, 2026, replacing Amazon Q Developer as AWS's primary coding IDE. The differentiator is spec-driven development: before any code is written, Kiro formalizes your intent into a requirements document (EARS notation), a technical design with data flow diagrams and API schemas, then generates and iterates on code. Hooks automate tasks like test regeneration on file save — and they're free, not counted against your quota.

AWS Kiro launched as generally available on May 7, 2026, and simultaneously retired Amazon Q Developer as the company's primary coding IDE. the core pitch is simple: before Kiro writes a line of code, it formalizes what you want — requirements, design, and then generation — rather than jumping straight from a prompt to an implementation that drifts the moment the context gets complex.

the spec-first workflow

the workflow has three phases, and the sequencing is intentional:

first, Kiro turns your prompt into a requirements document using EARS (Easy Approach to Requirements Syntax) — a structured format developed for safety-critical software engineering where ambiguous requirements are especially costly. each requirement comes with user stories and acceptance criteria. you review and adjust this before anything is built.

second, Kiro analyzes your existing repository and produces a technical design document: data flow diagrams, TypeScript interfaces, database schemas, and API endpoints. this is generated from your actual codebase, not a blank slate — so the design accounts for what's already there rather than proposing architecture that conflicts with it.

third, code generation runs within the constraints that the first two phases established. Kiro writes files, runs tests, and iterates within limits you set. the model can't silently expand scope or produce code that contradicts the approved design, because the design document acts as a guardrail on the generation.

this addresses a specific and documented failure mode of current agentic coding tools: code that works on a narrow set of test cases but drifts from the intended architecture, misses edge cases embedded in requirements, and breaks down under production conditions because the agent didn't know the full system context when it generated each piece.

hooks: event-driven automation that's free

hooks are declarative automations written in natural language that trigger on file system events. examples: “on file save, regenerate the relevant unit tests”; “on API schema change, update the OpenAPI documentation.” they run without consuming your usage quota — hooks are exempt from the credit system entirely.

this matters for practical workflows. if you use Kiro on a codebase where you want tests to stay in sync with implementations or docs to stay in sync with interface changes, those automations don't eat into your monthly interactions. the hooks themselves are stored as declarative config, so they can be committed and shared across a team.

sub-agents and model flexibility

Kiro ships with sub-agents: specialized agents with their own prompts and tool configurations for context gathering, custom agent creation, and general task execution. the underlying model is configurable — Claude, Cursor's model layer, and Codex are available alongside AWS Transform agents for specific AWS service workflows (CDK migrations, Java upgrades, test suite generation).

pricing

free tier: 50 interactions per month, no credit card required. Pro: $20/month for 1,000 credits with per-prompt visibility into credit consumption. Pro Max: unlimited interactions, intended for heavy agentic sessions or multi-project use. hooks don't count against any tier's quota.

honest take

the spec-driven workflow is a genuine architectural choice, not just a UX layer on top of code generation. whether it's better than Cursor or Copilot depends on your use case: for greenfield features and large structured changes on an existing codebase, the requirements → design → code pipeline has real value. for fast iteration on small fixes or exploratory prototyping, the upfront spec phase is overhead you may not want. the honest answer is that both workflows are useful and Kiro is optimizing for a different position on that tradeoff than its competitors.

the retirement of Amazon Q Developer also signals how Amazon is consolidating its developer-tools strategy. if you're in an AWS-heavy shop, Kiro is the path forward — Q is not being updated.