Using Spec-Driven Development for Production Workflows

How do you get a coding assistant to produce better software, rather than simply produce code faster? Spec-driven development puts reviewable specifications before implementation. Requirements and design documents, written in Markdown, give the assistant an explicit description of what to build before it starts changing code. The intended benefit is both speed and quality; the workflow itself is the subject here, rather than a measured comparison of those outcomes.

The difficulty is familiar to anyone who has managed an eager intern. Early in Erik Hanchett’s career, a VP would walk around suggesting ideas, and Hanchett would drop his assigned work to pursue them. His manager taught him a different sequence: record the request, put it into the schedule, and discuss it before acting. Coding assistants can show the same eagerness. A plausible new request becomes an implementation unless someone supplies the priorities and checkpoints that should come first.

Hanchett introduces himself as a senior developer advocate at AWS with more than 15 years of software development experience. His recommendation is to make that intervening process explicit for the agent: capture what is wanted, inspect the proposed approach, and only then authorize implementation.

Better frontier models do not remove the need to describe a changing project. Requirements, software conventions, and architectural choices keep moving; the model needs the current version of that context. Thinking and planning modes in agent harnesses can delay the jump into code, but Hanchett favors an additional checkpoint: actual documents that a developer can inspect and revise before implementation begins. He presents these recommendations as working judgments, not settled rules for every project.

More context is not automatically better. Files such as AGENTS.md and CLAUDE.md, or steering documents in Kiro, should contain enough rules to orient the assistant without burying the task in instructions. Keep persistent project guidance focused, and bring specialized instructions into the workflow when they become relevant.

Skills provide that on-demand guidance. Hanchett describes them as instruction files activated by task cues or a slash command. More precisely, current Kiro Agent Skills documentation describes automatic activation through matching the request to a skill’s description, rather than a guaranteed literal keyword trigger. Skills can help while the assistant writes the design document and again while it implements individual tasks.

The developer remains responsible for both the plan and the code. Review requirements and design documents interactively, then review the generated implementation. That does not mean reviewing alone: other developers, coding assistants, and pull-request review tools can all help. Their assistance does not transfer responsibility for the result to the agent.

Kiro grew out of a pattern AWS teams saw among customers who were dissatisfied with their coding assistants’ output. Those customers were already asking agents to produce full requirements and design documents. Kiro turned that practice into a product workflow, with an IDE and a CLI. Its general-availability announcement is dated November 17, 2025, anchoring Hanchett’s reference to a release late in the preceding year.

The IDE exposes Vibe and Spec modes. Spec mode addresses the need to plan larger features and complex projects with a clearer understanding of the existing application. Hanchett describes increasing interest in the CLI as well. Hanchett reports tens of thousands of launch downloads. He also recalls a preview access gate introduced under heavy demand, users finding ways around it, and the later public availability of the IDE and CLI.

The same process can be performed manually with a coding assistant:

1. Create requirements. Ask the assistant to derive user requirements from the feature request, or supply an existing requirements document as its starting point.
2. Review the requirements. Work through omissions and misunderstandings before moving on.
3. Create and review the design. Ask how the accepted requirements will be implemented, then inspect that proposal.
4. Generate implementation tasks. Derive the task list from both the requirements and the design, so the work has a traceable basis.

GitHub Spec Kit is another way to organize this staged process across coding assistants. The essential mechanism is the sequence of artifacts and reviews, not a particular editor.

In the recorded Kiro IDE, select Spec and enter a request—for example, a movie MCP server that tracks films you have watched, or a movie website. Hanchett calls the CLI entry point Plan mode and later refers to a quick plan mode. Those are the recording’s labels; current Kiro Specs documentation describes CLI specs and Quick Spec.

A new movie application is an easy example, but specs also fit existing codebases. Hanchett has seen years-old applications containing dozens of spec files. He recommends the approach especially for in-depth features and complex projects that need upfront planning. Kiro also offers a bug-fix spec workflow, although he suggests a more direct vibe-coding interaction may be sufficient for small changes.

The requirements phase produces an introduction, user stories, and requirements in EARS—Easy Approach to Requirements Syntax. Structured requirements make the triggering situation and expected behavior easier to inspect than a broad feature request. Clarifying questions can come before document generation; the quick plan option described in the recording uses those answers to generate the documents together.

