AWS re:Invent 2025 - Spec-driven development: Shaping the next generation of AI software (DVT212)

Published: (December 5, 2025 at 06:04 PM EST)
3 min read
Source: Dev.to

Source: Dev.to

Overview

AWS re:Invent 2025 – Spec‑driven development: Shaping the next generation of AI software (DVT212)

In this session Jay Raval and Al Harris from the Kiro team present spec‑driven development, a structured approach to AI coding that generates three key artifacts:

  1. Requirements (using EARS syntax)
  2. Design documents
  3. Implementation tasks

The methodology tackles the “prompt‑and‑pray” loop by planning before coding, enabling reproducible results through property‑based testing that traces back to specific requirements. Live demos show how Kiro implements features such as authentication with MCP servers and Atlassian Jira integration, as well as real examples from the Kiro team (agent notifications, remote MCP support). The approach emphasizes human‑in‑the‑loop collaboration, committing specs to version control, and achieving correctness via formal verification rather than relying solely on LLM decisions.

AWS re:Invent Session Thumbnail

Introduction: The Problem with Prompt‑and‑Pray Development

Good afternoon, everyone. I’m Jay Raval, senior solutions architect on the Kiro team, joined by Al Harris, principal engineer and co‑founder of Kiro.

We’ll explore how spec‑driven development can improve developer productivity end‑to‑end in the software development lifecycle (SDLC) and provide a mental model for working with Kiro’s agent to obtain reproducible, protected results.

Agenda

  • What spec‑driven development is and why specs matter
  • The set of artifacts it generates (requirements, design, implementation)
  • Real‑world case studies from the Kiro engineering team
  • Live demo: using MCP to ship a feature from scratch

Slide – Agenda

The Prompt‑and‑Pray Loop

  • You issue a prompt, the AI generates code, and you get a working prototype.

  • However, moving that prototype to production raises many unanswered questions:

    • What assumptions did the model make?
    • Were the requirements fully defined or fuzzy?
    • Where are the design decisions documented?
    • How can you review and iterate on the implementation?
  • The result is often a cycle of “undo, re‑prompt, rebuild,” which wastes time and introduces risk.

Illustration of Prompt‑and‑Pray Loop

What is Spec‑Driven Development? Requirements as the Foundation

Spec‑driven development is built around three core artifacts and a structured workflow that yields reproducible results:

  1. Requirements – captured using the EARS syntax and often sourced from tools like Jira, Linear, or Asana.
  2. Design – technical implementation decisions, architecture choices, and rationale.
  3. Implementation Tasks – concrete, version‑controlled work items derived from the specs.

Requirements

The entry point for any feature is the product manager’s requirements. By ingesting these into Kiro, the system can validate, enrich, and formalize them before any code is written.

Design

Once requirements are solidified, the design phase determines the tech stack, architectural patterns (greenfield, brownfield, refactor), and detailed implementation steps. The design document records all decisions and their justifications, making them searchable and version‑controlled.

Implementation

From the design, Kiro generates implementation tasks that can be tracked in the same issue‑tracking system. Each task is linked back to its originating requirement and design rationale, enabling traceability and easier debugging.

Spec‑Driven Workflow Overview

The session content is auto‑generated from the original presentation; minor typographical errors may be present.

Back to Blog

Related posts

Read more »