Die meisten Ratschläge zu Spec-driven Development passen für Solo Builder immer noch nicht.
Ständig hörst du, du bräuchtest eine komplette Spec-Pipeline, eine Doktrin, eine Verfassung, Phase Gates und eine kleine Religion rund um Markdown. Genau deshalb nennen viele Builder SDD inzwischen „Wasserfall mit Markdown“. Der Gegenwind ist echt. Simon Willison hat sich deutlich gegen ausufernde Zeremonie gestellt. Birgitta Böckelers Einteilung in spec-first, spec-anchored und spec-as-source hat dem Durcheinander bessere Begriffe gegeben. Addy Osmanis Spec-Format mit sechs Abschnitten hat Specs brauchbarer gemacht, aber auch gezeigt, dass ein Format allein nicht vor Aufblähung schützt. Skepsis im Stil des Thoughtworks Tech Radar ist hier gesund.
Die Kritik bildet sich das nicht ein. Specs können erstarren. Teams können Tokens verbrennen, um Docs zu schreiben, die niemand pflegt. Spec Drift ist real, vor allem sobald mehrere Menschen und Agents an derselben Absicht herumeditieren. Und wenn du voll auf Spec-as-Source setzt, sollte dich Böckelers Warnung vor Koordinationsrisiken nervös machen.
Aber das Anti-SDD-Lager übergeht oft die hässliche Alternative. Ad-hoc-Prompting ist meist schlechter, sobald du Spielzeug-Demos hinter dir lässt. 2025 sahen Teams mit schlanken SDD-Frameworks eine etwa 3- bis 5-mal höhere Erfolgsquote beim ersten Durchlauf von KI-generiertem Code, und die mediane Zeit bis zu einer funktionierenden Implementierung eines nicht trivialen Features sank von 17 bis 20 Entwicklungsstunden auf 5 bis 7 Stunden, so die Übersicht von BCMS zu Spec-driven Development. Wenn du die ausführliche Argumentation willst, wo Specs helfen und wo sie dich ausbremsen, lies diese Analyse der These von der Produktivitätsfalle.
Die Antwort ist also nicht „Lass die Specs weg“. Die Antwort lautet: weniger Framework.
Inhalt
- Der SDD-Backlash ist da – wozu also das Ganze?
- Warum schlanke Frameworks gerade explodieren
- Wie wir diese Frameworks vergleichen
- Schlanke SDD-Frameworks im Überblick
- Feature-Matrix: Frameworks nebeneinander
- So wählst du das richtige SDD-Framework
- Fazit: Hör auf zu debattieren, fang an zu spezifizieren
Der SDD-Backlash ist da – wozu also das Ganze?
Der Gegenwind ist nicht erfunden. Vieles an SDD fühlt sich tatsächlich an wie Zeremonie, die Tokens verbrennt.
Wenn dein Framework einen Kurzroman verlangt, bevor du einen einzigen Endpoint änderst, bekommst du keine Disziplin. Du kaufst dir Verzögerung. Genau da trifft der Vorwurf „Wasserfall mit Markdown“. Schwere Setups erzeugen eingefrorene Specs, Review-Müdigkeit und ein falsches Gefühl von Kontrolle.
Die Kritik zielt vor allem auf schweres SDD
Birgitta Böckelers Einteilung ist hier wichtig. Spec-first kann nützlich sein. Spec-anchored kann nützlich sein, wenn du das Artefakt pflegst. Bei Spec-as-Source wird es schnell riskant. Böckelers Analyse von Workflows mit generiertem Code weist darauf hin: Sobald Specs die einzige editierbare Quelle sind, führen parallele Änderungen zu Koordinationsproblemen und Drift, weil es keine eingebaute Merge-Policy gibt, die Absichten sauber zusammenführt – nachzulesen in dieser Kritik zu SDD im Vergleich mit Wasserfall.
Auch für Solo Founder ist das Problem nicht theoretisch. Heute bist du allein. Morgen hast du Unterstützung von außen, einen zweiten Agent, einen hastigen Freitags-Patch und eine Spec, der niemand traut.
Faustregel: Wenn es dir ein Framework schwerer macht, deine Meinung zu ändern, als deinen Code zu ändern, ist es zu schwer für ein Startup.
Warum es sich trotzdem lohnt
Weil unstrukturiertes Prompting auf langweilige, teure Art scheitert. Du wiederholst Anforderungen. Das Modell übersieht Constraints. Es schreibt dasselbe Feature zweimal neu. Es macht alten Code kaputt, weil deine Absicht im Chatverlauf lebte statt im Repo.
Bei schlankem SDD geht es nicht um Reinheit. Es geht um Verdichtung. Du schreibst gerade so viel Struktur, dass Claude Code, Cursor, Codex oder Gemini aufhören können zu raten.
Ein gutes schlankes Framework leistet vier Dinge:
- Es nagelt die Absicht fest, damit das Modell nicht abschweift.
- Es setzt Grenzen, damit Änderungen nicht ausufern.
- Es ergänzt Validierungsszenarien, bevor Code entsteht.
- Es bleibt editierbar, wenn sich die Realität an Tag zwei ändert.
Wer gerade mit SDD gewinnt, schreibt nicht die längsten Specs. Sondern die kürzeste Spec, die den Kontakt mit einer chaotischen Codebase noch übersteht.
Warum schlanke Frameworks gerade explodieren
Die Kategorie ist explodiert, weil Builder den Overhead im Stil von Spec Kit satthatten.
Das ist die kurze Version. Die lange Version: Schlanke Frameworks passen endlich zu der Art, wie kleine Teams arbeiten. Minimale Konfiguration. Menschenlesbares Markdown oder YAML. Artefakte, die im Repo leben können, ohne das Repo in ein Papierarchiv zu verwandeln.
Die Daten sagen: Das ist keine Nische mehr
Eine Studie, die öffentliche GitHub-Aktivität rund um GitHub Spec Kit, OpenSpec und BMAD-METHOD ausgewertet hat, fand heraus, dass Commits mit Bezug auf diese Frameworks von rund 3.200 im Q4 2023 auf mehr als 28.000 im Q1 2025 gestiegen sind – ein Plus von mehr als 780 % in etwa fünfzehn Monaten. Dieselbe Analyse fand im Median 30 % weniger Nacharbeitszyklen bei Projekten mit schlankem SDD im Vergleich zu unstrukturierten Prompts. Außerdem stammte der Großteil dieser Aktivität von kleineren Teams und unabhängigen Projekten, nicht von riesigen Engineering-Organisationen – so die auf arXiv veröffentlichte GitHub-Analyse.
Dieses Adoptionsmuster ist wichtig. Die Tools verbreiten sich nicht, weil Konzerne eine neue Governance-Gewohnheit entdeckt haben. Sie verbreiten sich, weil Solo Builder wollen, dass die KI aufhört, mit ihrem Code auf eigene Faust zu arbeiten.
Warum es zu diesem Wandel kam
Drei Designentscheidungen tauchen bei den Frameworks, die überleben, immer wieder auf:
- Geringer Einrichtungsaufwand. Du kannst loslegen, ohne dein ganzes Repo umzubauen.
- Lesbare Artefakte. Markdown schlägt für die meisten Founder eigene DSLs.
- Toleranz für Brownfield. Bestehende Codebases brauchen Delta-Specs, keine Fantasien vom leeren Blatt.
OpenSpec ist ein gutes Beispiel für diesen Wandel. Es setzt auf Deltas und Proposals statt auf riesige Dokumente vorab. BMAD steht am meinungsstärkeren Ende, zieht aber trotzdem Builder an, die ein stabileres Gerüst wollen, ohne gleich einen Enterprise-Prozess einzuführen.
Die eigentliche Rebellion richtet sich nicht gegen Specs. Sie richtet sich gegen Zeremonie, die sich als Gründlichkeit ausgibt.
Es gibt noch einen zweiten Grund, warum schlankes SDD wächst. Founder mischen ihre Tools heute ständig. Claude Code für die eine Aufgabe. Cursor für die nächste. Codex oder Gemini für Experimente. Das alte Versprechen „eine IDE, ein Workflow, ein Anbieter“ passt nicht zu dieser Realität.
Wenn du ein Startup aufbaust, ist die Wahl des Frameworks ähnlich wie die Auswahl von VCs aus einer fokussierten Liste für Software. Die falsche Wahl kostet Zeit, die du nicht hast. Es geht nicht um Prestige. Es geht darum, ob das Ding zu deiner Phase und deinen Einschränkungen passt.
Wie wir diese Frameworks vergleichen
Eine Feature-Checkliste ist nutzlos, wenn dein AI Agent um 1 Uhr nachts gerade deinen Auth-Flow missverstanden und sechs Dateien angefasst hat, die er nicht hätte anfassen dürfen.
Mir sind deshalb vier Dinge wichtig.
Einrichtungsaufwand
Wie lange dauert es von null bis zur ersten brauchbaren Spec?
Wenn ein Framework ein Tutorial, ein Migrationsritual und eine philosophische Bekehrung braucht, hat es schon verloren. Solo Founder brauchen etwas, das sich an einer einzigen echten Aufgabe testen lässt, nicht ein Onboarding-Wochenende.
Kompatibilität mit AI Agents
Das ist der am meisten übersehene Teil der ganzen Kategorie.
Die meisten Inhalte zeigen immer noch nicht, welche Frameworks modellunabhängig sind und welche von bestimmten Tools oder bestimmter Infrastruktur abhängen. Diese Lücke ist wichtig, weil Solo Builder Agents und Editoren mischen und wissen müssen, ob ihre Spec-Artefakte zwischen Claude Code, Cursor, Gemini und Codex wandern können, während die Spec die maßgebliche Quelle bleibt – darauf weist Birgitta Böckeler in ihrer Besprechung von Kiro, spec-kit und Tessl hin.
Wenn dein Framework nur funktioniert, solange du in der Spur eines einzigen Anbieters bleibst, ist es nicht schlank. Das ist Abhängigkeit mit besserem Branding.
Pflegeaufwand
Eine Spec, die du nicht aktualisierst, ist der Müll von morgen.
Die langfristigen Kosten eines Frameworks liegen nicht im Schreiben der ersten Spec. Entscheidend ist, ob die Spec nach dem zweiten Refactoring, dem dritten Bugfix und der Übergabe an ein anderes Modell noch hilft. Spec Drift zerstört Vertrauen schnell.
- Geringer Aufwand heißt: kurze Artefakte, einfache Änderungen und klare Grenzen.
- Mittlerer Aufwand heißt: nützliche Struktur, aber mehr Review und Aufräumarbeit.
- Hoher Aufwand heißt: Deine Dokumentation konkurriert mit deinem Code um Aufmerksamkeit.
Passung zur Codebase
Greenfield und Brownfield sind verschiedene Sportarten.
Eine frische App verträgt einen strengeren Workflow. Ein bestehendes Produkt mit Legacy-Auth, wild verstreuten Skripten und historisch gewachsenen Eigenheiten braucht ein Framework, das Änderungen an der Realität verankern kann. Genau hier fallen die meisten Hochglanz-Demos durch. Sie zeigen ein sauberes Repo und tun so, als würde jeder dort leben.
Wenn deine Codebase schon Narben hat, wähl das Framework, das Narben respektiert.
Schlanke SDD-Frameworks im Überblick
Hier der schnelle Überblick vor der ausführlichen Analyse.
| Framework | Passt am besten zu | Stil | Größte Stärke | Größtes Risiko |
|---|---|---|---|---|
| Vibe Kanban | Niemandem mehr. Es wurde eingestellt. | Workflow-Board | Gute warnende Lektion | Anbieterrisiko |
| OpenSpec | Solo Builder mit Brownfield-Projekten | Schlank, Delta-orientiert | Flexibel und schnell | Kann sich zu locker anfühlen |
| Measure | Builder, die eine leichtere Methode wollen | Harness-unabhängig | Pitch mit minimalem Overhead | Früh und weniger erprobt |
| BMAD | Builder, die Struktur und Community wollen | Meinungsstarke Methode | Starke Templates und aktive Community | Kann schwer werden |
| Spec Kitty | Projekte mit viel Legacy | Brownfield-orientiert | Ausdrücklich für alten Code gedacht | Neu und muss sich noch beweisen |
| GSD | Claude-Code-Nutzer, die Tempo mögen | Workflow-first | Direkt, schnell | Wirkt wie ein engeres Ökosystem |
| Superpowers | Claude-Code-Nutzer, die Review-Disziplin wollen | Plugin-Ebene | Fokus auf Plantreue | Zusätzliche Komplexität |
| sdd-flow | Builder, die mit orchestrierten Abläufen experimentieren | Multi-Agent | Prozessautomatisierung | Mehr bewegliche Teile |
Der ganze Markt bewegt sich schnell. Behandle jede Framework-Bewertung als Momentaufnahme, nicht als heilige Schrift. Wenn du die größere Landkarte willst, wie diese Tools zusammenpassen, lies den breiteren Überblick über die SDD-Tools 2026.
Vibe Kanban
TL;DR: Eine gute Erinnerung daran, dass Workflow-Tools schneller verschwinden können als deine Specs.
Vibe Kanban ist der warnende Eintrag in dieser Liste. Es wurde eingestellt, nachdem das Unternehmen 2026 geschlossen hat. Das macht die Ideen nicht wertlos, aber es macht einen Punkt schmerzhaft klar: Wenn dein ganzer Prozess von einer gehosteten Ebene oder einem proprietären Workflow-Wrapper abhängt, gehst du ein Plattformrisiko ein, ob du es zugibst oder nicht.
Was gut ist
- Klare Lektion in Sachen Portabilität. Artefakte im Repo altern besser als Task-Boards in einer App.
- Gesunde Skepsis. Wenn der Wert eines Frameworks mit dem Unternehmen stirbt, war das Framework nicht schlank genug.
Was nicht gut ist
- Es wurde eingestellt. Allein das streicht es von jeder ernsthaften Shortlist.
- Es hat eine verbreitete Falle offengelegt. Founder verwechseln oft Workflow-UX mit einer dauerhaften Methode.
Wann du es wählen solltest
Gar nicht – es sei denn, du studierst alte Muster oder migrierst weg.
OpenSpec
TL;DR: Aktuell die beste Wahl für chaotischen Bestandscode, wenn du Struktur ohne Religion willst.
OpenSpec ist die schlanke Alternative zu Spec Kit, die für mich bei Brownfield-Arbeit allein am meisten Sinn ergibt. Der Ablauf ist specify → plan → tasks → implement, aber starre Phase Gates erzwingt es nicht. Es passt natürlich zu OpenCode und hält die Artefakte nah am Code.
Ein unabhängiger Vergleich ergab, dass die Pipeline von OpenSpec überflüssige Regenerierungszyklen etwa um den Faktor 2 bis 4 reduziert hat – verglichen mit Ad-hoc-Prompting am selben Feature in einer bestehenden Codebase, so der Vergleich von Spec-Workflows auf GitHub. Genau solche Vorteile zählen in der Praxis, denn beim Regenerieren verschwinden deine Abende.
Was gut ist
- Passt zu Brownfield. Delta-basierte Artefakte verankern die Änderung am Code, den du schon hast.
- Wenig Zeremonie. Das Slash-Command-Modell steht dir nicht im Weg.
- Gute Flexibilität bei Modellen. Der Stil der Artefakte ist portabel genug, um ihn an verschiedene Coding-Agents zu übergeben.
Ein Reddit-Thread zu OpenSpec mit OpenCode zeigt, warum es Leute mögen. Jemand beschrieb es dort als saubereren Weg für bestehende Projekte statt eines großen Rewrite-Workflows, nachzulesen in dieser OpenSpec-Diskussion auf Reddit.
Was nicht gut ist
- Lose Kanten. Wenn du strikte Durchsetzung willst, wirkt OpenSpec womöglich zu schwach.
- Braucht Disziplin von dir. Freiheit ist großartig, bis du aufhörst, das Artefakt zu aktualisieren.
Wann du es wählen solltest
Nimm OpenSpec, wenn deine App schon existiert, dein Stack gemischt ist und du eine Spec willst, die deinen Agent von dummen Annahmen abhält, ohne dir eine komplette Prozesstransplantation aufzuzwingen.
Measure
TL;DR: Vielversprechend, wenn du eine leichtere Methode willst und Wert darauf legst, Harness-unabhängig zu bleiben.
Measure beschreibt sich selbst als leichteres SDD-Framework und ist am 25. April 2026 gestartet. Das Interessante ist nicht nur „leichter“. Es ist die Harness-unabhängige Positionierung. Das ist der richtige Instinkt für diesen Markt. Die meisten Solo Builder wollen ihren Prozess nicht für immer an einen einzigen Assistenten binden.
Was gut ist
- Der Pitch „schlank“ ist glaubwürdig. Er zielt genau auf den Schmerzpunkt, der Leute von schwereren Frameworks vertrieben hat.
- Freundlich zu mehreren Tools. Die Harness-unabhängige Ausrichtung ist attraktiv, wenn du zwischen Editoren und Modellen hin- und herspringst.
Was nicht gut ist
- Es ist früh. Neue Frameworks können elegant aussehen, bevor sie auf Edge Cases treffen.
- Weniger Praxiserfahrung. Du bekommst nicht dieselbe Menge an Community-Mustern wie bei BMAD oder OpenSpec.
Auf Reddit drehte sich die frühe Diskussion um Measure um den Reiz von „leichter“ statt um große Versprechen zum Ökosystem – und genau darauf solltest du achten, nachzulesen in diesem Measure-Thread in der OpenCode-CLI-Community.
Wann du es wählen solltest
Probier Measure aus, wenn du die Schwerkraft von Frameworks hasst und deinen Workflow portabel halten willst. Zum Zentrum eines geschäftskritischen Prozesses würde ich es noch nicht machen, es sei denn, du kannst gut damit leben, nachzujustieren, während es reift.
BMAD
TL;DR: Mehr Struktur, größere Community, leichter zu übertreiben.
BMAD ist das Aushängeschild des Framework-Goldrauschs. Das GitHub-Repo ist sehr sichtbar, der Discord ist aktiv, und der Pitch eines Multi-Agent-„Teams in a Box“ kommt bei Foundern an, die mehr wollen als eine nackte Spec-Datei.
Was gut ist
- Energie in der Community. Ein lebendiger Discord und ein großes öffentliches Repo erleichtern den Einstieg.
- Meinungsstarke Templates. Hilfreich, wenn du mehr Anleitung und weniger Angst vor dem leeren Blatt willst.
- Lernmaterial im Ökosystem. Es gibt bereits Schulungsmaterial dazu, etwa das Repository der BMAD-Methode und einen BMAD-Kurs auf Udemy.
Was nicht gut ist
- Framework Creep. BMAD kann dich von „gerade genug Struktur“ zu „jetzt pflege ich ein System“ ziehen.
- Kann für Solo-Arbeit zu viel sein. Wenn du diese Woche nur ein Feature ausliefern willst, kann es sich anfühlen, als würdest du ein Zwei-Personen-Startup in Enterprise-Kleidung stecken.
BMAD ist nützlich, wenn du Hilfe beim Denken willst. Schlecht wird es, wenn es anfängt, an deiner Stelle zu denken.
Wann du es wählen solltest
Wähl BMAD, wenn du stärkere Leitplanken willst, gern bei einer Community abschaust und dir eine Einrichtungs- und Pflegesteuer für diese Struktur nichts ausmacht.
Spec Kitty
TL;DR: Interessant, wenn dein eigentliches Problem alter Code ist, nicht neue Features.
Spec Kitty tauchte im Mai 2026 mit einer Positionierung auf, die für Founder mit Legacy-Repos sofort Sinn ergibt. Das ist ein klügeres Ziel als die übliche Greenfield-Fantasie. Die meisten Founder, die das hier lesen, fangen nicht bei null an. Sie versuchen, Ordnung in ein Repo mit Geschichte zu bringen.
Was gut ist
- Brownfield-first-Positionierung. Das ist der richtige Marktbedarf.
- Verständnis für Legacy. Jedes Framework, das bei „dein Repo ist seltsam“ anfängt, hat meine Aufmerksamkeit.
Was nicht gut ist
- Neu am Markt. Langfristige Belege gibt es noch kaum.
- Unklarer Pflegeaufwand. Neue Frameworks wirken oft leicht, bevor der Wildwuchs an Artefakten einsetzt.
Wann du es wählen solltest
Spec Kitty ist einen Test wert, wenn deine App älter ist, deine Architektur abgedriftet ist und leichtere Delta-Specs besser klingen als ein vollständiger doktrinärer Workflow. Ich würde es an einem Feature erproben, bevor ich ihm eine breite Prozessänderung anvertraue.
GSD
TL;DR: Schneller Claude-Code-Workflow für Builder, die lieber handeln als theoretisieren.
GSD, kurz für Get Shit Done, sagt schon im Namen, worum es geht. Das ist kein Framework für Leute, die eine lange Vorrede wollen. Es passt zur pragmatischen Claude-Code-Fraktion, die genug Struktur will, um schnell voranzukommen, ohne so zu tun, als leite sie eine Prozessabteilung.
Was gut ist
- Direktheit. Weniger einschüchternd als manche SDD-Marken.
- Passt zu Buildern, die auf Tempo setzen. Die Workflow-Ausrichtung spricht Solo Founder an, denen Momentum wichtig ist.
Was nicht gut ist
- Möglicherweise enge Bindung an ein Tool. Frameworks, die um ein einziges Agent-Ökosystem gebaut sind, altern oft schlecht, wenn sich dein Stack ändert.
- Weniger offensichtliche Haltbarkeit. Schnelle Workflows können Wartungsschulden verstecken, bis es zu spät ist.
Wann du es wählen solltest
Nimm GSD, wenn Claude Code ohnehin dein Schwerpunkt ist und du ein schlankes Ritual willst, das die Umsetzung in Bewegung hält. Lass es weg, wenn dir Portabilität zwischen Modellen besonders wichtig ist.
Superpowers
TL;DR: Starkes Add-on für Claude-Code-Nutzer, die Plantreue prüfen wollen – bezahlt wird mit zusätzlichem Prozess.
Superpowers ist ein Claude-Code-Plugin, das auf stärkeres Review-Verhalten und Multi-Agent-Prüfungen der Plantreue setzt. Das macht es attraktiv, wenn dein größter Schmerz nicht das Schreiben des Plans ist, sondern den Agent davon abzuhalten, vom Plan abzudriften.
Was gut ist
- Review-Disziplin. Hilfreich, wenn dein Agent gern übers Ziel hinausschießt.
- Klares Wertversprechen. Es konzentriert sich auf ein konkretes Fehlerbild: Das Modell ignoriert den Plan mitten in der Implementierung.
Die Diskussionen in der Community spiegeln diesen Produktivitätsaspekt wider. Builder in diesem Thread über Superpowers in r/ClaudeWorkflows sprechen davon als Workflow-Booster, nicht als große Methodik. Das ist ein besseres Zeichen als viel Framework-Marketing.
Was nicht gut ist
- Mehr bewegliche Teile. Review-Ebenen können zu ihrer eigenen Zeremonie werden.
- Claude-Schlagseite. Wenn du oft zwischen Tools wechselst, passt es schlechter.
Wann du es wählen solltest
Wähl Superpowers, wenn Claude Code dein Hauptwerkzeug ist und dein Hauptproblem das Abdriften vom Plan ist, nicht das Erstellen der Spec.
sdd-flow
TL;DR: Interessant für Experimente mit Orchestrierung, aber riskant, wenn du deiner grundlegenden Spec-Disziplin noch nicht traust.
sdd-flow geht weiter in Richtung Multi-Agent-Orchestrierung. Das kann aufregend klingen. Es kann aber auch Verwirrung vervielfachen, wenn die zugrunde liegende Spec schwach ist. Mehr Agents reparieren keine vage Absicht. Sie verteilen sie nur schneller.
Was gut ist
- Ehrgeiz bei der Automatisierung. Nützlich, wenn du mehr Prozessautomatisierung willst, als ein reiner Markdown-Workflow bieten kann.
- Potenzial für komplexe Abläufe. Es gibt Fälle, in denen gestufte Orchestrierung hilft.
Was nicht gut ist
- Komplexitätssteuer. Mehr Orchestrierung heißt mehr Debugging am Workflow selbst.
- Schwierigere Fehlerbilder. Wenn etwas abdriftet, ist weniger offensichtlich, wo die Drift begann.
Die Diskussion in diesem Reddit-Thread zu sdd-flow in der Claude-AI-Community zeigt den Reiz der Orchestrierung – und genau dieser Reiz sollte vorsichtige Builder bremsen.
Wann du es wählen solltest
Probier sdd-flow nur aus, wenn du Spec-Disziplin schon beherrschst und mit stärker orchestriertem Agent-Verhalten experimentieren willst. Einem Solo Founder würde ich nicht raten, hier anzufangen.
Feature-Matrix: Frameworks nebeneinander
Wenn du direkt hierher gesprungen bist: verständlich. Das ist die Shortlist-Ansicht.
Schlanke SDD-Frameworks auf einen Blick
| Framework | Kernidee | Am besten für | KI-Integration | Pflegekosten |
|---|---|---|---|---|
| Vibe Kanban | Workflow-Management rund um SDD | Niemanden mehr. Nur noch als historische Referenz | Unklar, da eingestellt | Hohes Risiko, da eingestellt |
| OpenSpec | Schlanker Spec-Ablauf im Repo mit Deltas | Solo Founder und kleine Teams mit Brownfield-Projekten | Flexibel. Funktioniert gut mit gemischten Agent-Stacks | Gering bis mittel |
| Measure | Leichtere, Harness-unabhängige Methode | Builder, die Lock-in bei Anbietern oder Tools vermeiden | Darauf ausgelegt, portabel zu bleiben | Gering, zumindest in der Theorie |
| BMAD | Meinungsstarke Methode mit starken Templates und Community | Builder, die mehr Gerüst wollen | Breit angelegt, aber mit schwereren Workflow-Erwartungen | Mittel bis hoch |
| Spec Kitty | Schlankes Framework mit Fokus auf Brownfield und Legacy | Bestehende Codebases mit Geschichte | Vermutlich portabel, noch früh | Unbekannt |
| GSD | Schneller Claude-Code-Workflow | Solo Builder mit Fokus auf Tempo in Claude-lastigen Setups | Am stärksten, wenn Claude Code dein Standard ist | Gering bis mittel |
| Superpowers | Claude-Plugin für Plantreue und Review | Builder, die gegen Drift bei der Implementierung kämpfen | Am besten innerhalb von Claude-Code-Workflows | Mittel |
| sdd-flow | Multi-Agent-Orchestrierung rund um SDD | Wer gern experimentiert und tief tüftelt | Auf Orchestrierung ausgerichtet | Mittel bis hoch |
Was die Matrix auf die Schnelle zeigt
Drei Muster zählen mehr als das ganze Branding.
- OpenSpec und Measure passen zu Buildern, die Portabilität und weniger Zeremonie wollen.
- BMAD und Superpowers passen zu Buildern, die mehr Prozesskontrolle wollen.
- sdd-flow ist etwas für alle, die gern an Workflows tüfteln, nicht für den Einstieg.
Wenn dein Repo alt, seltsam oder fragil ist, zählt die Passung zu Brownfield mehr als die Zahl der Features. Deshalb stechen OpenSpec und Spec Kitty für die meisten Solo Founder stärker heraus als auffällige Orchestrierungs-Tools.
So wählst du das richtige SDD-Framework
Die meisten Framework-Vergleiche helfen dir immer noch nicht, nach Größe und Reife der Codebase zu entscheiden. Genau das ist die Kernentscheidung. Bestehende Vergleiche lassen Solo Founder oft raten, ob für ihre tatsächliche Projektform ein leichterer Ansatz im Stil von OpenSpec passt oder etwas Meinungsstärkeres wie BMAD – so auch dieser Praxistest aktueller SDD-Tools.
Deshalb hier die praktische Version.
Wenn deine Codebase schon existiert
Fang mit OpenSpec an.
Nicht, weil es gerade angesagt ist. Sondern weil bestehende Repos Starrheit bestrafen. Der Proposal-first-Stil von OpenSpec, der gut mit Deltas umgehen kann, ist die sicherste Standardwahl für eine Codebase mit Geschichte. Wenn dein Repo Legacy-Auth, alte Migrationen, gemischte Konventionen oder undokumentierte Edge Cases hat, brauchst du ein Framework, das sich biegen lässt.
Spec Kitty ist ebenfalls einen Test wert, wenn das Repo stark Brownfield ist und dein größter Schmerz die Legacy-Komplexität ist, nicht die Prozesskonsistenz.
Wenn du mehr Struktur willst
Nimm BMAD.
Tu das, wenn die Lähmung vor dem leeren Blatt dein größeres Problem ist als Prozess-Overhead. BMAD gibt dir stabilere Schienen, mehr Beispiele und eine aktivere gemeinschaftliche Methode. Der Kompromiss liegt auf der Hand: Mehr Struktur heißt mehr Pflege. Das ist in Ordnung, wenn dir das Gerüst etwas bringt.
Wenn Claude Code dein Hauptwerkzeug ist
Dann wird deine Auswahl schnell kleiner.
- GSD, wenn du vor allem Tempo und einen geradlinigen Workflow willst.
- Superpowers, wenn Drift während der Implementierung dein eigentliches Problem ist.
- sdd-flow nur, wenn dir das Verwalten von Systemen genauso viel Spaß macht wie das Ausliefern von Produkt.
Wenn du oft Modelle und Editoren wechselst
Setz auf OpenSpec oder Measure.
Portabilität zählt mehr als Feinschliff, wenn sich dein Stack jede Woche ändert. Es ist dieselbe Art von Abwägung, die du auch anderswo in deinem Stack triffst. Ein SDD-Framework auszuwählen ist ähnlich wie die Wahl zwischen Astro und Next.js. Die richtige Antwort hängt weniger von abstrakter Qualität ab als von den tatsächlichen Einschränkungen deines Projekts.
Wenn du eine verwaltete Spec-Ebene statt eines Framework-Rituals willst
Es gibt noch einen anderen Weg. In Tekk.coach lesen Loops, was sich in deinem GitHub-Repo geändert hat, und schreiben Specs für dich – als Proposals, die du mit Greenlight freigibst; du kannst auch selbst eine schreiben. Dein Coding-Agent (Cursor, Claude Code, Codex) baut jede Spec über den Tekk-MCP-Server, und der gemergte PR schließt sie. Tekk schreibt nie den Code. Wenn du die minimale Form des Artefakts selbst willst, ist dieses minimale Spec-Format die nützliche Grundlage, vor allem bevor du eine schwerere Methode einführst.
Nimm das leichteste Framework, das wiederholte Fehler noch verhindert. Alles Schwerere ist Overhead, für den du dich entscheidest.
Fazit: Hör auf zu debattieren, fang an zu spezifizieren
Ein perfektes Framework gibt es hier nicht.
Es gibt nur Kompromisse, mit denen du leben kannst, und Kompromisse, die dich so lange nerven, bis du aufgibst. Für die meisten Solo Founder gewinnt nicht das Framework mit den meisten Features. Sondern das, das du nach dem dritten gehetzten Feature-Request und dem zweiten kaputten KI-Patch noch benutzt.
Meine unverblümte Meinung ist einfach. Fang mit OpenSpec an, wenn du eine bestehende Codebase hast. Probier BMAD, wenn du mehr Leitplanken willst. Teste Measure, wenn dir Portabilität und Minimalismus am wichtigsten sind. Begegne orchestrierungslastigen Setups mit Misstrauen, bis du bewiesen hast, dass du erst einmal eine einfache Spec-Gewohnheit durchhältst.
Verbring keine zwei Wochen mit Methodendebatten. Schick ein echtes Feature durch ein Framework. Beurteile es nach Nacharbeit, Klarheit und danach, ob dein Agent innerhalb der Grenzen geblieben ist.
Specs von Hand zu schreiben ist der manuelle Weg. Die Loops von Tekk.coach schreiben sie für dich, aus dem, was sich in deinem Code geändert hat: dasselbe Board, dieselben Akzeptanzkriterien, geschlossen, sobald der PR gemergt wird.
Teil des Leitfadens zu Spec-driven Development – ein ehrliches Playbook dafür, mit KI-Coding-Agents auszuliefern. Die andere Hälfte ist Loop Engineering: An der Spec erkennt ein Loop, dass er fertig ist.