The next artifact is a higher-level design, potentially including Mermaid diagrams or ASCII diagrams. The order can vary: start with requirements, start with design, or combine the two documents where that makes sense. Pause here to add project knowledge and implementation preferences. A generated design becomes useful when someone who understands the application edits its assumptions and choices, rather than merely accepting a polished Markdown file.

Before generating implementation tasks, inspect the Markdown for inconsistencies, hallucinations, and errors. The resulting task list can include property-based tests derived from requirements and design: checks of behavior that should hold across different inputs. Hanchett recommends generating and running those tests as part of implementation.

He also asks the assistant to reorganize the beginning of the task list around a working MVP. His usual request is to put the top four tasks first and make them deliver that initial version. The purpose is to see the application working before proceeding through the rest of the plan. The useful constraint is a working slice of the product, not four arbitrary items checked off a list.

Model Context Protocol connects AI applications to external data sources. Hanchett sketches a model-backed tool such as Kiro, an illustrative provider such as OpenAI or Anthropic, and MCP between the application and its sources. The workflow benefit is access to information the team has already written elsewhere.

Command-line tools can cover some of the same ground. Hanchett acknowledges that alternative while describing MCP, including its security work, as still maturing. For specification work, his concrete use case is pulling tickets and larger requirements documents from systems such as Jira or Asana. A product manager’s requirements can then inform the generated spec instead of being manually reconstructed in a new prompt.

The assistant still needs to know where to look. Put a rule in steering documents or AGENTS.md directing the specification workflow to the relevant MCP server, or explicitly request that source in the initial requirements prompt. This makes retrieval part of requirements creation, before the assistant turns incomplete context into a design and task list.

The IDE demonstration opens a prepared movie-database project rather than building a new application during the recording. Its starting request was “Please create me a movie website.” Hanchett deliberately chose the design-first path, then opened the rendered Markdown preview. The design includes architecture and sequence diagrams, and he describes iterating with the assistant to edit that design.

Further down the design document are property tests using fast-check in TypeScript and Node. Hanchett describes property tests running dozens or hundreds of times with different values. That repeated variation is how the tests probe whether a stated property survives more than a few handpicked examples; the recording does not establish the project’s configured run count or a passing test result.

The requirements document follows, again using EARS and user stories. The visible walkthrough reaches movie-data loading and a requirement triggered by application initialization, involving the filter engine. This gives the design and implementation a more specific target than simply making a movie website: startup behavior is expressed as something the application is required to do.

Hanchett then asks the assistant to reorganize the movie-site tasks around an MVP. The revised task list assigns tasks one through four to a browsable movie grid with search, genre filtering, sorting, and an ’80s synthwave theme. He says the requirements were revised around that goal and that he subsequently implemented all the tasks. The displayed list explains the intended first working version; his account supplies the implementation outcome.

The IDE also exposes property-test execution information and hover descriptions. The final example states a precise invariant: for any movie dataset, the extracted genres must be exactly the sorted set of unique genres. This combines three obligations: preserve every genre present in the input, remove duplicates, and return the result in sorted order.

For a concrete illustration, take two movie records with genres ['Drama', 'Comedy'] and ['Drama', 'Action']. Extraction should produce ['Action', 'Comedy', 'Drama'] without changing either record. The following TypeScript expresses the operation and tests the same invariant across generated datasets:

import assert from 'node:assert/strict';
import fc from 'fast-check';

type Movie = { genres: string[] };

function extractGenres(movies: Movie[]): string[] {
  return [...new Set(movies.flatMap(movie => movie.genres))].sort();
}

const movies: Movie[] = [
  { genres: ['Drama', 'Comedy'] },
  { genres: ['Drama', 'Action'] },
];

assert.deepEqual(extractGenres(movies), ['Action', 'Comedy', 'Drama']);

const movieArbitrary = fc.record({
  genres: fc.array(fc.string()),
});

fc.assert(
  fc.property(fc.array(movieArbitrary), dataset => {
    const before = structuredClone(dataset);
    const result = extractGenres(dataset);
    const inputGenres = dataset.flatMap(movie => movie.genres);

    assert.deepEqual(new Set(result), new Set(inputGenres));
    assert.equal(result.length, new Set(result).size);
    assert.deepEqual(result, [...result].sort());
    assert.deepEqual(dataset, before);
  }),
);

The set comparison checks membership, the length check rules out duplicates, and the sorted-copy comparison checks ordering. Input preservation is an additional check in this illustration. The movie example ends with a specification that can be challenged by tests: an exact relationship between input records and output genres, rather than an impression that filtering looks right.