DEV Community: planu-dev.ai

SDD is BDD/TDD for the AI Era — A Guide for Software Crafters

planu-dev.ai — Wed, 25 Mar 2026 19:36:32 +0000

SDD is BDD/TDD for the AI Era — A Guide for Software Crafters

The Software Crafters community has been arguing for engineering discipline since long before AI coding tools existed. Clean code. Continuous refactoring. Test-first. The boy scout rule.

Those values do not become less important when an AI is writing the code. They become more important.

The Core Analogy

You already know this principle: write the test first, then the code.

TDD forces you to articulate what correct behavior looks like before you implement anything. The test is a specification. The red-green-refactor loop is a verification cycle.

SDD applies the same principle to AI-assisted development:

Write the spec first. Then let the AI write the code.

Same discipline. Same intent. Adapted for the reality that the "developer" is now an AI agent.

Why This Audience Gets It Immediately

Software Crafters are already convinced that:

Engineering discipline matters
"Move fast and break things" accumulates debt
Verification is not optional — it is part of the definition of done
Shared understanding between team members prevents bugs

Planu does not need to convince you of any of this. It just shows you how to apply these principles to AI development.

The Parallel Is Exact

Software Crafters Concept	SDD Equivalent
User Story + Acceptance Criteria	Spec + Acceptance Criteria
Test First	Spec First
Definition of Done	DoD gate in Planu
Code Review	`validate` tool (automated drift detection)
Refactoring safely	Spec + validate = safe AI-driven refactors
Pair programming	Human + AI with shared spec

The workflow is familiar. The tooling is new. The discipline is identical.

What Makes AI Development Different

There is one important difference from traditional TDD: the AI has no memory of your decisions.

When you pair program with a human colleague, they remember the discussion you had last week about error handling patterns. They remember why you chose that architecture. They can say "wait, that contradicts what we decided in the auth layer."

An AI agent starts fresh every session. Without a spec, it makes decisions that may contradict previous sessions. Over time, the codebase becomes inconsistent — not because the AI is bad at writing code, but because it lacks the context that a human colleague would carry naturally.

The spec is that persistent context. It is the shared understanding that survives session boundaries.

Drift Detection: The AI-Era Code Review

One of Planu's most useful features for Software Crafters is drift detection.

After you have an approved spec and an implementation, running validate checks whether the implementation still matches the spec. This is like a continuous code review that runs against an explicit contract, not just style conventions.

When the AI refactors something and accidentally breaks a behavior the spec defines, validate catches it. When a feature drifts because someone added "just one small thing" without updating the spec, validate catches it.

This is the "refactoring safely" pattern applied to AI development.

Collaboration Ideas for the Community

Conference Talk: "From Vibe Coding to Spec Driven Development"

A live demo comparing the two approaches. Format: 45-60 minutes with a hands-on section. This works well for any conference where developers are adopting AI tools and wondering how to maintain quality.

Blog Series: XP Meets AI

"What XP Practitioners Need to Know About AI Development"
"How to Apply TDD Discipline to AI-Assisted Development"
"Why Your AI Code Reviews Are Failing (And How to Fix Them)"

Podcast Topics

"The AI Quality Problem No One Is Talking About"
Compare to early TDD adoption: same resistance, same eventual acceptance
The parallels between TDD's critics in 2003 and SDD's critics in 2026

What Makes Planu Right for This Community

No cloud required — data stays local, no privacy concerns
Language agnostic — works with Python, Go, Java, Ruby, .NET, not just JavaScript
Tool agnostic — Claude Code, Cursor, Windsurf, Zed, Cline, Continue
Open standard — built on MCP, the open protocol for AI plugins
Engineering discipline built in — the workflow enforces spec-first, not optional

The last point matters. Planu is not a suggestion. The workflow requires a spec before implementation. You cannot skip it without explicitly overriding it. That is a deliberate design choice — the same reason TDD frameworks make it easy to write tests first, not just possible.

One-Line Pitch

"Planu is what happens when Software Crafters discipline meets AI development."

Planu — Spec Driven Development for AI coding agents. Get started

Live Demo: SDD vs Vibe Coding in 10 Minutes

planu-dev.ai — Wed, 25 Mar 2026 19:35:52 +0000

Live Demo: SDD vs Vibe Coding in 10 Minutes

This is the demo that makes the difference tangible. Two approaches, same feature, same AI. The contrast speaks for itself.

Use this for conference talks, team workshops, or to convince a skeptical colleague that the spec-first approach is worth the two minutes it takes.

Setup (before the demo)

Have a project with Planu installed in Claude Code
Have a simple feature idea ready: "add dark mode toggle"
Ideally have two terminal windows side by side

Part 1: The Vibe Coding Approach (3 min)

Say: "This is how most people use AI coding tools today."

Open Claude Code in a project without Planu
Type: "Add a dark mode toggle to the settings page"
Watch Claude write code
Ask the audience: "How do you know this is correct? How do you know it is done?"
Point out: There is no checklist. No verification. No way to track that the right thing was built.

Say: "This works for prototypes. For production features, you need something better."

