Tutorial – How to use spec-driven development

The latest level of AI driven SDLC is spec-driven development (SDD). Today we’ll build a simple CRM system using SDD and a multi-agent squad to build that in a few steps.

What is spec-driven development (SDD)

Spec-driven development (SDD) is short for Specification Driven Development. In SDD, the developer specifies the problem and the desired outcome to be solved, in a structured, well-documented manor.

• Step 1: Explore. Describe & Clarify requirements. You specify what you want, and AI asks questions if things are unclear.
• Step 2: Propose. Make clear human and AI-readable specifications. Make a plan a for the implementation
• Step 3: Setup quad. Design the right multi-agent team to work on it iteratively
• Step 4: Implement & Test:. The AI will generate all the code, test (automation) and documentations.
• Step 5: Review & manual test. You test the new features manually and review the important code changes.

With the latest AI models like ChatGPT 5.4 and Claude Sonnet 4.6, the quality has increased drastically.

Why SDD? What are the benefits?

The benefit of SDD is that it is superior to ‘occasional prompting’. With SDD, the changes are stored in the code base, the LLM looks at the necessary dependencies, and specific skills.md’s and other .md files make sure the LLM delivers consistent quality.

SDD vs. Vibe coding

Spec‑Driven Development (SDD) emphasizes discipline and control, while vibe coding prioritizes speed and intuition. With vibe coding, you mostly rely on prompting – often using third‑party tools – without a defined process to ensure quality, security, or architectural consistency, and with limited control over structure and safeguards. In contrast, SDD follows a structured, multi‑step process where you explicitly guide the AI on architecture, design patterns, and security measures, resulting in more predictable, maintainable, and secure outcomes. The instructions remain in your source control (.md-files) and improvements are stored in the relevant skills.md to improve future development.

Vibe Coding

• Prompt‑driven, no repeatable process
• No durable source of truth; prompts are lost
• Inconsistent architecture
• Tool‑controlled structure

Spec‑Driven Development

• Specification‑first
• Specs as source of truth, part of source code
• Explicit architecture & constraints, part of source code
• Human‑defined quality and security boundaries

How to start with SDD?

In this example, we use:

• Github CoPilot CLI (the chat window works, but is small. The CLI gives a better, wider and focused interface).
• OpenSpec (@Fission-AI/OpenSpec) to create a solid design and plan changes for both greenfield and brownfield projects. Install it globally (-g).
• Squad (@bradygaster/squad-cli) to facilitate a multi-agent configuration.
• Claude Sonnet 4.6 as the foundational language model, while Squad can utilize simpler and more cost-effective models for specific tasks.

To start the tutorial, use npm (or other package installer) to install all these packages. Get a subscription to Github Copilot or Claude Code.

First step: Explore: Describe & Clarify specifications

In the first step, we start using OpenSpec to explore a new feature. We start with an empty folder, open the command prompt or bash

openspec init

Choose the tool that you use (GItHub CoPilot or Claude Code or …)

Start copilot CLI or start a new chat session in vscode.

With /openspec-explore you can start the SDD process. Use, for example:

/openspec-explore I want to build a multi-tenant CRM system, with a c# backend using mariadb. Use entity-framework-core to render the database. A React TS frontend using Tailwind and shadcn/ui. The CRM is mainly for sales leads, making new contacts/leads, b2b and trace notes, calls, emails and action items. An account is for a single company with many users.

The skill /openspec-explore is started and it comes with several questions, in my case:

You can answer these questions with (for example):

1. Option B.
2. Deals are tracked separately as their own entities. Activities can be both on a deal or on a contact.
3. Action items are simple with a due date, a description and a contact and a user that owns them.

You can simply answer a few questions and the openspec-explore will help you with the questions not yet answered. In the spec, explicitly instruct the agent to enforce tenant isolation at the database and API level.

If you want clarity on how the security is managed, you can ask that by typing:

Explain me more how the security is aranged with JWT

It will tell you in detail how the security is aranged in the different layers (UI/Browser, C# API and MariaDB). Every request has a bearer token that is validated against the JWT and the claims. Pretty solid!

If you want, you can further elaborate on topics like:

• Logging, tracability
• Reporting
• Soft-deletes vs hard-deletes
• …

Step 2: Propose: readable specifcations

The next fase is to propose theste changes. Type:

/openspec-propose

It will create the different documents, using different background agents to work on it simultaniously.

It has created files in:

openspec > changes > multi-tenant-crm:
- design.md
- propsal.md
- tasks.md

You can review these files and give feedback. I made the following change

Use the more general term organization (in stead of company)

Step 3: Setup squad (multi-agent development team)

The next step is to setup the squad, so multi-agents will collaborate on creating the CRM application. Therfore close copilot and start the following cmd/bash/powershell:

squad

In the squad tool, type:

 /init look at openspec/changes/multi-tenant-crm and form a team

Step 4: Implement the proposal

Start copilot again and:

/agent 

And select the squad

And type

i have a pending change in @openspec\changes\multi-tenant-crm\ use the team to implement it

In a matter of 30 minutes (roughly) it has created 312 files and both the frontend as the backend.

In this tutorial, we ran all the changes in one go. Of course, in real-life, you would run it in phases, review the code and make necessary changes – if needed.

Step 5: Review & Test

Review the code, the classes and the implementation choices it made. If needed, prompt for making changes. Also improve the skills.md and different agent-instructions if you want AI to apply these improvements structurally next times. Manually test the new features too.

You often also have to fix minor things, the UI may not be great at first, the some features needs tweaking. But in the end, you get a working solution far quicker than in the old fasioned way.

Conclusion using specification driven development

Spec-driven-development (SDD) gives you the right structure and process to a qualitative and secure solution faster than ever before. It’s far better than just vibe-code new features. SDD is an extension on your current SDLC (Software Development Life Cycle) and the instructions and skills (.md-files) remain in your source control. It gives teammembers a next step in collaborating together.

The current LLMs (like Claude Sonnet and ChatGPT 5.x) ofcourse still have some issues. Developers need to review important parts of the code to double check it’s delivered properly. But you end up having a fully automated tested features. In greenfield, this is often 10x faster. In brownfield solutions it totaly depends on the current architecture and how well-structured the code is.

Executive Summary for CIOs, HoEs and CTOs

Spec‑Driven Development (SDD) offers a structured, enterprise‑ready approach to using AI in the software development lifecycle, moving beyond ad‑hoc “vibe coding.” Instead of relying on isolated prompts and tool‑driven defaults, SDD establishes clear, machine‑readable specifications as a single source of truth. These specifications explicitly define requirements, architecture, patterns, and security constraints before code is generated. As a result, AI becomes a controlled delivery accelerator rather than an unpredictable contributor.

SDD improves governance, risk management, and auditability by making decisions explicit and traceable in specifications rather than implicit in generated code. It enables architectural consistency, higher code quality, and maintainability, even across complex brownfield environments. In short, SDD allows organizations to scale AI‑assisted development with confidence – delivering speed without sacrificing control, security, or long‑term sustainability.