What Is Spec-Driven Development? — Three Technical Elements, Four Principles, and Seven Processes

in ,

Introduction

A while ago I wrote a piece called “Management-as-Code: A Spec-Driven Architecture for the Organization.” It was an attempt to extend spec-driven development to how a company is run. But in writing it, I realized something.

I had never properly written a single article about spec-driven development itself — the foundation.

In English, “Spec-Driven Development” has become a major current. So this is a good moment to lay out, plainly, what I systematized in my book Spec-Driven Development: A Practical Introduction (Nikkei BP, 2026). Let me set the foundation down here.

In a word

Spec-driven development is a way of building software that treats the specification as the single source of truth.

Not conversations, not email, not scattered documents — you return to the spec. When in doubt, go back to the spec and decide from there. And you manage and operate that spec the same way you manage code (this is commonly called Spec-as-Code).

To make this real, I defined three things: three technical elements, four principles, and seven processes. Let me go through them.

The three technical elements

The technical foundation for handling specifications.

  1. Markdown (to write) — plain text that both humans and AI can read. Unlike Word or Excel, you can hand it straight to an AI.
  2. Git / GitHub (to manage) — keep every change to the spec in history, and share it across the team.
  3. AI / AI editors (to use) — the most important element. AI supports writing the spec, checking its consistency, and generating code.

Write in Markdown, manage with Git/GitHub, use with AI — that is what Spec-as-Code actually is.

The four principles

The mindset to hold while you work.

  • Principle 1: the spec is a “living document.” Don’t write it once and forget it; keep it current (but always keep changes in history — dynamic is not the same as chaotic).
  • Principle 2: the spec is the “single source of truth.” Avoid knowledge silos; everyone returns to the spec.
  • Principle 3: the spec assumes “change and iteration.” Treat change not as an exception but as a given (this does not mean “no planning”).
  • Principle 4: use AI to keep the cost down. Not “hand everything to the AI” — humans decide what to build. The final judgment is human (human-in-the-loop).

The seven processes

The concrete steps for practice.

  1. Constitution
  2. Specify
  3. Plan
  4. Tasks
  5. Implement
  6. Verify / Accept
  7. Migration / Operation

The operation phase (7) is not the end. The lessons learned there flow back to (1) and (2), and the next cycle begins — this is how spec-driven development keeps turning.

Why seven? — the difference from the English-language current

This is what characterizes my methodology.

In its official engineering blog post, “Spec-driven development with AI: Get started with a new open source toolkit,” GitHub laid out four processes (Specify / Plan / Tasks / Implement) — that post is the one that introduced the open-source toolkit, Spec Kit. I took those four as the base and added three processes suited to Japanese organizations, extending them to seven.

The three I added:

  • Constitution — for a culture of consensus. State the project’s purpose and founding principles up front, and have everyone agree.
  • Verify / Accept — for quality assurance. Make continuous verification and final acceptance explicit as a process.
  • Migration / Operation — feed operational learning back into the next spec. Don’t sever development from maintenance.

In short: the English-language current offers four processes for “building fast.” Mine adds three to land spec-driven development in the realities of Japanese development sites — consensus, contracts, and quality. We stand in the same current, but the ground we face is different. That is the difference.

Closing

Spec-driven development binds its three technical elements (foundation), four principles (direction), and seven processes (practice) with a single idea: treat the spec as the single source of truth.

I wrote about this in detail in my book, Spec-Driven Development: A Practical Introduction. And the attempt to carry this thinking all the way into management is my earlier piece, Management-as-Code: A Spec-Driven Architecture for the Organization. I’d be glad if you read them together — the foundation (this article) and the application (the architecture).

Comments and questions are welcome.

References

  • Spec-Driven Development: A Practical Introduction — Nikkei BP (2026-03)
    https://amzn.to/3RWAvmR
  • GitHub official blog, “Spec-driven development with AI: Get started with a new open source toolkit” — the source of the four processes (Specify / Plan / Tasks / Implement); the post that introduced the open-source toolkit, Spec Kit.
  • Management-as-Code: A Spec-Driven Architecture for the Organization (this blog)
    https://hdkworks.com/en/archives/37303