Die Spec legt fest, dass die Zahlungsabwicklung synchron erfolgen soll. Sie wurde geprüft, gemergt und archiviert, alles nach dem vorgesehenen Prozess. Zwei Releases später fragt jemand, warum diese Entscheidung gefallen ist. Die Spec enthält keine Begründung, und auch ihr Autor kann die damalige Abwägung nicht mehr rekonstruieren. Dass gerade er die Spec geschrieben hatte, war Zufall: Er hatte den Workflow angestoßen und die Datei ohnehin gerade bearbeitet.
Tool-Einstellungen allein klären weder die Zuständigkeit noch bewahren sie die Begründung einer Entscheidung. Sobald mehrere Personen an denselben Specs arbeiten, braucht es einen gemeinsamen Prozess.
Was Spec-Driven Development ist und wann sich der Aufwand lohnt, erklärt ein separater Beitrag. Hier geht es um den nächsten Schritt: Wer verantwortet die Spec? Wie wird die Prüfung der Spec zu einer verbindlichen Freigabe? Und wie bleibt die Begründung einer Entscheidung lange nach dem Merge nachvollziehbar? Wie dieses Betriebsmodell in eine übergeordnete Strategie für Coding Agents passt, zeigt das Team-Kapitel des Coding-Agents-Leitfadens.
Wer die Spec schreibt, muss das Team bewusst entscheiden
Birgitta Böckeler weist in ihrer Analyse von drei SDD-Tools auf einen Punkt hin, der in der Debatte häufig untergeht: Die Verfahren setzen stillschweigend voraus, dass Entwickler Aufgaben der Anforderungsanalyse übernehmen, für die traditionell das Produktmanagement oder der Fachbereich verantwortlich ist. Keines der Tools benennt diese Rollenverschiebung ausdrücklich.
Diese Beobachtung beruht auf der Analyse von drei Tools, nicht auf einer Erhebung in Entwicklungsteams. In allen drei Workflows übernehmen Entwickler einen erheblichen Teil der Anforderungsanalyse. Bei Spec Kit zeigt sich diese Rollenverschiebung etwa beim Befehl /speckit.specify: Wer ihn ausführt, startet die Erstellung der Spec und muss die fachlichen Annahmen entweder selbst formulieren oder mit dem Produktmanagement klären. Die ausgewerteten Quellen beschreiben vor allem die in den Tools vorgesehenen Abläufe und einzelne fachliche Einschätzungen. Sie zeigen nicht, wie Teams Rollen tatsächlich verteilen oder welches Modell produktiver ist.
Böckeler legt keine eindeutige Rollenverteilung fest. Als mögliche Antwort nennt sie Cross-Skilling, also den gezielten Aufbau fachübergreifender Kompetenzen. Entwickler könnten dadurch stärker an der Anforderungsanalyse beteiligt werden. Zugleich bezweifelt sie, dass dieses Modell bei großen, noch unklaren Features ausreicht, die fundierte Produkt- und Anforderungsarbeit erfordern.
Zwei Modelle sind beispielsweise denkbar. Im ersten übernimmt das Entwicklungsteam bewusst mehr Anforderungsarbeit und wird dafür entsprechend qualifiziert. Im zweiten verantwortet der Product Owner den fachlichen und das Entwicklungsteam den technischen Teil der Spec. Welches Modell passt, hängt davon ab, wie klar die Anforderungen sind, wie hoch das technische Risiko ist und welche Kompetenzen im Team vorhanden sind. Bleibt die Zuständigkeit ungeklärt, entscheidet am Ende die Gewohnheit.
Die Spec gehört ins Repository, nicht auf einen einzelnen Laptop
Sobald mehrere Personen an einer Spec arbeiten, zählt nicht nur ihr Inhalt. Ebenso wichtig ist, wo sie liegt und wer darauf zugreifen kann. Eine Spec auf einem einzelnen Laptop ist kaum mehr als eine persönliche Notiz. Liegt die Spec versioniert im Repository und ist sie im Pull Request sichtbar, kann sie zur gemeinsamen Arbeitsgrundlage werden. Ein Commit allein reicht dafür nicht. Erst verbindliche Reviews und laufende Pflege machen sie zu einem verlässlichen Teamartefakt.
Kiro und Spec Kit sehen die Ablage im Repository und Reviews durch das Team ausdrücklich vor. Kiro, eine SDD-Entwicklungsumgebung von AWS, speichert dauerhafte Vorgaben zu Produkt, Technik und Projektstruktur als sogenannte Steering-Dateien direkt in der Codebasis. Die Dokumentation verlangt, Änderungen an Steering-Dateien wie Codeänderungen zu prüfen.
Unter .kiro/specs/<feature>/ liegen die Feature-Spezifikationen, die gemeinsam mit dem zugehörigen Code versioniert werden.
Auch Spec Kit beschreibt einen Teamprozess, in dem gemeinsam geprüfte Spezifikationen formuliert und versioniert werden. Diese Quellen beschreiben vorgesehene Abläufe, nicht deren tatsächliche Verbreitung in Teams.
Specs, die in mehreren Repositories genutzt werden, kann ein Team in einem zentralen Spec-Repository verwalten und per Git-Submodul oder Paket einbinden (Stand: Juli 2026).
Nutzt ein Team mehrere dieser Wege ohne klare Abgrenzung und Priorität, lässt sich kaum noch nachvollziehen, welche Vorgabe aus welcher Quelle stammt. Ein zentrales Spec-Repository braucht außerdem ein klar verantwortliches Team, ein eindeutiges Versionsschema und einen definierten Freigabeprozess. Andernfalls wird es selbst zum Engpass.
Wie diese Artefakte entstehen und welchen Lebenszyklus eine Spezifikation in den einzelnen Tools hat, zeigt der Vergleich von GitHub Spec Kit und OpenSpec anhand derselben Änderung in einem bestehenden System.
Freigabe braucht ein nachprüfbares Kriterium
Dass Spec-Driven Development die Prüfung vor die Codegenerierung zieht und das Code-Review nicht ersetzt, sondern ihm einen früheren Schritt voranstellt, ist der Kern des Grundlagenartikels. Für den Teamprozess ist die nächste Frage entscheidend: Wann gilt eine Spec, die dieses frühe Review durchlaufen hat, als freigegeben?
Ein solches Review-Gate braucht ein ausdrückliches Freigabekriterium, sonst bleibt „geprüft“ Auslegungssache. Eine Spec kann etwa als freigegeben gelten, wenn die fachlich und technisch Verantwortlichen zugestimmt haben, keine blockierenden Kommentare offen sind und die Freigabe im Repository dokumentiert ist.
Das Kriterium beantwortet, wann das Gate bestanden ist. Es sagt noch nicht, welche Änderungen das Gate durchlaufen müssen. Dafür braucht es eine separate, risikobasierte Regel. Bei kleinen, leicht rückgängig zu machenden Änderungen kann der zusätzliche Prüfschritt mehr Aufwand als Nutzen erzeugen. Deshalb sollte das Gate nach dem Risiko der Änderung gestaffelt und zunächst in einem Pilotprojekt geprüft werden. Die Zeit bis zum Review, spätere Planänderungen und der Umfang der Nacharbeit liefern dafür Hinweise, belegen aber keinen eindeutigen Wirkungszusammenhang.
Die einzelne Spec und die Constitution mit den projektweiten Regeln bestehen aus Text, den eine KI interpretiert. Böckeler weist darauf hin, dass sich die Einhaltung solcher Anweisungen nicht vollständig garantieren lässt. Die Dokumente selbst erzwingen das Review-Gate also nicht. Ohne zusätzliche technische Kontrollen im Workflow bleibt das Gate eine Teamkonvention.
Eine Kontroll- und Ausführungsschicht um den Agenten, oft Harness genannt, kann diese Lücke teilweise schließen. Berechtigungen können den Zugriff begrenzen. Hooks können Prüfungen an festen Punkten im Ablauf verankern. Auch diese Kontrollen müssen korrekt konfiguriert und getestet werden. Wie eine solche Schicht aufgebaut ist, erklärt der Beitrag zum Context Engineering für Coding Agents.
Entscheidungsgründe müssen die Änderung überleben
Zurück zum Beispiel der synchronen Zahlungsabwicklung. Eine Spec beschreibt, was umgesetzt werden soll und welche Akzeptanzkriterien gelten. Die Gründe für eine Entscheidung können dagegen in einem Designdokument stehen, das nach Abschluss der Änderung im Archiv verschwindet. Ob diese Begründung später auffindbar bleibt, hängt davon ab, wie das Team sie strukturiert, prüft und ablegt.
Böckeler beschreibt dieselbe Lücke in den untersuchten Tools. Sinngemäß lautet ihre Beobachtung: Bei allen drei Verfahren bleibt offen, wie Specs langfristig gepflegt werden sollen. Ihre Analyse stammt vom Oktober 2025, und die Tools entwickeln sich schnell weiter. Die Tools beschreiben technische Wege, um Specs zu aktualisieren oder zu archivieren. Häufig bleibt jedoch offen, wer im Team die langfristige Pflege verantwortet und nach welchen Regeln eine Spec aktualisiert, ersetzt oder stillgelegt wird.
Eine bewährte Lösung ist deutlich älter als der aktuelle Boom um Coding Agents. Michael Nygard beschrieb das Konzept der Architecture Decision Records (ADR) am 15. November 2011. Seine Ausgangsbeobachtung passt genau zum Beispiel am Anfang: „One of the hardest things to track during the life of a project is the motivation behind certain decisions.“
Das Format ist bewusst einfach gehalten. Jede relevante Architekturentscheidung erhält eine kurze, fortlaufend nummerierte Markdown-Datei im Repository. Sie enthält Titel, Kontext, Entscheidung, Status und Konsequenzen. Revidiert das Team eine Entscheidung, markiert es den bisherigen Eintrag als ersetzt (superseded), statt ihn zu löschen. So bleiben der aktuelle Stand und der Weg dorthin nachvollziehbar. Nygard empfiehlt einen direkten Ton: Man schreibt, als erkläre man die Entscheidung einem künftigen Teammitglied.
Eine mögliche Teamkonvention lautet: Die Spec hält Ziel, erwartetes Verhalten und Prüfkriterien fest. Dauerhafte Architekturentscheidungen und ihre Begründung stehen im ADR. Tool-spezifische Plan-, Research- oder Designdokumente können weitere Abwägungen enthalten. Diese Trennung ist eine Konvention, keine feste Vorgabe der Formate. Entscheidend ist, dass dauerhafte Entscheidungen auffindbar bleiben, mit der betroffenen Spec verlinkt sind und ihren Status erkennen lassen: vorgeschlagen, angenommen oder ersetzt.
Ein von Hari Krishnan für OpenSpec beschriebenes Schema zeigt beispielhaft, wie sich Specs und ADRs verlinken lassen. Die Trennung von aktueller Spec und archivierten Änderungsartefakten behandelt der Toolvergleich.
Ohne klare Zuständigkeit und regelmäßige Pflege sammeln sich leicht Dutzende Einträge an, die einander widersprechen und deren aktueller Status unklar ist. Die Merge-Checkliste sollte deshalb zwei Fragen enthalten: Braucht diese Entscheidung einen ADR? Sind die betroffenen ADRs noch gültig oder bereits ersetzt? Meine Faustregel: Braucht die Antwort auf „Warum haben wir uns dafür entschieden?“ mehr als zwei Sätze, gehört die Begründung in einen ADR.
Vier Regeln für den nächsten Pull Request
Für den Einstieg genügt ein gemeinsamer Termin der fachlich und technisch Verantwortlichen vor dem nächsten größeren Feature. Danach sollte das PR-Template vier Fragen beantworten:
- Wer verantwortet die Spec?
- Wer muss zustimmen, und wann gilt sie als freigegeben?
- Wann wird sie aktualisiert oder ersetzt?
- Wann braucht eine Entscheidung einen ADR?
Das reicht als Ausgangspunkt für ein Pilotprojekt. Wie Teams aus einem einzelnen Tool einen verlässlichen Teamprozess machen, behandeln die Inhouse-Workshops zu Coding Agents.
Quellen
- Birgitta Böckeler: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl, martinfowler.com, 15. Oktober 2025
- Michael Nygard: Documenting Architecture Decisions, cognitect.com, 15. November 2011
- GitHub Spec Kit: spec-driven.md, GitHub-Repository, Stand Juli 2026
- GitHub Spec Kit: Dokumentation, github.github.io/spec-kit (Stand: Juli 2026)
- Kiro Docs: Steering, kiro.dev (Stand: Juli 2026)
- Kiro Docs: Specs Best Practices, kiro.dev (Stand: Juli 2026)
- Hari Krishnan: Architectural Decision Records with Spec-Driven Development using OpenSpec, intent-driven.dev, 29. April 2026
