Im vorigen Artikel haben wir BMAD vorgestellt — ein Framework, das aus chaotischem Vibe Coding einen strukturierten Entwicklungsprozess macht, indem es ein Ensemble aus sechs spezialisierten KI-Agenten orchestriert. Wer den Artikel gelesen hat, kennt Mary, John, Winston und ihr Team.
Eine Bemerkung am Ende dieses Artikels lohnt einen zweiten Blick: BMAD ist nicht die einzige Antwort. Spec Kit von GitHub geht denselben Weg — strukturierte, spezifikationsgetriebene Entwicklung mit KI — aber mit fundamental anderer Philosophie. Wer eine Entscheidung über die methodische Grundlage seiner KI-gestützten Softwareentwicklung trifft, sollte beide Optionen kennen.
Dieser Artikel erklärt Spec Kit, ordnet es im Markt ein und liefert eine Entscheidungsgrundlage für die Frage, die jeden technischen Entscheider gerade beschäftigt: Welches Framework passt zu meinem Team?
Warum GitHub ein Framework veröffentlicht
Bevor wir in die Mechanik einsteigen, lohnt eine Einordnung: Spec Kit ist kein typisches Community-Projekt, das GitHub nur hostet. Es ist ein Werkzeug, das GitHub selbst entwickelt hat — das Unternehmen, auf dessen Plattform ein erheblicher Teil der weltweiten Open-Source- und Enterprise-Entwicklung stattfindet und das damit aus erster Hand sieht, woran Projekte scheitern und woran sie erfolgreich werden.
Wenn GitHub ein Framework veröffentlicht, basiert das auf der Auswertung von Mustern, die sich über Millionen von Repositories hinweg zeigen. Spec Kit greift dabei eine Beobachtung auf, die im Software-Engineering seit Jahrzehnten anerkannt ist: Frühe Klarheit über Anforderungen reduziert nachgelagerte Korrekturkosten erheblich (Boehms Cost-of-Defect-Studien) — ein Zusammenhang, der durch KI-gestützte Implementierung nicht aufgehoben, sondern verschärft wird. Wo Code in Sekunden entsteht, kostet eine unklare Spezifikation entsprechend schneller.
Spec Kit formalisiert diese Erkenntnis. Es stellt die Spezifikation ins Zentrum des gesamten Entwicklungsprozesses — nicht als hübsches Dokument, das in einem Confluence-Wiki verstaubt, sondern als ausführbares, maschinenlesbares Artefakt, aus dem sich die Implementierung direkt ableiten lässt.
Constitution — Das Grundgesetz Ihres Projekts. Hier legen Sie die unverhandelbaren Prinzipien fest. "Sicherheit vor Features." "Barrierefreiheit ist nicht optional.” "Testbarkeit ist eine Architekturentscheidung." Diese Prinzipien wirken trivial, wenn man sie liest, sind aber für KI-Agenten Gold wert: Ein Agent, dem über den Kontext mitgegeben wird, Sicherheit zu priorisieren, entscheidet sich im Zweifel für die sichere Lösung — ohne dass man ihn jedes Mal daran erinnern muss.
Specification — Was, nicht Wie. Sie beschreiben, was das System tun soll und warum, aber bewusst nicht, wie es technisch umgesetzt wird. "Der Benutzer soll sich registrieren können" gehört in die Spec. "Per REST-API mit JWT-Token, gespeichert in PostgreSQL" gehört in den Plan. Diese Trennung ist entscheidend — sie hält die Spezifikation technologieagnostisch und damit langlebig.
Plan — Die technische Brücke. Hier treffen Sie die technischen Entscheidungen: Tech-Stack, Architektur, Schnittstellen, Abhängigkeiten. Jede Entscheidung wird mit Begründung dokumentiert — nicht nur was, sondern warum.
Tasks — Vom Plan zur Aktion. Der Plan wird in ausführbare Arbeitspakete zerlegt. Jeder Task hat Beschreibung, Akzeptanzkriterien, Abhängigkeiten und Referenzen auf die relevanten Stellen in Spec und Plan. Die Faustregel: Ein guter Task ist in einer einzigen KI-Session umsetzbar, ohne dass der Agent den Kontext verliert. Typischerweise eine bis vier Stunden Arbeit.
Implementation — Specs werden Code. Der Agent arbeitet die Tasks ab — in der durch Abhängigkeiten definierten Reihenfolge, jeden Task gegen seine Akzeptanzkriterien validiert. Hier zeigt sich der Unterschied zu unstrukturiertem Vibe Coding: Der Agent rät nicht, er führt aus. Fehler sind lokale technische Fehler, keine globalen architektonischen.
Spec Kit vs. BMAD: Zwei Wege, ein Ziel
Beide Frameworks lösen dasselbe Grundproblem — Struktur in KI-gestützte Entwicklung bringen — aber mit fundamental unterschiedlicher Philosophie.
BMAD fragt: "Wer baut das?" Es gibt jedem Schritt eine Persönlichkeit. Mary analysiert, John formalisiert, Winston entwirft, Amelia codet. Diese Personifizierung ist kein Marketing-Gag — sie ändert die Qualität der KI-Antworten, weil der gesamte Konversationskontext auf eine Rolle ausgerichtet wird.
Spec Kit fragt: "Was genau wird gebaut?" Es gibt jedem Schritt ein Artefakt. Die Constitution, die Spec, der Plan, die Tasks. Diese Artefakte sind die Steuerungsinstanz — nicht eine Persona, sondern ein Dokument.
Diese unterschiedliche Philosophie schlägt sich in jedem Detail nieder. BMAD hat einen Party Mode, in dem Winston, Mary und Sally gemeinsam eine Architekturentscheidung diskutieren. Spec Kit hat einen /speckit.analyze-Befehl, der die Konsistenz der Spezifikation prüft. Beide Werkzeuge erreichen Qualitätssicherung — auf grundverschiedene Weise.
Das Extension-Ökosystem: über 80 Erweiterungen
Eines der bemerkenswertesten Merkmale von Spec Kit ist sein Erweiterungssystem. Der offizielle Community-Katalog listet zum Zeitpunkt dieses Artikels über 80 Einträge — mit fast täglichen Neuzugängen. Die Extensions lassen sich in vier Kategorien einteilen:
Integrationen mit Projektmanagement-Tools. Jira, Azure DevOps, Linear. Tasks aus der Task-Breakdown-Phase werden als Tickets im jeweiligen Tool angelegt, mit allen Referenzen und Akzeptanzkriterien. Status-Änderungen synchronisieren. Teams, die ein etabliertes PM-Tool nutzen, müssen nicht migrieren.
Quality Gates. Automatisierte Prüfungen zwischen den Phasen. Bevor eine Spezifikation in die Planning-Phase übergeht, prüft ein Quality Gate beispielsweise, ob alle Features Akzeptanzkriterien haben und ob keine offenen Fragen markiert sind. Das verhindert ein in der Praxis häufiges Problem: unvollständige Spezifikationen, die ungeprüft in die technische Planung gelangen.
Multi-Agent-Orchestration. Für komplexere Projekte gibt es Extensions, die mehrere Agenten parallel an verschiedenen Tasks arbeiten lassen — etwa einen Agent am Frontend, einen am Backend. Die Orchestration-Extension stellt sicher, dass beide Agenten dieselbe Spezifikation als Referenz verwenden und ihre Ergebnisse kompatibel sind.
Reporting und Analytics. Wie viele Tasks sind abgeschlossen? Wie lange dauert die durchschnittliche Implementation-Phase? Welche Task-Arten erfordern am häufigsten Nacharbeit? Reporting-Extensions liefern diese Metriken und ermöglichen Prozessoptimierung.
Die Breite dieses Ökosystems zeigt eine bewusste Designentscheidung: Spec Kit ist als erweiterbarer Kern konzipiert, nicht als monolithisches System. Der Kern bleibt schlank und fokussiert auf das Wesentliche; die Community sorgt für die Integration in bestehende Workflows.
Tool-agnostisch by design
Ein häufiges Missverständnis: Spec Kit sei an GitHub Copilot gebunden, weil es von GitHub stammt. Das Gegenteil ist der Fall. Spec Kit funktioniert mit Claude Code, GitHub Copilot, Gemini, Cursor, Windsurf — praktisch jedem KI-Coding-Assistenten, der strukturierte Textdokumente als Kontext verwenden kann.
Diese Tool-Agnostik ist kein Zufall, sondern strategisch. GitHub hat verstanden: Die Toollandschaft der KI-gestützten Entwicklung verändert sich rasant. Was heute das führende Tool ist, kann morgen abgelöst werden. Ein Framework, das an ein bestimmtes Tool gebunden ist, wird mit diesem Tool obsolet. Spec Kit setzt deshalb auf Artefakte und Prozesse, die jeder Agent nutzen kann.
Für Entwickler bedeutet das: Sie können Spec Kit heute mit Claude Code verwenden und morgen zu Cursor wechseln, ohne Spezifikationen, Pläne und Tasks wegwerfen zu müssen. Die Investition in gute Specs ist toolunabhängig — und damit zukunftssicher.
Wann Spec Kit, wann BMAD?
Die ehrliche Antwort: Es gibt keine allgemeingültige Wahl. Aber es gibt klare Indikatoren.
Spec Kit eignet sich besonders für:
Multi-Entwickler-Teams mit unterschiedlichen KI-Tools im Einsatz. Die gemeinsame Spezifikation ist die Brücke zwischen verschiedenen Agenten und Werkzeugen.
Projekte mit etabliertem PM-Tool (Jira, Azure DevOps, Linear). Die Extensions integrieren nahtlos.
Agenturen und Dienstleister, die Inkonsistenzen zwischen Entwicklern eliminieren müssen — die Constitution sorgt für Einheitlichkeit, die Specs für nachvollziehbare Übergaben.
Teams, die schnell starten wollen. Installation und erstes Projekt in unter zehn Minuten.
BMAD eignet sich besonders für:
Stark BA-getriebene Projekte, in denen Anforderungen über mehrere Stakeholder-Iterationen entstehen. Marys explorative Fragen decken blinde Flecken auf, die ein Spec-Linter nicht erkennt.
Komplexe Produktentwicklung, bei der Architekturentscheidungen ausführlich diskutiert werden müssen. Party Mode bringt mehrere Perspektiven an einen Tisch.
Teams mit klar definierten Rollen, die KI-Agenten als Erweiterung ihrer Rollenstruktur verstehen. Die personifizierten Agenten passen sich natürlich in diese Struktur ein.
Beide eignen sich nicht für:
Bugfixes und mini Feature-Erweiterungen. Der Phasen-Overhead ist nicht gerechtfertigt.
Explorative Wegwerf-Prototypen, bei denen die Anforderungen so unklar sind, dass nicht einmal eine grobe Spec möglich wäre.
Einmal-Skripte und Hobby-Hackereien.
In diesen Fällen ist unstrukturiertes Vibe Coding der schnellere Weg — bis der Punkt erreicht ist, an dem Sie wissen, was Sie wirklich bauen wollen. Dann wird es Zeit für ein Framework.
Risiken und Grenzen — eine ehrliche Einordnung
Auch Spec Kit ist keine Silberkugel. Drei Punkte, die man kennen sollte:
Die Specification-Phase ist anspruchsvoller als sie aussieht. Features präzise zu beschreiben, ohne in technische Details abzudriften, ist eine Übung in Präzision und Abstraktion gleichzeitig. Teams, die das zum ersten Mal versuchen, brauchen mehrere Iterationen, bis ihre Specs den Sweet Spot zwischen "zu vage" und "zu detailliert" treffen.
Die Constitution wird gerne übersprungen. Es ist verlockend, direkt mit der Specification zu beginnen und die Constitution als bürokratisches Übel zu betrachten. Bei kleinen Projekten funktioniert das. Bei jedem Projekt mit nicht-trivialer Komplexität rächt es sich: Ohne Constitution trifft jeder Agent seine eigenen Grundsatzentscheidungen, und diese Entscheidungen werden nicht übereinstimmen.
Die Specs müssen leben. Wenn sich Anforderungen ändern, müssen die Specs aktualisiert werden, bevor der Code geändert wird. Wer den Code ändert und die Spec als "holen wir später nach" markiert, hat das Kernprinzip von SDD nicht verstanden. Das erfordert Disziplin — und ein Team, das diese Disziplin trägt.
Was das für technische Entscheider bedeutet
Wer KI-gestützte Entwicklung im Unternehmen einführt, steht vor einer Entscheidung, die strategischer ist, als sie zunächst wirkt: Die Wahl des Frameworks bestimmt nicht nur, wie Code entsteht, sondern auch, wer ihn versteht, wie er übergeben wird und wie das Team kommuniziert.
BMAD investiert mehr in Persönlichkeit und Rollenstruktur. Das passt gut zu Teams, in denen klare Verantwortlichkeiten gewünscht sind und in denen die KI als virtueller Kollege gedacht wird. Für stark BA-getriebene Organisationen ist BMAD oft der natürlichere Fit.
Spec Kit investiert mehr in Schlankheit und Tool-Unabhängigkeit. Das passt zu Teams, die schnell starten wollen, die unterschiedliche KI-Werkzeuge parallel einsetzen oder die starke bestehende Prozesse haben, in die sich SDD einbetten soll. Für Multi-Entwickler-Teams in Agenturen ist Spec Kit oft die robustere Wahl.
Die Wahrheit ist: Beide Frameworks lösen dasselbe Problem — und wer eines davon konsequent einführt, wird die Vorteile von SDD ernten. Die wichtigere Entscheidung ist nicht welches Framework, sondern ob Sie überhaupt eines einsetzen. Denn unstrukturiertes Vibe Coding skaliert nicht. Auf den ersten Sprint mag es schneller wirken — auf den dritten ist es teurer als jeder strukturierte Ansatz.
Wer Spec Kit oder BMAD evaluieren möchte, sollte beide einmal einen Tag lang ausprobieren — an einem realen, klar abgegrenzten Feature. Nach diesem Tag werden Sie wissen, welches Framework zur Denkweise Ihres Teams passt. Diese Information ist wertvoller als jeder Vergleichsartikel.
Fazit: Die Spec ist die Zukunft, das Framework ist die Wahl
GitHub hat mit Spec Kit nicht das Rad neu erfunden. Es hat bestehendes Wissen über gute Softwareentwicklung für die Ära der KI-gestützten Entwicklung formalisiert: Spezifikationen als zentrales Artefakt, Trennung von Was und Wie, phasenweise Verfeinerung. Diese Prinzipien sind alt — aber sie werden durch KI plötzlich operationalisierbar.
In einer Welt, in der Code in Sekunden entsteht, ist die Fähigkeit, präzise zu spezifizieren, wertvoller als die Fähigkeit, schnell zu implementieren. Das ist die eigentliche Revolution von Vibe Coding: Nicht dass Maschinen Code schreiben können, sondern dass die Fähigkeit, klar zu denken und präzise zu formulieren, zum wichtigsten Skill des Softwareentwicklers wird.
BMAD und Spec Kit sind zwei Antworten auf dieselbe Frage. Welche zu Ihnen passt, hängt davon ab, wie Sie über Software, Teams und Werkzeuge denken. Aber dass Sie eine Antwort brauchen, steht außer Frage.
