Guide · Specification-driven development
What SDD is, how it runs, and why it is back in conversation
New here? This is a plain-language map for first arrivals. We separate the stable idea from the noisy label, walk the workflow in human terms, explain why cheap AI coding changed the economics, and show how PRDs, SRS-style documents, APIs, and other familiar inputs still fit—because SDD names a direction of travel more than a single mandated file format, and practitioners are still writing parts of the playbook together.
- Definition first
- End-to-end shape
- Why timing matters
- PRD & SRS are fine on-ramps
- Knowledge still forming
01 · What the label names
SDD usually means Specification-Driven Development
Across vendors and meetups you will hear slightly different words for the same pressure: keep intent explicit enough that humans and tools can align before code ships. “Specification-Driven Development” is the label many teams use; some still say “design-driven.” The useful question is not the acronym fight but whether your organization treats a structured specification—not chat scroll—as the place where truth is negotiated, versioned, and reviewed.
- Intent before implementation
- Reviewed, versioned surface
- Not a single vendor lock-in
02 · The core claim
The specification leads; code follows or is checked against it
In traditional flow, code quietly becomes the source of truth and documents trail behind. SDD flips the expectation: the specification is the primary artifact—often graph-like, typed, or otherwise machine-friendly—and implementation is generated, refreshed, or at minimum verified against that artifact. Drift still happens; the difference is that drift is supposed to be visible, owned, and repaired upstream instead of discovered late in review.
- Spec holds authority
- Code is downstream
- Drift is managed, not hidden
03 · How it works in practice
A loop your team can recognize even if tools differ
Most mature descriptions share the same spine: structured features, scenarios, data, services, and constraints live in one inspectable place; change requests edit that layer first with impact analysis; traceability ties requirements, tests, and code; generation or synchronization keeps agents and compilers pulling from the same facts. The exact DSL, graph, or document skin varies—that is one reason you see multiple “flavors.”
- Structured intent layer
- Change objects + impact
- Traceability & verification
- Generate or sync code
04 · Why now hits different
When implementation is cheap, ambiguity becomes expensive
Before LLMs went mainstream, rigorous specification lived mostly in safety-critical pockets because the friction was worth it only when failure cost dwarfed tooling pain. Agentic coding changed the ratio: models and IDEs can emit enormous amounts of code quickly, so the bottleneck moved to “what exactly should exist?” A fuzzy PRD or orphan SRS paragraph scaled to a fuzzy pull request instantly. SDD is resurging because it is the discipline that keeps leverage without surrendering the merge bar.
- Volume moved upstream
- Agents read what you write
- Same review bar, new speed
05 · Inputs and flavors
PRDs, SRS markdown, OpenAPI, Gherkin—many on-ramps, one habit
Teams rarely start from a green-field graph on day one. Product may own a PRD; engineering may keep OpenAPI or ADRs; quality may author Gherkin; Gluecharm-style stacks often center structured SRS chapters. SDD-compatible practice says: pick surfaces your roles can sustain, then harden them until agents and reviewers can trust the same text. The flavor changes; the habit is “edit intent where it is authoritative, then propagate.”
- Start from existing docs
- Converge authority gradually
- Teach agents the same surface
06 · Neighbors, not enemies
TDD, BDD, DDD, vibe coding—different sources of truth
Behavior-driven tests, domain models, and chat transcripts each capture value; they simply answer different precision questions. SDD insists on a structured specification layer precise enough to drive or verify behavior at scale—closer to executable-adjacent intent than a slide deck. The appendix table below spells out who owns truth in each style so you can explain trade-offs to leadership without sounding tribal.
- Different precision bars
- Complement where honest
- See table for contrasts
07 · Honest frontier
The canon is still being written—adopt with curiosity, not dogma
Conferences, open-source experiments, and product teams are converging on shared pains faster than on shared nouns. That is healthy: it means you can pilot SDD-shaped habits—tighter change control, explicit specs for agent runs, traceable diffs—without pretending the industry finished arguing. Capture what worked for your stack, keep revision history, and revisit quarterly as models change.
- Pilot before rebranding
- Prefer evidence over slogans
- Revisit as models shift
08 · How EasySpecs frames it
Structured intent that stays humane for stakeholders
Gluecharm and easyspecs.ai exist to keep structured specifications legible across roles while agents absorb implementation churn. The goal is not more paperwork; it is fewer “wait, which doc is real?” moments when shipping pressure spikes. Training translates that posture into repo-native rituals your whole team can run.
- Stakeholder-readable structure
- Repo-native habits
- Training grounds the loop
Technical appendix
Next: side-by-side contrasts (TDD, BDD, vibe coding, formal methods), a fuller workflow checklist, and attributed public quotes that explain why agentic teams now care about durable written intent.
Ready to make the habit real inside your org?
Read the appendix for rigor, then talk with us about agentic team training—shared prompts, verification, and specs everyone can tend without heroics.
Reference · SDD
Specification-Driven Development (SDD)
SDD usually means Specification-Driven Development. Some people say “design-driven”; the label most teams use is Specification-Driven Development.
SDD is a methodology where the specification is the primary artifact of the software process — not the code. Code is derived, regenerated, or validated against a rigorously maintained spec. That is the thesis behind Gluecharm and easyspecs.ai: structured intent stays in charge while agents handle implementation volume.
- Intent leads
- Code follows structure
- Agents absorb volume
Core idea
Traditional development
- Requirements flow into code through a lossy translation.
- Code becomes the source of truth.
- Specs rot, drift, or never existed in an executable or machine-readable form.
Specification-Driven Development
- The specification is the source of truth — structured, versioned, machine-readable.
- Code is derived, regenerated, or checked against the spec.
- Changes start at the spec layer first, then propagate to implementation.
Executable shape
The spec is expected to be precise enough to run or verify — not a vague Word document, but a structured artifact (often a graph, DSL, or typed schema) covering features, scenarios, data models, services, and constraints.
Why it is resurging now
Before LLMs, SDD lived mostly in formal-methods circles (TLA+, Alloy, B-Method, Event-B): rigorous but high-friction, so it stayed in aerospace, finance, and protocol design. With agentic coding, the economics flipped. Implementation is increasingly cheap — models and IDEs can generate thousands of lines on demand — so the bottleneck moved upstream to “what exactly do we want built?” A fuzzy prompt produces fuzzy code at massive scale. A precise specification produces consistent, regeneratable code. That is the Agentic Conf Hamburg thesis: the missing layer between intent and merges.
Typical components of an SDD workflow
- Structured spec artifacts — features, use cases, scenarios, views, services, data entities, and non-functional requirements (for example a five-scope impact analysis).
- Change requests as first-class objects — spec edits are tracked, reviewed, and impact-analyzed (including CR “animal sizing” from mouse-sized to dinosaur-sized change).
- Bidirectional traceability — lines of code map to requirements; requirements map to tests and implementation.
- Impact analysis — given a change request, know which features, services, entities, and views move before anyone edits code.
- Generation and synchronization — agents produce or update code from the spec; discovery flows can rebuild or align the spec from existing code (for example OpenCode discovery).
How SDD differs from neighbors
Same industry, different source of truth and precision bar.
| Approach | Source of truth | Precision |
|---|---|---|
| Vibe coding | Chat history | None |
| TDD | Tests | Behavioral only |
| BDD | Gherkin scenarios | Behavioral, human-readable |
| DDD | Domain model | Conceptual |
| Model-Driven Engineering | UML / metamodels | High but heavy |
| SDD | Structured specification | High, executable-adjacent |
| Formal methods | Mathematical spec | Provable |
Reference · Field notes
Why we cite Andrej Karpathy
His public arc tracks how the field matured: natural language as the interface, then “vibe coding” for throwaways, then professional agentic engineering with oversight — and lately the “compile, don’t just retrieve” pattern behind durable specs. Below are attributed lines from that thread (plus one community synthesis of his LLM Wiki framing). The practice is what we install with your team:
- Interface → habit
- Oversight returns
- Durable surfaces
Jan 2023 — English as the interface
The hottest new programming language is English.
Andrej Karpathy, X (Jan 24, 2023)
Feb 2025 — vibe coding
There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
Andrej Karpathy, X (Feb 2, 2025)
June 2025 — YC AI Startup School
Suddenly, everyone is a programmer because everyone speaks natural language like English. This is extremely bullish and very interesting to me and also completely unprecedented.
Andrej Karpathy, quoted in coverage of his YC AI Startup School keynote (e.g. mlnotes.substack.com)
Feb 2026 — agentic engineering
Today (1 year later), programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny. The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software.
Andrej Karpathy, one-year retrospective on X (Feb 2, 2026)
Feb 2026 — why the new name
Many people have tried to come up with a better name for this to differentiate it from vibe coding, personally my current favorite 'agentic engineering': 'agentic' because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. 'engineering' to emphasize that there is an art & science and expertise to it.
Andrej Karpathy, same retrospective on X (Feb 2, 2026)
LLM Wiki pattern — compilation
The correct way to use LLMs is not Q&A, it's compilation.
Summarized baseline of Karpathy’s LLM Wiki gist (github.com/karpathy/442a6bf555914893e9891c11519de94f); phrasing from community writeups of the pattern
Positioning note (community synthesis)
Ideas outrank Code — Your wiki of decisions and formulas is worth more than the code it generates.
Community principle derived from Karpathy’s LLM Wiki paradigm (github.com/Ss1024sS/LLM-wiki); swap “wiki” for “SRS” and you have the EasySpecs thesis
Training turns that arc into repo habits: orchestration with human oversight, quality gates that do not move, and versioned specs the team treats as the compiled surface agents read — not disposable chat.