The issue is not that Claude wrote bad code. The issue is that you have no way to know whether it wrote the right code without reading every line yourself.

Part 2: The SDD Approach (5 min)

Say: "This is Spec Driven Development with Planu."

Open Claude Code with Planu connected
Type: "I want to add a dark mode toggle to the settings page"
Planu creates a spec — show the acceptance criteria on screen
Say: "Notice these acceptance criteria. The AI now knows exactly what 'done' means."
Say to Claude: "Approve this spec" — show Planu moving to 'approved' status
Claude implements the feature against the spec
Run: validate SPEC-XXX
Say: "This tells us whether the implementation matches the spec. Not vibes — verification."

The key moment: When you show validate passing, the audience sees that "done" is a binary state, not a feeling.

Part 3: Why This Matters (2 min)

Key points to land:

"When something breaks in production, you look at the spec — not trawl through chat logs"
"When a new developer joins, the spec documents what was built and why"
"When you have 50 features in flight, Planu tracks all of them — not just the one you are looking at right now"

Close with:

"Planu does not slow you down. It makes your AI more reliable. That is the difference between vibe coding and spec driven development."

Q&A Preparation

"Isn't this just extra documentation overhead?"

The spec is the contract, not the docs. It takes 2 minutes to approve and saves hours of re-implementation when the AI builds the wrong thing. You would rather find out the spec was wrong before implementation than after.

"What if I am prototyping?"

For throwaway prototypes, skip the spec. Planu does not force anything — it is there when you need production quality. The workflow scales down gracefully.

"Does this work with Cursor, Windsurf, or other tools?"

Yes. Planu works with any MCP-compatible AI tool: Claude Code, Cursor, Windsurf, Zed, Cline, Continue, and more. One installation, all your tools.

"How long does writing a spec actually take?"

About 2 minutes for a typical feature. Planu generates the initial spec from your description — you review and approve it. The overhead is genuinely small compared to the verification it provides.

Adapting This Demo

For a 5-minute slot: Do only Part 2. Skip the Vibe Coding comparison and just show the SDD workflow working. The validate output is the most impressive part.

For a 30-minute workshop: Add a hands-on section where attendees install Planu and run through the workflow themselves. The npx @planu/cli install command gets them started in 30 seconds.

For a skeptical audience: Lead with the question "How do you currently verify that AI-generated code is correct?" Most people do not have a good answer. That question frames the entire demo.

Planu — Spec Driven Development for AI coding agents. Get started

SDD vs Vibe Coding: Why Specs Make AI Development Scale

planu-dev.ai — Wed, 25 Mar 2026 19:35:47 +0000

SDD vs Vibe Coding: Why Specs Make AI Development Scale

"Vibe Coding" — describing features informally to AI — creates technical debt at scale. The bottleneck has shifted from writing code to validating whether AI-generated code is correct.

AI tools are getting better at writing code every month. The remaining problem: verifying that what they write matches what you actually want.

The Core Difference

Without SDD:    idea → describe in chat → AI writes code → (hope it's right)
With SDD:       idea → spec → approve → AI implements → validate → done

The difference is not about AI capability. It is about the clarity of the contract between you and your AI agent.

What Vibe Coding Gets Right

Vibe Coding is genuinely good for some things:

Rapid prototyping — exploring an idea quickly, before committing to a design
Small, isolated tasks — "add a console.log here" or "fix this typo"
Learning — understanding a codebase or technique without production stakes

For these cases, informal descriptions work fine. The AI is smart enough to fill the gaps.

Where Vibe Coding Breaks Down

At production scale, informal descriptions create compounding problems:

1. No shared understanding. The spec lives in someone's head or scattered across chat logs. When the original developer leaves, the intent is lost.

2. No verification. How do you know it is done? You re-describe and hope the AI implemented what you meant, not what you said.

3. No traceability. When something breaks, which chat message caused it? Which session changed the behavior?

4. Drift. The AI's implementation diverges from the original intent over time, and no one notices until something breaks in production.

How SDD Solves All Four

Planu's Spec Driven Development workflow addresses each problem directly:

Problem	SDD Solution
No shared understanding	Spec is a written contract, approved by both developer and AI
No verification	`validate` tool checks implementation against the spec
No traceability	Every change is linked to a spec ID
Drift	Drift detection compares current code against the approved spec

The Competitive Landscape

Approach	Has Spec	Has Validation	Has Traceability
Vibe Coding	No	No	No
Kiro (AWS)	Yes	Partial	Partial
Planu	Yes	Yes	Yes

Kiro targets AWS and enterprise teams. Planu is language-agnostic, tool-agnostic, and works entirely locally — no cloud required.

Planu is Not Anti-AI

This is worth being explicit about: Planu does not slow down AI development. It makes AI development reliable.

The spec takes two minutes to write and approve. The validation step takes seconds. What you get in return is confidence — the kind that lets you ship AI-generated code to production without a manual code review.

"You have already accepted that AI can write code. Planu ensures it writes the right code — by giving your AI a precise blueprint to follow instead of a vague chat description."

Getting Started

If you are already using Claude Code, Cursor, Windsurf, or any MCP-compatible AI tool, adding Planu takes one command:

npx @planu/cli install

Then describe a feature to your AI. Instead of writing code immediately, it will create a spec first. You approve it. It implements. You validate. Done.

That is the entire workflow. No configuration, no overhead, no new tools to learn.

Planu — Spec Driven Development for AI coding agents. Get started

SDD vs TDD: Why Spec Driven Development Changes the Game for AI-Assisted Coding

planu-dev.ai — Wed, 04 Mar 2026 16:51:26 +0000

SDD vs TDD: Why Spec Driven Development Changes the Game for AI-Assisted Coding

Most developers are familiar with TDD — Test Driven Development. Write a failing test, make it pass, refactor. It's been a cornerstone of software craft for over two decades. But as AI coding agents enter the picture, a different kind of discipline is emerging: Spec Driven Development (SDD).

This article breaks down what each approach does, where they differ, and why SDD has become essential for teams working with AI tools like Claude, Cursor, or Windsurf.

What is TDD?

Test Driven Development is a micro-cycle practice. The loop is tight:

Write a failing test that describes desired behavior
Write the minimum code to make the test pass
Refactor without breaking the test

TDD operates at the code level. Its primary job is to keep the implementation honest: the test expresses what a function or module should do, and the code must satisfy that contract.

The benefits are real. TDD forces you to think about interfaces before implementation. It catches regressions early. It creates a living documentation of expected behavior. Teams that practice TDD consistently ship more maintainable code.

The limitation is equally real: TDD doesn't tell you what to build. You still need to decide what the feature is, what it accepts, what it returns, how it handles edge cases, and how it interacts with other parts of the system. TDD assumes you've already made those decisions.

What is SDD?

Spec Driven Development is a pre-implementation discipline. Before any code is written — and before any AI agent writes a single line — you create a specification that defines:

What the feature does (user story, acceptance criteria)
How it fits into the architecture (affected files, new types, dependencies)
What risks exist (edge cases, performance concerns, rollback complexity)
How success is measured (concrete, verifiable criteria)

SDD operates at the feature level. It produces documents — typically a User Story file and a Technical Sheet — that serve as contracts between the developer (or agent) and the intended outcome.

The cycle looks like this:

Write the spec (spec.md + technical.md)
Get explicit approval from the team or product owner
Implement against the spec
Validate with automated quality gates
Merge only when all criteria pass

The Key Differences

Dimension	TDD	SDD
Scope	Function / module	Feature / spec
Timing	Before writing the function	Before writing any code
Artifact	Test file	Spec document + acceptance criteria
Primary concern	"Does this code do what I wrote?"	"Are we building the right thing?"
Works well for	Implementation correctness	Feature scope, AI agent direction
Fails without	Clear requirements	Approval gate before coding

These are complementary, not competing. TDD answers "is this implementation correct?" — SDD answers "is this the implementation we agreed to build?"

Why AI Coding Agents Break Without Specs

Here's the real-world problem: AI agents are highly capable at generating code, and nearly incapable of maintaining long-term coherence without structured context.

When you ask Claude or Copilot to "add a user settings page," you get code. But:

It may contradict a decision made two sprints ago
It may introduce a new database schema when you already had one for the same data
It may handle error cases differently from your existing patterns
In a parallel session, another agent may be building the same feature from a different angle

Without a spec, every AI session is a fresh start. The agent has no contract to honor, no acceptance criteria to satisfy, and no way to know when it's done. The result is feature sprawl, inconsistency, and the kind of technical debt that's hard to name but easy to feel.

With a spec, the agent has:

Explicit acceptance criteria it must satisfy
The architecture constraints it must respect
A definition of done that both you and the agent can verify

When to Use Each

Use TDD when:

You're implementing a well-defined module with clear inputs and outputs
You're fixing a bug and want to prevent regression
You're refactoring and need a safety net

Use SDD when:

You're starting a new feature, even a small one
You're working with AI coding agents (always)
Multiple people or agents may work on the same area
The feature touches more than one file or layer
You want an explicit approval gate before any code is written

Use both when: you're building software seriously. SDD tells everyone what's being built. TDD verifies it was built correctly.

How Planu Helps

Planu is an MCP server that brings SDD discipline directly into your AI coding workflow. When you install Planu, your AI agent gains access to tools that:

Create structured spec documents (create_spec) with User Stories and Technical Sheets
Enforce an approval gate before any implementation begins
Track implementation status against acceptance criteria
Validate the spec is complete before marking it done

The workflow with Planu looks like this:

User: "Add OAuth login support"
Agent: [uses create_spec] → generates spec.md + technical.md
User: reviews and approves the spec
Agent: [implements against the spec, tracks progress]
Agent: [uses validate_spec] → all criteria checked
Merge when gates pass

The agent doesn't guess at scope. It has a contract.

Getting Started

SDD doesn't require Planu — you can practice it with any structured document format. But if you want the discipline enforced automatically within your AI coding sessions, Planu integrates directly with Claude, Cursor, Windsurf, and any MCP-compatible agent.

Read the Getting Started guide to set up Planu in under five minutes.

The spec is the contract. TDD verifies the code. Together, they close the loop.