DeepLearning.AI und JetBrains haben einen guten Kurs zu Spec-Driven Development. Paul Everitt hält ihn. Du schreibst erst eine Constitution, dann eine Spec, dann Code. Worum es geht, ist die Disziplin — und die ist übertragbar.
Nicht übertragbar ist das Substrat. Der Kurs setzt auf Markdown. Für ein Tutorial reicht das. Aber sobald Markdown in einem echten Projekt landet — Agents, die Änderungen über Anforderungen, Specs, Code, Tests und Varianten hinweg propagieren —, rennt man gegen dieselbe Wand, über die ich in Die 6×-Steuer geschrieben habe. Reiner Text sagt dir nicht, was mit was zusammenhängt. Deine Agents laden bei jedem Schritt das ganze Projekt neu, übersehen Artefakte, von denen ihnen niemand erzählt hat, und verbrennen dabei Tokens, das auch noch zu beweisen.
Also habe ich den Kurs neu gebaut. Er liegt unter patdhlk/spec-driven-development.
Dieselbe Disziplin, anderes Substrat
Zwölf Lektionen. Derselbe Bogen wie bei Everitt: Constitution, Feature, Implementierung, Validierung, der Rest. Die Unterschiede liegen an den entscheidenden Stellen.
Specs sind sphinx-needs, kein Markdown. Jede Anforderung, jede Spec, jeder Test, jede Entscheidung und jedes Risiko bekommt eine typisierte ID und typisierte Links. req wird von spec spezifiziert, spec von impl implementiert, impl von test verifiziert. Entscheidungen schränken ein, Risiken werden eingedämmt. schemas.json erzwingt den Graph — fehlerhafte Specs fliegen raus, bevor sie Code erreichen.
Die Anwendung ist Rust + Actix-web, nicht TypeScript + Hono. Vertrautes Terrain für die Automotive- und Embedded-Leute, mit denen ich arbeite. SQLite über rusqlite, Askama für HTML-Templates mit Compile-Zeit-Prüfung, PicoCSS fürs Styling, kein Build-Schritt.
Das Capstone nutzt Pharaoh. Sobald deine Specs ein Graph sind, kannst du den Graph fragen. Pharaoh ist der AI-Assistent, der die Fragen stellt — Impact-Analyse, Lückenanalyse, Traceability-Traversierung, alles über Skill-Markdown statt über ein Runtime-Binary. Genau dafür habe ich Pharaoh gebaut.
Die Domäne ist AgentClinic. AI-Agents sind die Patienten. Ailments — die Krankheitsbilder — sind Degradationsmodi: Hallucination, Context Rot, Persona Collapse. Treatments sind die Verschreibungen: Context Infusion, Prompt Recalibration. Ein Besuch läuft Triage → Diagnose → Verschreibung → Nachsorge. Eine echte CRUD-App mit einer Domäne, die albern genug ist, dass du die Lektion auch um 23 Uhr noch durcharbeitest.
Eigenständige Lektionen
Jedes Lesson_NN/-Verzeichnis ist ein vollständiger Projekt-Snapshot. Ordner kopieren, loslegen. Du brauchst Lesson_03 nicht, um Lesson_07 zu machen. Wenn du sehen willst, wie needtable-Traceability-Matrizen in der Praxis aussehen, spring auf Lesson_05. Wenn du Specs aus bestehendem Code rückentwickeln willst, ist Lesson_09 ein Projekt mit Code und ohne Doku.
cp -r Lesson_02/ my-agentclinic/
cd my-agentclinic
cargo run
Mehr nicht. Kein Setup-Wizard. Keine Lesson_00.5-Voraussetzungen. Die Lektionen stehen für sich, weil der Code für sich steht.
Was du tatsächlich lernst
Lektion 02 zeigt dir, wie du eine Constitution als decision::- und feature::-Direktiven schreibst, gegen ein Schema validiert. Lektion 03 führt req, spec und test mit Traceability-Links ein. Lektion 04 bringt impl::, und das Schema beginnt, impl→spec-Links zu erzwingen. In Lektion 05 zahlt sich der Aufwand aus — du erzeugst eine needtable-Traceability-Matrix, und der Graph zeigt dir, was noch nicht abgedeckt ist.
In Lektion 11 lässt du Pharaoh-Skills auf den Korpus los. pharaoh:change zählt den Impact einer einzelnen Anforderungsänderung auf, bevor auch nur ein einziges LLM-Token ausgegeben ist. pharaoh:mece findet Waisen, lose Links, Lücken. pharaoh:trace läuft den Graph in jede Richtung ab. Derselbe Agent, anderer Prompt, strukturierter Input.
Der Kurs bringt dir kein Rust bei. Er setzt voraus, dass du es lesen kannst. Er bringt dir auch kein Sphinx bei. Er bringt dir bei, Specs zu schreiben, die eine Maschine traversieren kann — und darum geht es eigentlich.
“Aber ich nutze kein Rust”
Die meisten Teams, die davon profitieren würden, nutzen kein Rust. Auch gut. Die Disziplin ist portabel. Es geht ums Substrat.
Wenn du eh schon mit GitHubs spec-kit arbeitest, gibt es einen offenen PR — useblocks/spec-kit#1 — der einen optionalen format = "rst"-Schalter ergänzt. Dieselben spec-kit-Slash-Commands, derselbe Workflow, aber heraus kommen sphinx-needs-Direktiven statt Markdown-Listen. spec.rst, plan.rst, tasks.rst und eine automatisch gerenderte coverage.rst mit needtable-Filtern und einem needflow-Diagramm. sphinx-build -W wird zum Konsistenz-Orakel. Du bekommst den typisierten Graph, ohne spec-kit zu verlassen.
Das Konzept stammt von mir, den Großteil der Arbeit hat Bartosz Burda gemacht. Dieselbe Idee wie im Kurs, nur auf ein Tool angewendet, das viele Leute ohnehin schon nutzen.
Wozu der Aufwand
Weil Spec-Driven Development die richtige Idee ist und Markdown das falsche Substrat. Du kannst die Disziplin auf Markdown üben und ein kleines Projekt ausliefern. Auditieren lässt sie sich damit nicht. Abfragen auch nicht. Und sie an vier parallele Agents zu übergeben mit der Erwartung, dass am Ende etwas Konsistentes herauskommt — erst recht nicht.
Der Kurs ist der kürzeste Weg, den ich kenne, um Specs zu schreiben, die skalieren. Such dir eine Lektion aus. Ordner kopieren. Loslegen.
Referenzierte Repos: patdhlk/spec-driven-development (der Kurs), useblocks/pharaoh (das AI-Assistent-Framework, das im Capstone genutzt wird), useblocks/spec-kit#1 (RST-Modus für spec-kit).
