Spec-Driven Development with Agentic AI - Can You Specify Your Way to Working Software?

  This page is still in draft state. Please note that the content may be subject to change.

Spec-driven development promises a new workflow: write a complete, structured specification, with functional and non-functional requirements, acceptance criteria, architectural and constraints. Then let an agentic AI implement it autonomously “over night”. This topic puts that optimistic vision to the test.

• Background
• Objective(s)
• Possible Research Question(s)
• Sources (Example)

Background

The latest trend in agentic AI-assisted development is called spec-driven development (SDD). The idea is to move the developer’s primary work from writing code to writing specifications - structured documents that describe what the software should do, how it should behave, what constraints it must satisfy, and what quality attributes it must exhibit. Once the spec is complete, an agentic AI takes over and implements the software, ideally with minimal human intervention.

The vision is seductive: you invest your intellectual effort into getting the requirements right — functional behavior, edge cases, error handling, security constraints, performance targets, API contracts — and then let the AI do the “mechanical” translation into working code. In the most optimistic version, you push a specification on Friday evening, and by Monday morning, your software is ready for review.

A growing ecosystem of tools supports this workflow. GitHub’s Spec Kit (84k+ stars) provides an open-source toolkit for spec-driven workflows. AWS launched Kiro, an entire IDE built around a Specify-Plan-Execute workflow. Tessl offers spec-driven development as a service. And tools like Claude Code, Devin, and OpenHands can all consume structured specifications and work through them autonomously. Thoughtworks has recognized spec-driven development as one of the key new AI-assisted engineering practices of 2025.

But the approach also faces serious criticism. Critics point out that spec-driven development looks suspiciously like waterfall in Markdown: the assumption that you can fully specify a system before building it is exactly the assumption that the agile movement rejected decades ago. Kent Beck has critiqued SDD for encoding the belief that “you aren’t going to learn anything during implementation that would change the specification.” Other concerns include spec drift (specs and code diverging over time), the overhead of writing detailed specs for small tasks, and the risk that “spec-as-crutch” replaces understanding with documentation.

The counter-argument is that the feedback loop has fundamentally changed: when the AI can implement a spec in minutes rather than months, the cost of getting the spec wrong — and iterating — is much lower than in traditional waterfall. But is that actually true in practice? This topic puts the optimistic vision to the test.

Objective(s)

You research the current state of spec-driven development: what it promises, which tools and frameworks support it, what the claimed benefits are, and what the critics say. Based on your research, you design a coding experiment that tests how far the “spec to working software” pipeline actually gets you.

A proof of concept could look like this, for example: You select a small but non-trivial software project — say, a REST API with authentication, input validation, persistence, and a handful of business rules. You write a complete specification for it: functional requirements, acceptance criteria, API contracts, error handling, non-functional requirements (e.g. response time targets, security constraints), and architectural decisions. You then hand this specification to an agentic AI (e.g. Claude Code, Kiro, or OpenHands) and let it implement the software autonomously, without intervening or correcting along the way. Afterwards, you evaluate the result according to functional and various non-functional dimensions, and compare it to the original spec.

You could also explore what makes a good spec for an AI: What level of detail is needed? Do formal acceptance criteria help? Are architectural constraints followed? Does the AI handle ambiguity gracefully or catastrophically?

Possible Research Question(s)

• How far does an agentic AI get when implementing a small software project from a structured specification alone, without human intervention during implementation?
• Which types of requirements (functional, non-functional, architectural) are reliably translated into working code, and which are systematically missed or misinterpreted?
• What level of specification detail is needed to produce acceptable results — and at what point does writing the spec cost more effort than writing the code?
• How does spec-driven autonomous implementation compare to interactive AI-assisted development in terms of output quality and total effort?
• Is spec-driven development a fundamentally new paradigm, or is it waterfall with faster feedback?

Sources (Example)

1. Thoughtworks (2025): Spec-Driven Development: Unpacking One of 2025’s Key New AI-Assisted Engineering Practices. https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices
2. Martin Fowler / Thoughtworks (2026): Understanding Spec-Driven Development: Kiro, Spec-Kit, and Tessl. https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
3. Alex Cloudstar (2026): Spec-Driven Development 2026: Future of AI Coding or Waterfall? https://www.alexcloudstar.com/blog/spec-driven-development-2026/ <!–
4. GitHub Blog (2025): Spec-Driven Development with AI: Get Started with a New Open Source Toolkit. Introduction to GitHub’s Spec Kit and the spec-driven workflow. https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ –>