Der verbreitete Rat lautet: Du brauchst ein größeres Spec-System. Mehr Templates. Mehr Markdown. Mehr Agent-Rollen. Für die meisten Solo Builder halte ich das für verkehrt herum.
Der Gegenwind gegen Spec-driven Development im Mai 2026 kam nicht aus dem Nichts. Die Kritik nannte es „Wasserfall mit Markdown“, „Produktivitätsfalle“, „Spec Drift“, „eingefrorene Specs“ und „Token verbrennende Zeremonie“. Diese Kritik sitzt, wenn der Workflow zum Ritual wird und der Code hinterherhinkt. Simon Willison hat deutlich vor den Risiken gewarnt, KI-gestütztes Coden zu stark zu strukturieren. Auch Birgitta Böckelers Taxonomie ist hier wichtig. Spec-first, spec-anchored und spec-as-source sind nicht dasselbe. Addy Osmanis kanonisches Spec-Format mit sechs Abschnitten ist nützlich, aber ein Template allein schützt dich nicht vor Aufblähung. Thoughtworks Tech Radar, GitHub Spec Kit, Kiro, OpenSpec, Traycer, Vibe Kanban und BMAD liegen alle irgendwo auf diesem Spektrum.
Die entscheidende Frage ist nicht, ob Specs gut sind. Sondern ob der Workflow dir beim Ausliefern hilft, wenn du überwiegend allein baust.
Deshalb ist dieser Vergleich wichtig. Wenn du etwas Leichteres als Spec Kit suchst, stehen diese drei für drei sehr unterschiedliche Antworten. BMAD ist Community-getrieben und setzt stark auf Muster. Get Shit Done (GSD) ist ein schlanker Ausführungs-Workflow mit einer starken Fangemeinde in der Claude-Code-Szene. Tekk.coach fällt aus der Reihe: Seine Loops finden die Arbeit in deiner Codebase und schreiben die Spec, und jeder Coding-Agent kann sie bauen. Dieselbe grobe Kategorie. Sehr unterschiedliche Wetten.
Inhalt
- Der Gegenwind gegen Spec-driven Development und die Suche nach dem, was funktioniert
- Tekk vs. BMAD vs. GSD im direkten Vergleich
- Wann BMAD gewinnt: der Community-first-Ansatz
- Wann GSD gewinnt: der schlanke Claude-Code-Workflow
- Wann Tekk.coach gewinnt: die integrierte Plattform für Solo Founder
- Das Fazit: So wählst du deinen Workflow
Der Gegenwind gegen Spec-driven Development und die Suche nach dem, was funktioniert
Der Gegenwind ist echt
Der Gegenwind ist leicht zu verstehen. Viele haben Spec-driven Workflows ausprobiert und dann gemerkt, dass sie Dokumente schreiben, die das Modell bewundern, aber nicht sauber ausführen kann. Daher kommt das Etikett „Wasserfall mit Markdown“.
Das Schwierige ist: Beide Lager reden oft über verschiedene Dinge. Ein aufgeblähtes Framework mit zu vielen Gates ist nicht dasselbe wie eine schlanke Planungsgewohnheit. Ein statisches Anforderungsdokument ist nicht dasselbe wie spec-as-source, wo die Spec das einzige Artefakt ist, das Menschen bearbeiten, und der Code daraus generiert wird. Das macht Drift sichtbar statt versteckt, wie dieses Paper zu spec-as-source beschreibt.
Eines der deutlichsten Zeichen dafür, dass sich dieser Markt sortiert, ist die auseinanderlaufende Verbreitung. In der Phase des Gegenwinds wuchs ein Spec-driven Framework in sechs Monaten um 863 %, während ein Konkurrent in derselben Kategorie nur um 18 % zulegte, laut dieser YouTube-Analyse vom Mai 2026. Diese Lücke ist wichtig. Sie deutet darauf hin, dass die Szene Struktur nicht grundsätzlich ablehnt. Sie lehnt schlechte Mechanik in der Ausführung ab.
Praktische Regel: Wenn dein Spec-Workflow mehr Tokens verbrennt, um den Prozess zu erklären, als um das Feature zu bauen, ist der Workflow das Problem.
Was Solo Builder wirklich brauchen
Als Solo Founder brauchst du meistens nicht mehr Zeremonie, sondern eines von drei Dingen.
- Ein Denksystem: etwas, das bessere Anforderungen erzwingt und Architekturfehler früh abfängt.
- Eine Ausführungsgewohnheit: etwas, das den Agent über lange Sessions scharf hält.
- Eine Quelle für Arbeit: etwas, das die Codebase liest, findet, was zu tun ist, und es geordnet hält.
Durch diese Brille würde ich BMAD, GSD und Tekk.coach betrachten.
Die breitere Diskussion in diesem Reddit-Thread darüber, dass Spec-driven Development das Vibe Coding ablöst, zeigt, warum leichtere Alternativen immer wieder auftauchen. Wer baut, will mehr Verlässlichkeit, als reines Vibe Coding bietet, aber viele wollen auch nicht den Overhead eines schwergewichtigen Frameworks.
Die bessere Frage ist also nicht „Welches Framework ist das beste?“, sondern diese: Welche Art von Scheitern willst du vermeiden? Falsches Design. Verrotteten Kontext. Oder die Arbeit, die niemandem aufgefallen ist.
Tekk vs. BMAD vs. GSD im direkten Vergleich
Tekk.coach vs. BMAD vs. GSD in der Übersicht
| Kriterium | BMAD | Get Shit Done (GSD) | Tekk.coach |
|---|---|---|---|
| Integrationsumfang | Framework und Methode | Workflow-Schicht für die Ausführung beim KI-Coding | Loops, die die Arbeit finden und die Spec schreiben, auf einem Board |
| Agent-Lock-in | Flexibler, Multi-Agent-Muster | Passt am besten, wenn du in Claude Code lebst, auch wenn es breitere Runtime-Unterstützung gibt | Agent-agnostisch: Claude Code, Codex oder Cursor baut die Spec über den Tekk-MCP-Server |
| Gewicht des Spec-Formats | Schwerer im vollen Modus, leichter in BMAD Quick | Schlank und operativ | Kurze Specs mit Akzeptanzkriterien und Checkliste; Loops schreiben sie, oder du schreibst eine von Hand |
| Community-Modell | Discord-first, Lernen in der Community | Open Source, Nische, aber aktives Interesse in Claude-Code-Kreisen | Produktgeführtes Erlebnis |
| Codebase-Bewusstsein | Hängt davon ab, wie du Kontext lieferst | Nicht der Hauptunterschied | Loops lesen, was sich in deinem GitHub-Repo geändert hat, und verfolgen es bis zu dem, was es berührt |
| Lernkurve | Höher, wenn du die volle Methode nutzt | Niedriger, wenn du ein diszipliniertes Ausführungsmuster willst | Niedriger bei der Methodik, aber ein anderer Trade-off, weil es eine gehostete Plattform ist |
| Kanban und Workspace | Nicht der Kernnutzen | Nicht der Kernnutzen | Eingebautes Board; ein gemergter PR, in dem Closes TEK-123 steht, schließt die Spec |
| Für wen | Wer Planungstiefe und Community-Muster will | Wer pragmatisch in Claude Code arbeitet und möglichst wenig Framework will | Solo Founder, die sich die Arbeit finden lassen wollen und jede Spec durch einen Merge schließen |
So liest du die Tabelle
Der größte Unterschied ist hier philosophisch.
BMAD behandelt Entwicklung wie einen koordinierten Mannschaftssport, auch wenn das Team größtenteils synthetisch ist. Es geht um Rollen, Review, Struktur und darum, Fehler abzufangen, bevor sie sich verfestigen. Das macht es attraktiv, wenn dir meistens Architekturfehler wehtun.
GSD sieht das Kernproblem im Kontextverfall. Das ist eine kluge Wette. Lange KI-Coding-Sessions werden unmerklich schlechter. Der Agent startet stark und wird dann unscharf. GSD ist dafür gebaut, dieses Abrutschen zu stoppen, indem es die Arbeit in Phasen und frische Fenster aufteilt.
Tekk.coach gehört in eine andere Schublade. Es ist kein Framework zum Auswendiglernen. Seine Loops finden die Arbeit und schreiben die Spec. Das ist wichtig, wenn dein Problem nicht lautet „Wie schreibe ich ein besseres Spec-Template?“, sondern „Was in dieser Codebase braucht als Nächstes Arbeit, während ich allein ausliefere?“
Viel Verwirrung in dieser Kategorie entsteht, weil man eine Methodik, eine Workflow-Schicht und eine Plattform vergleicht, als wären sie derselbe Produkttyp. Sind sie nicht.
Eine letzte Nuance ist wichtig. Zwischen spec-anchored Arbeit und striktem spec-as-source liegt ein großer Unterschied. Die meisten Solo Builder werden nicht dauerhaft im reinen Spec-as-Source-Modus leben. Sie brauchen weiterhin Raum für Iteration und Urteilsvermögen. Entscheide also nicht nach Ideologie. Entscheide danach, wo dein Workflow gerade bricht.
Wann BMAD gewinnt: der Community-first-Ansatz
BMAD ist am stärksten, wenn Designfehler teuer sind
BMAD gewinnt, wenn dir ein richtiges Design wichtiger ist, als schnell beim Code anzukommen.
Das ist kein Gerede. In einer Vergleichsanalyse orchestriert BMAD mehr als 12 spezialisierte AI Agents und erzielte insgesamt 3,65 von 4,00 Punkten, mit 4 von 4 bei der Spec-Qualität, womit es in dieser Dimension vor Spec-Kit lag, laut diesem Praxisvergleich mit BMAD. Das zeigt dir, worauf BMAD optimiert. Bessere Planungsqualität. Mehr Review. Mehr Chancen, eine schlechte Entscheidung abzufangen, bevor sie sich durchs Repo zieht.
Deshalb ergibt BMAD Full für komplexe Arbeit Sinn. Wenn sich eine falsche Architekturentscheidung nur schmerzhaft rückgängig machen lässt, ist zusätzliche Planung keine Verschwendung. Sie ist eine Versicherung.
Ein paar Eigenschaften von BMAD stechen heraus:
- Multi-Agent-Teammuster: Rollen für Planung, Entwicklung, QA und Review lassen den Prozess wie ein besetztes Projekt wirken, nicht wie einen einzigen langen Chat.
- Adversarial Review: eine der nützlichsten Ideen von BMAD. Sie geht davon aus, dass die erste Antwort falsch sein kann.
- BMAD Quick: ein leichterer Weg für kleinere Features. Dieselbe Grundhaltung beim Herausarbeiten der Anforderungen, weniger Zeremonie.
Die Open-Source-Basis der Methode findest du im GitHub-Repository BMAD-METHOD, und dass es ein Integrations-Repo BMAD-SPEC-KIT gibt, sagt ebenfalls etwas Wichtiges. Wer BMAD nutzt, ist beim Setup nicht dogmatisch. Man experimentiert.
Sein eigentlicher Burggraben ist die Community
Die größte Stärke von BMAD ist nicht nur die Prompt-Struktur. Sondern dass die Methode sozial lebt.
Die BMAD-Discord-Community ist das deutlichste Signal. BMAD gehört zu den Frameworks, bei denen Doku zählt, Gespräche aber noch mehr. Wenn du am besten lernst, indem du zusiehst, wie andere Prompts teilen, über Muster streiten und gemeinsam seltsame Edge Cases debuggen, passt dieses Modell.
Diese Community-first-Form ist nicht trivial. Als Solo Founder brauchst du meist kein weiteres PDF, sondern einen Ort, an dem du fragen kannst: „Warum ist dieses Architekturdokument aus dem Ruder gelaufen?“, und eine brauchbare Antwort bekommst. Genau da schlägt BMAD oft Tools, die aufgeräumter aussehen, aber schwächere Communities haben.
Was funktioniert: BMAD passt gut, wenn du beim Lernen der Methode andere um dich haben willst, die auch bauen.
Darin steckt auch eine Lektion fürs Gründen. Gute Systeme verbreiten sich über Vertrauen und wiederholten Austausch, nicht nur über Dokumentation. Wenn dich diese Dynamik auch jenseits von Tooling interessiert, lohnen sich die Networking-Einblicke von Founder Connects, weil hier dasselbe Prinzip gilt. Starke Netzwerke unter Leuten, die bauen, verhindern dumme Fehler.
BMAD ist allerdings nicht für alle.
- Das Gewicht kann dich abschrecken: Volles BMAD kann sich nach viel anfühlen, wenn dein Projekt klein ist.
- Das Discord-first-Modell ist ein echter Trade-off: Manche wollen Doku und deterministische Abläufe statt Auslegung durch die Community.
- Es verführt zum Überdesign: Wenn du schon weißt, dass das Feature unkompliziert ist, kann tiefe Planung zur Verzögerung werden.
Wenn du einen breiteren Blick auf leichtere Alternativen willst, ist dieser Vergleich schlanker SDD-Frameworks eine gute Begleitlektüre.
Wann GSD gewinnt: der schlanke Claude-Code-Workflow
GSD ist um Kontextdisziplin herum gebaut
GSD gewinnt, wenn dein Hauptgegner nicht schlechtes Produktdenken ist, sondern der Verfall der Session.
Deshalb hat GSD echte Zugkraft. Get Shit Done hat 58.900 GitHub-Sterne, unterstützt Claude Code plus 13 weitere Runtimes wie Cursor, Codex und Gemini, und das neueste stabile Release ist v1.38.5 mit Deployment-Datum 25. April 2026, wie dieser GSD-Überblick bei Augment Code berichtet. So viel Verbreitung und aktive Pflege zeigen, dass das kein Spielzeug-Workflow ist.
Was GSD unterscheidet, ist das Ausführungsmodell. Es zerlegt die Arbeit in atomare Pläne und verlagert die Implementierung in frische Context Windows. Der Gedanke ist simpel. Halte die Haupt-Session sauber. Lagere die Schwerarbeit aus. Lass nicht zu, dass sich eine riesige Unterhaltung selbst vergiftet.
Der praktische Reiz liegt auf der Hand, wenn du je zugesehen hast, wie eine lange Claude-Code-Session langsam den Faden verliert. GSD behandelt genau das als zentrales Designproblem.
Eine nützliche Sicht aus der Praxis liefert dieser Reddit-Rückblick nach zwei Monaten GSD für Spec-driven Arbeit. Wegen dieses Threads würde ich GSD als Nische bezeichnen, aber als echte. Es sammelt nicht nur Sterne auf GitHub. Leute versuchen, darin zu arbeiten.
Wo es passt und wo nicht
GSD ist für ein bestimmtes Profil am stärksten.
- Du arbeitest schon in Claude Code oder ähnlichem Agent-Tooling
- Du willst eine schlanke Gewohnheit, kein schweres Framework
- Dir ist eine saubere Ausführungshistorie wichtig
- Du baust etwas Nicht-Triviales, willst aber trotzdem wenig Overhead
Sein Workflow hat eine scharfe Kante. Der Prozess ist strukturiert genug, um dich ehrlich zu halten, aber nicht so verschnörkelt, dass der Prozess zum Projekt wird.
Auch die Trade-offs sind wichtig.
Erstens versteht man GSD am besten als Workflow-Schicht, nicht als vollständige Planungsumgebung. Wenn du einen eingebauten Workspace, ein Projekt-Board oder eine dauerhafte Planungsfläche willst, ist das nicht wirklich seine Spur.
Zweitens: Auch wenn das Ökosystem breiter geworden ist, liegt der Schwerpunkt noch in der Claude-Code-Kultur. Das ist eine Stärke, wenn du dich auf diese Welt festgelegt hast. Es ist eine Einschränkung, wenn du ein neutraleres Zuhause für deine Planung willst.
GSD fühlt sich weniger nach „Übernimm diese Methodik“ an und mehr nach „Hör auf, deine KI-Coding-Sessions verrotten zu lassen“.
Deshalb würde ich es allen empfehlen, die pragmatisch arbeiten. Nicht denen, die Frameworks als Hobby sammeln. Nicht denen, die eine große Philosophie suchen. Sondern denen, die wollen, dass der Agent scharf bleibt und die Git-Historie sauber.
Wenn Claude Code deine Hauptumgebung ist, lohnt es sich, diesen Leitfaden zu einem Planning Tool für Claude Code mit dem GSD-Ansatz zu kombinieren.
Wann Tekk.coach gewinnt: die integrierte Plattform für Solo Founder
Eine Plattform, kein Prompt-Framework
Tekk.coach gewinnt, wenn du deinen Workflow nicht aus Prompts, Docs, Chat-Threads und Gedächtnis zusammenbauen und nicht allein entscheiden willst, was zu tun ist. Seine Loops finden die Arbeit und schreiben die Spec.
Dieser Unterschied ist wichtig. BMAD und GSD sind Frameworks in verschiedenen Formen. Tekk.coach ist überhaupt kein Framework. Die Spec ist seine Arbeitseinheit, nicht seine Kategorie. Im Mittelpunkt steht nicht „Welchen Slash-Command führe ich als Nächstes aus?“, sondern „Was in diesem Repository braucht Arbeit, und wer schreibt es auf?“
Der stärkste Unterschied: Loops schreiben die Spec aus deinem Code. Sechzehn Loops (Security, Payments, Reliability, Testing und mehr) wachen auf, wenn sich dein Code ändert, lesen, was sich geändert hat, und bringen ein Proposal. Gibst du es mit Greenlight frei, wird daraus eine Spec auf deinem Board; lehnst du es mit einer Begründung ab, lernen die Loops dazu. Statt das Modell das System aus deiner Beschreibung erschließen zu lassen, startest du von dem Code, der schon existiert.
Das macht es besonders nützlich für Brownfield-Arbeit. Die meisten Solo Founder fangen nicht mit einem leeren Ordner an. Sie ergänzen einen Edge Case in der Abrechnung, ersetzen einen wackligen Auth-Flow oder entwirren einen halb funktionierenden Onboarding-Pfad.
Was das in der Praxis heißt
Tekk.coach passt zu einer bestimmten Arbeitsweise.
- Du verbindest GitHub, keinen leeren Prompt: Die Loops starten beim Repo.
- Du entscheidest, was gebaut wird: Jeder Fund kommt als Proposal, das du mit Greenlight freigibst oder ablehnst. Du kannst auch selbst eine Spec von Hand auf dasselbe Board schreiben.
- Du behältst die freie Wahl beim Agent: Claude Code, Codex oder Cursor baut die Spec über den Tekk-MCP-Server.
- Fertig heißt gemergt: Ein PR, in dem
Closes TEK-123steht, schließt die Spec ab, sobald ihre Checkliste abgehakt ist, und dieser Merge ist die nächste Änderung, die die Loops lesen.
Die letzten beiden Punkte brauchen klare Worte. Tekk schreibt nie Code und liefert nie Code aus. Das macht dein Coding-Agent. Das Verknüpfen von PRs ist für GitHub gebaut. Wenn du ein Framework willst, das den ganzen Build in deiner Agent-Session ausführt, oder Repo-Automatisierung über mehrere Git-Hosts, dann ist dieses Produkt nicht das Richtige.
Diese Ehrlichkeit ist wichtig, weil der Vergleich sonst verschwimmt. Tekk will weder der Community-Motor von BMAD sein noch die Context-Engineering-Schicht von GSD. Es will die Arbeit finden, die sich in deiner Codebase lohnt, und sie an den Agent übergeben, den du schon nutzt – für alle, die ohne Senior Engineer im Rücken bauen.
Die Grenze, die du dir merken solltest: Tekk findet die Arbeit und schreibt die Spec. Du entscheidest, was gebaut wird, und dein Coding-Agent baut es.
Damit passt es besser für Solo Founder, die nicht zum Framework-Betrieb werden wollen. Du willst, dass die Arbeit für dich gefunden wird, ein Board und Specs, die im Repo verankert sind. Du willst keine weitere Methodik, die du babysitten musst.
Wenn dein Engpass eher die Klarheit über die Roadmap ist als Prompt-Mechanik, passt dieser Artikel über eine KI-gestützte Produktentwicklungs-Roadmap gut zu dieser Arbeitsweise.
Das Fazit: So wählst du deinen Workflow
Wähl nach deinem Engpass
Wenn du Tekk.coach vs. BMAD vs. Get Shit Done (GSD) so vergleichst, als wäre eines davon universell besser, wählst du schlecht.
Diese Tools lösen unterschiedliche Probleme.
BMAD ist die richtige Wahl, wenn du eine Methode willst, die wie ein voll besetzter Engineering-Prozess denkt. Es ist am stärksten, wenn architektonische Korrektheit zählt, wenn du Adversarial Review schätzt und wenn du gern in einer Community lernst. Wenn du die meiste Hilfe beim Durchdenken von Komplexität willst, kommst du an BMAD kaum vorbei.
GSD ist die richtige Wahl, wenn dein Agent anfangs gut arbeitet und dann mitten im Feature zerfällt. Es sorgt gezielt für verlässlichen Kontext, indem es in einzelnen Phasen mit frischen Fenstern von 200K Tokens arbeitet, während die Haupt-Session bei 30 bis 40 % Auslastung bleibt. Das ermöglicht atomare Git-Commits und einen saubereren Ausführungsfluss, wie diese Aufschlüsselung des GSD-Workflows zeigt. Wenn du stark auf Claude Code setzt und ein schlankes System willst, das Kontextverfall direkt bekämpft, ist das hier die sauberste Antwort.
Tekk.coach ist die richtige Wahl, wenn dein Engpass darin liegt, zu wissen, was du bauen sollst. Du willst Loops, die deine Codebase lesen und die Spec schreiben. Du willst ein Board, auf dem ein Merge die Spec schließt. Und du willst dich nicht an einen einzigen Coding-Agent binden.
Ein einfacher Entscheidungsbaum
Fang hier an.
Willst du eine lebendige Community und eine Methode, die auf Planungstiefe drängt?
Nimm BMAD.Lebst du hauptsächlich in Claude Code und willst den leichtesten Workflow, der trotzdem Disziplin erzwingt?
Nimm GSD.Willst du Loops, die die Arbeit in deiner Codebase finden und die Spec schreiben, und wählst deinen Coding-Agent lieber selbst?
Nimm Tekk.coach.
Ein paar schärfere Faustregeln helfen.
- Nimm BMAD, wenn deine größte Angst ist, früh die falsche Systementscheidung zu treffen.
- Nimm GSD, wenn deine größte Angst ist, über lange KI-Coding-Sessions an Qualität zu verlieren.
- Nimm Tekk.coach, wenn deine größte Angst die Arbeit ist, die dir nie aufgefallen ist: die Lücke in der Auth, der Retry, der doppelt abbucht, der geänderte Code ohne Tests.
Es gibt keinen klaren Sieger, weil es nicht nur einen Job zu erledigen gibt.
Wenn du dir noch einen Überblick über den breiteren Markt verschaffst, helfen diese Begleitartikel:
- die Landschaft rund um Spec-driven Development
- der Vergleich Spec Kit vs. Tekk vs. ChatPRD
- der Vergleich Tekk vs. Traycer vs. OpenSpec
- der Entscheidungsbaum für Frameworks
Meine ehrliche Meinung: Die meisten Solo Builder scheitern nicht, weil ihnen noch ein Prompt-Template gefehlt hat. Sie scheitern, weil ihr Prozess an einer von drei Stellen bricht. Denken. Ausführen. Die Arbeit finden.
Wähl den Workflow, der den Bruch repariert, den du schon hast. Nicht den, der auf GitHub am klügsten aussieht.
Tekk.coach ist für das dritte Lager. Verbinde dein Repo. Die Loops starten bei deiner nächsten Änderung.
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.