Back to articlesAWS Backs Spec-Driven Dev with Kiro
Thumbnail for ‘From vibe coding to viable code’: AWS dives into spec-driven AI software development with Kiro

Paul Sawers

9 min read28 Jul 2025

Paul Sawers is a freelance writer at Tessl, covering the people, products, and platforms shaping the future of AI-native development. Based in London, Paul brings nearly two decades of experience reporting on startups, enterprise tech, and open source. Before joining Tessl, he was a senior writer at TechCrunch and previously covered the European tech scene for The Next Web and VentureBeat. His reporting blends sharp editorial insight with a deep understanding of the software landscape.

Spec-driven development
Agentic AI
AI-Native Development
Vibe Coding
Developer Best Practices

‘From vibe coding to viable code’: AWS dives into spec-driven AI software development with Kiro

AWS entered the agentic IDE space in a big way last week with the launch of Kiro. At first glance, Kiro seems much like the myriad other AI-native software development platforms out there, such as GitHub Copilot and Cursor, but Amazon’s cloud computing arm is positioning its offering in a fundamentally different way.

First up, Kiro is more than just an AI coding assistant. As a full agentic IDE, its core pitch is that it will orchestrate the whole development workflow through autonomous agents: delegating tasks, not just speeding them up, from prototype through production.

This also sounds a whole lot like Lovable. But Kiro goes beyond the ship-fast “hacky” ethos of vibe coding and into the domain of structured, production-grade software engineering. Indeed, while vibe coding is all about speed and low-friction, it often comes at the cost of long-term reliability in real-world settings.

Kiro addresses this by bringing the “clarity of specs” into the developer workflow.

image1

Spec-driven development

The heart of the Kiro platform lies in specs and hooks. Specs are detailed plans generated from natural-language prompts, breaking down development goals into clear requirements, designs, tasks, and tests.

So for example, a user might issue this prompt: “Create a reusable React component for a modal dialog with title, content, and close button."

Kiro then unpacks this into a structured spec, identifying key requirements – such as handling props, accessibility, and event behavior – and breaks them down into clearly defined tasks, design choices, and tests. It may also generate acceptance criteria to ensure details like keyboard support or edge-case interactions are explicitly handled.

This turns a simple prompt into a reliable blueprint that guides autonomous agents through the building, refactoring, and debugging process.

This spec might look a little something like:

Requirements

Build a reusable React modal dialog component named ModalDialog

Accept props: title (string), children (content), and an onClose callback.

Include a close button that triggers onClose.

Ensure accessibility with proper ARIA roles and keyboard support.

Modal should close when clicking outside the dialog or pressing the ESC key.

Design

Use React functional components and hooks for state and lifecycle management (e.g., open/close logic, keyboard handling).

Modal overlays the entire page with a semi-transparent backdrop.

Center modal content vertically and horizontally in the viewport.

Provide smooth open and close animations for better UX.

Follow the project’s design system standards for typography and spacing.

Implement styling using CSS or styled-components.

Tasks

Create the ModalDialog React component with specified props.

Implement styling for backdrop and modal container.

Add close button and hook up the onClose handler.

Add accessibility attributes and keyboard event handling (ESC key, focus management).

Implement modal close on backdrop click and ESC key press.

Write unit tests covering rendering, user interaction, and accessibility.

image2

With this spec in place, Kiro can then generate designs (e.g. data flow diagrams and TypeScript interfaces), and break down implementation into sequenced tasks with linked requirements, tests, and execution status — all while keeping the specs synced with the evolving codebase.

While specs lay out the blueprint to guide development, hooks ensure those plans are followed consistently throughout the coding process.

Hooks are basically automations that trigger upon specific developer actions — like saving a file or committing code — to handle tasks they’d otherwise do manually. Such automations might include updating related test files when code changes, refreshing documentation after API updates, or running security scans before commits.

🚀 Transform Your Development Workflow with Kiro

From vibe coding to viable code

While Kiro aims to build robust, production-grade software, it attempts to capture vibe coders — users can explicitly choose between starting a “vibe” or a spec-driven session.

image3

That said, Kiro isn’t primarily aimed at casual builders looking to hack something together post-haste. Its core audience is, ultimately, developers who value structure and long-term maintainability over speed alone. And to support this, Kiro makes it easy to transition from vibe to spec sessions by enabling the user to generate a detailed spec based on the context of the initial vibe session.

AWS calls this going from “vibe coding to viable code,” noting in its FAQ:

“Developing with specs keeps the fun of vibe coding, but fixes some of its limitations: vibe coding can require too much guidance on complex tasks or when building on top of large codebases, and it can misinterpret context.”

MCP support as standard

While specs and hooks are the core concepts that differentiate Kiro’s approach – defining what to build and how the AI agents interact with the codebase – Kiro packs other key features that you’d expect from any AI code editor: support for the Model Context Protocol (MCP), which helps developers connect to external tools and data; steering, which are rules set in markdown files that guide a project’s conventions and standards without having to repeat explanations; and chat, which enables ad-hoc conversations with AI agents that understand your code, files, and project context.

Nathan Peck, senior developer advocate for generative AI at AWS, said that Kiro is based on internal processes that Amazon’s own software development teams use “to build very large technical projects.”

To demonstrate Kiro’s capabilities, Peck has also built an infinite crafting game called Spirit of Kiro, with around 95% of the code generated by AI, he said. Open sourced by AWS, the project highlights agent-based development using specs, hooks, and steering. The GitHub repository includes challenges, documentation, and a feature roadmap to help developers explore Kiro in real-world workflows.

Cloud data concerns

Generally speaking, reaction from the community has been positive. However, some expressed reservations about having to use AWS infrastructure, with one noting: “We are 150 people in a SME and most of our projects [under] NDA for gov & defense clients absolutely forbid us to use any cloud based IDE tools like GitHub Copilot etc.

Related to this, another commenter on Hacker News pointed to a section in the Kiro FAQ that addresses the thorny issue of using content to train AI models.

During the preview phase, AWS says that the user’s content – including code snippets, conversations, and file contents that are open in the IDE – “may be used to enhance and improve the quality” of foundation models, though an opt-out is provided in Kiro’s settings. After the preview phase, Kiro will ship with premium Pro and Pro+ tiers, which won’t* use content to train any of the underlying models as default.

For now, Kiro offers the choice between Claude Sonnet 4 and 3.7, though more models will be added soon. It’s worth noting that Kiro desktop IDE is built on the open source VS Code platform, meaning that users can keep their familiar keyboard shortcuts, themes, configuration files, and compatible extensions from the Open VSX ecosystem.

Kiro is currently in public preview, with access available via a waitlist.

Paul Sawers

9 min read28 Jul 2025

Paul Sawers is a freelance writer at Tessl, covering the people, products, and platforms shaping the future of AI-native development. Based in London, Paul brings nearly two decades of experience reporting on startups, enterprise tech, and open source. Before joining Tessl, he was a senior writer at TechCrunch and previously covered the European tech scene for The Next Web and VentureBeat. His reporting blends sharp editorial insight with a deep understanding of the software landscape.

Spec-driven development
Agentic AI
AI-Native Development
Vibe Coding
Developer Best Practices