- Spec-Driven Development (SDD) ist beim KI-gestützten Coding ein Ansatz, bei dem vor dem Schreiben von Code zuerst eine Spezifikation (
spec) verfasst wird; diese Spezifikation dient als Source of Truth für Entwickler und KI
- SDD wird in drei Implementierungsstufen unterteilt und entwickelt sich schrittweise von spec-first (Spezifikation zuerst), über spec-anchored (Spezifikation zur Wartung beibehalten) bis zu spec-as-source (Spezifikation als zentrale Quelldatei, Entwickler bearbeiten den Code nicht direkt)
- Kiro bietet einen einfachen 3-Schritte-Workflow aus Anforderungen → Design → Aufgaben, spec-kit nutzt einen stark regelbasierten Workflow mit einer Constitution, und Tessl experimentiert mit einem spec-as-source-Ansatz, bei dem Spezifikation und Code 1:1 abgebildet werden
- Alle drei Tools verlangen selbst für kleine Bugfixes einen übermäßigen Prozess, Reviews von Markdown-Dateien sind mühsamer als Code-Reviews, und trotz großer Kontextfenster stößt die KI an Grenzen, weil sie Anweisungen nicht immer zuverlässig befolgt
- SDD ruft die Fehlschläge früherer Model-Driven Development (MDD)-Ansätze in Erinnerung und birgt das Risiko, die Nachteile beider Seiten zu vereinen: Nichtdeterminismus und mangelnde Flexibilität; deshalb muss der praktische Nutzen in realen Projekten erst noch belegt werden
Definition von Spec-Driven Development (SDD)
- SDD ist ein „Documentation-first“-Ansatz, bei dem vor dem Schreiben von Code zuerst eine Spezifikation erstellt wird; sie fungiert für Entwickler und KI als Single Source of Truth
- GitHub definiert es so: „Software-Wartung bedeutet die Weiterentwicklung der Spezifikation, die gemeinsame Sprache der Entwicklung wandert auf eine höhere Ebene, und Code ist der letzte Schritt des Prozesses“
- Tessl beschreibt es als „einen Entwicklungsansatz, bei dem die Spezifikation statt des Codes zum primären Artefakt wird; sie beschreibt die Absicht in strukturierter, testbarer Sprache, und Agenten erzeugen darauf abgestimmt Code“
- SDD lässt sich in drei Implementierungsstufen einteilen
- Spec-first: Zuerst wird eine gut strukturierte Spezifikation erstellt und dann im KI-gestützten Entwicklungs-Workflow verwendet
- Spec-anchored: Die Spezifikation bleibt auch nach Abschluss der Arbeit erhalten und wird weiter für Entwicklung und Wartung der betreffenden Funktion genutzt
- Spec-as-source: Die Spezifikation bleibt dauerhaft die primäre Quelldatei; Entwickler bearbeiten nur die Spezifikation und fassen den Code nicht direkt an
- Alle SDD-Ansätze sind spec-first, aber nicht alle zielen auf spec-anchored oder spec-as-source ab; oft bleibt unklar, wie Spezifikationen im Zeitverlauf gepflegt werden sollen oder dies bleibt völlig offen
Was ist eine Spezifikation (spec)?
- Eine Spezifikation ist ein in natürlicher Sprache verfasstes, strukturiertes und verhaltensorientiertes Artefakt, das eine Software-Funktion beschreibt und KI-Coding-Agenten als Leitfaden dient
- Die konsistenteste Definition vergleicht eine Spezifikation mit einem Product Requirements Document (PRD)
- Spezifikationen sollten von allgemeinen Kontextdokumenten für eine Codebasis unterschieden werden
- Allgemeiner Kontext umfasst Regeldateien sowie Beschreibungen des Produkts und der Codebasis auf hoher Ebene; einige Tools nennen das eine Memory Bank
- Dateien der Memory Bank sind in allen KI-Coding-Sitzungen für die Codebasis relevant, während Spezifikationen nur für Aufgaben relevant sind, bei denen eine bestimmte Funktion erstellt oder geändert wird
- Jede SDD-Variante definiert ihren eigenen Ansatz für Struktur, Detailgrad und Organisation von Spezifikationen innerhalb eines Projekts
Warum SDD-Tools schwer zu bewerten sind
- SDD-Tools und -Ansätze nah an der realen Nutzung zu bewerten ist extrem zeitaufwendig
- Man muss sie an Problemen unterschiedlicher Größe sowie in Greenfield- und Brownfield-Projekten ausprobieren und außerdem Zeit investieren, Zwischenergebnisse gründlich statt nur oberflächlich zu prüfen und zu korrigieren
- Im Blogpost zu GitHubs spec-kit wird betont: Wichtig ist, dass deine Rolle nicht nur darin besteht, Richtung vorzugeben, sondern auch zu validieren und in jedem Schritt zu reflektieren und zu verbessern
- Zwei der drei Tools scheinen mehr Aufwand bei der Einführung in bestehende Codebasen zu erfordern, was die Bewertung ihres Nutzens in Brownfield-Codebasen zusätzlich erschwert
- Bis Erfahrungsberichte von Personen vorliegen, die sie über längere Zeit in realen Codebasen genutzt haben, bleiben viele Fragen zur tatsächlichen Funktionsweise offen
Kiro
- Kiro ist von den drei Tools das einfachste und leichtgewichtigste und fällt überwiegend in die Kategorie spec-first
- Es wurden nur Beispiele für Aufgaben oder User Stories gefunden; Hinweise darauf, wie Anforderungsdokumente über mehrere Aufgaben hinweg spec-anchored genutzt werden könnten, gibt es nicht
- Workflow: Anforderungen → Design → Aufgaben
- Jede Workflow-Stufe wird durch ein Markdown-Dokument dargestellt, und Kiro führt in seiner auf VS Code basierenden Distribution durch diese drei Schritte
-
Zentrale Bestandteile von Kiro
- Anforderungen (Requirements)
- Strukturiert als Liste von Anforderungen, bei der jede Anforderung eine „User Story“ im Format „As a...“ darstellt
- Akzeptanzkriterien verwenden das Format GIVEN... WHEN... THEN...
- Design
- Enthält Abschnitte wie Komponentendiagramm der Architektur, Datenfluss, Datenmodell, Fehlerbehandlung, Teststrategie, Implementierungsansatz und Migrationsstrategie
- Es ist unklar, ob diese Struktur konsistent bleibt oder sich je nach Aufgabe ändert
- Aufgaben (Tasks)
- Aufgabenliste, die über Anforderungsnummern nachverfolgt wird
- Bietet zusätzliche UI-Elemente, um Aufgaben einzeln auszuführen und Änderungen pro Aufgabe zu prüfen
-
Kiros Memory Bank
- Kiro nennt das Konzept einer Memory Bank „steering“
- Der Inhalt ist flexibel, und der Workflow scheint nicht von der Existenz bestimmter Dateien abzuhängen
- Wenn Kiro gebeten wird, Steering-Dokumente zu erzeugen, erstellt es standardmäßig die Grundstruktur
product.md, structure.md, tech.md
Spec-kit
- spec-kit ist GitHubs Version von SDD und wird als CLI ausgeliefert, das Workspace-Setups für verschiedene allgemeine Coding-Assistenten erzeugen kann
- Nach dem Einrichten der Struktur interagiert man mit spec-kit über Slash-Commands des Coding-Assistenten
- Weil alle Artefakte direkt im Workspace abgelegt werden, ist es von den drei besprochenen Tools am stärksten anpassbar
-
Der Workflow von spec-kit
- Workflow: Constitution → 𝄆 Specify → Plan → Tasks 𝄇
- Das Memory-Bank-Konzept von spec-kit ist Voraussetzung für den spec-driven Ansatz
- Es wird Constitution genannt und enthält „unveränderliche“ übergeordnete Prinzipien, die bei allen Änderungen immer gelten sollen
- Eine sehr mächtige Regeldatei, die im Workflow stark genutzt wird
-
Funktionsweise von spec-kit
- In jeder Workflow-Stufe (
specify, plan, tasks) werden Bash-Skripte und Templates verwendet, um Dateien und Prompt-Sets zu instanziieren
- Der Workflow nutzt intensiv Checklisten in Dateien, um notwendige Klärungen durch den Nutzer, Verstöße gegen die Constitution, Rechercheaufgaben usw. zu verfolgen
- Das funktioniert wie eine „Definition of Done“ für jede Workflow-Stufe (da die KI sie interpretiert, ist das natürlich nicht zu 100 % garantiert)
- Eine Spezifikation besteht aus mehreren Dateien
- Beispiel: acht Dateien wie
data-model, plan, tasks, spec, research, api, component usw.
-
Der Ansatz von spec-kit
- GitHub scheint zunächst einen spec-anchored-Ansatz anzustreben
- „Wir denken Spezifikationen nicht als statische Dokumente, sondern als lebendige, ausführbare Artefakte, die sich mit dem Projekt weiterentwickeln; die Spezifikation wird zur gemeinsamen Source of Truth“
- Da spec-kit jedoch für jede erzeugte Spezifikation einen Branch erstellt, lässt sich das auch so interpretieren, dass Spezifikationen nur während der Lebensdauer einer Change Request lebendige Artefakte sind, nicht während der gesamten Lebensdauer einer Funktion
- Diese Verwirrung wird auch in Community-Diskussionen thematisiert; derzeit wirkt es so, als gehöre spec-kit weiterhin nur zu spec-first und nicht dauerhaft zu spec-anchored
Tessl Framework
- Das Tessl Framework befindet sich in einer geschlossenen Beta-Phase und wird wie spec-kit als CLI ausgeliefert, das Workspace- und Konfigurationsstrukturen für verschiedene Coding-Assistenten erzeugen kann
- Die CLI-Befehle fungieren auch als MCP-Server
-
Besonderheiten von Tessl
- Unter den drei Tools ist es das einzige, das explizit einen spec-anchored-Ansatz verfolgt und zusätzlich SDD auf spec-as-source-Niveau untersucht
- Tessl-Spezifikationen können das primäre Artefakt sein, das gepflegt und bearbeitet wird; Code wird dabei oben mit dem Kommentar
// GENERATED FROM SPEC - DO NOT EDIT markiert
- Aktuell gibt es eine 1:1-Abbildung zwischen Spezifikation und Code-Datei; eine Spezifikation wird also in genau eine Datei der Codebasis übersetzt
- Da das System noch in der Beta ist und verschiedene Varianten ausprobiert, könnte sich das zu einer Ebene weiterentwickeln, auf der eine Spezifikation einem Code-Baustein mit mehreren Dateien entspricht
-
Struktur der Tessl-Spezifikation
- Tags wie
@generate oder @test weisen Tessl an, was erzeugt werden soll
- Ein API-Abschnitt zeigt die Idee, in der Spezifikation die minimale Schnittstelle zu definieren, die anderen Teilen der Codebasis offengelegt wird, und stellt sicher, dass wichtige Teile der erzeugten Komponente vollständig unter Kontrolle der Maintainer bleiben
- Führt man
tessl build aus, wird die entsprechende JavaScript-Code-Datei erzeugt
-
Tessls Abstraktionsniveau
- Wenn Spezifikationen für spec-as-source auf einem ziemlich niedrigen Abstraktionsniveau pro Code-Datei angesiedelt sind, sinken Zahl der Schritte und der Interpretationsspielraum für das LLM — und damit auch die Fehlerwahrscheinlichkeit
- Selbst auf diesem niedrigen Abstraktionsniveau wurde jedoch Nichtdeterminismus beobachtet, wenn aus derselben Spezifikation mehrfach Code erzeugt wurde
- Der Prozess, Spezifikationen immer wieder zu überarbeiten und präziser zu machen, um die Reproduzierbarkeit der Code-Generierung zu erhöhen, erinnert an die Fallstricke und Herausforderungen beim Schreiben eindeutiger und vollständiger Spezifikationen
Beobachtungen und Fragen
-
Kann ein einzelner Workflow jede Größenordnung abdecken?
- Kiro und spec-kit bieten jeweils einen recht dogmatischen Workflow, der sich für viele reale Coding-Probleme als ungeeignet erweisen könnte
- Es ist unklar, ob sie genug Vielfalt für unterschiedliche Problemgrößen bieten
- Als versucht wurde, mit Kiro einen kleinen Bug zu beheben, wirkte der Workflow wie mit Kanonen auf Spatzen schießen
- Das Anforderungsdokument verwandelte den kleinen Bug in vier „User Stories“ mit insgesamt 16 Akzeptanzkriterien
- Auch bei spec-kit bleibt unklar, für welche Problemgröße es gedacht ist
- Bei einer Funktion, die in einem früheren Team vielleicht eine Story mit 3–5 Punkten gewesen wäre, wirkten die Anzahl der Schritte und die Menge an erzeugten Markdown-Dateien im Verhältnis zum Problem überzogen
- In derselben Zeit hätte man die Funktion vermutlich auch mit „normalem“ KI-gestütztem Coding implementieren können — mit deutlich mehr Kontrolle
- Ein wirksames SDD-Tool müsste zumindest mehrere unterschiedliche Kern-Workflows für Änderungen verschiedener Größen und Typen ermöglichen
-
Markdown-Review statt Code-Review?
- spec-kit erzeugt viele Markdown-Dateien, die überprüft werden müssen
- Sie wiederholen sich gegenseitig und auch bereits vorhandenen Code
- Manche enthalten schon selbst Code und sind dadurch insgesamt sehr wortreich und mühsam zu prüfen
- Bei Kiro gibt es nur drei Dateien, und das mentale Modell „Anforderungen > Design > Aufgaben“ ist intuitiver zu verstehen, weshalb es etwas leichter fällt
- Trotzdem ist auch Kiro für den angefragten kleinen Bugfix viel zu ausführlich
- Ehrlich gesagt drängt sich der Eindruck auf, dass Code zu reviewen besser ist als all diese Markdown-Dateien
- Ein gutes SDD-Tool müsste eine sehr gute Spezifikations-Review-Erfahrung bieten
-
Trügerisches Gefühl von Kontrolle?
- Trotz all dieser Dateien, Templates, Prompts, Workflows und Checklisten ist immer wieder zu beobachten, dass Agenten am Ende doch nicht alle Anweisungen befolgen
- Größere Kontextfenster werden zwar als ein Enabler von SDD genannt, aber ein größeres Fenster bedeutet nicht automatisch, dass die KI wirklich alles darin korrekt erfasst
- Beispiele
- spec-kit hatte während der Planung eine Recherchephase und untersuchte den bestehenden Code umfassend; am Ende ignorierte der Agent jedoch, dass es sich um die Beschreibung einer existierenden Klasse handelte, behandelte sie als neue Spezifikation und erzeugte alles doppelt neu
- Es gab nicht nur Fälle ignorierter Anweisungen, sondern auch Agenten, die Anweisungen zu eifrig befolgten und dadurch über das Ziel hinausschossen, etwa bei einer Klausel der Constitution
- Aus früherer Erfahrung waren kleine, iterative Schritte die beste Methode, Kontrolle über das Gebaute zu behalten; deshalb gibt es große Skepsis, ob umfangreiche Spezifikationsarbeit im Vorfeld wirklich sinnvoll ist
- Ein wirksames SDD-Tool müsste einen iterativen Ansatz unterstützen — aber kleine Arbeitspakete scheinen der Grundidee von SDD beinahe zu widersprechen
-
Wie trennt man funktionale und technische Spezifikationen sinnvoll?
- In SDD ist die bewusste Trennung zwischen funktionaler Spezifikation und technischer Implementierung eine verbreitete Idee
- Die grundlegende Hoffnung dahinter ist, dass die KI irgendwann alle Lösungen und Details ausfüllt und man mit derselben Spezifikation sogar zwischen verschiedenen Tech-Stacks wechseln könnte
- In der Praxis war bei Versuchen mit spec-kit jedoch oft unklar, wann man auf funktionaler Ebene bleiben und wann man technische Details hinzufügen sollte
- Auch Tutorials und Dokumentation waren darin nicht konsistent; es gibt unterschiedliche Interpretationen davon, was „rein funktional“ eigentlich bedeutet
- Wenn man an die vielen User Stories denkt, die Anforderungen und Implementierung nicht sauber trennen, ist die Bilanz des Berufsstands in dieser Disziplin insgesamt nicht gerade überzeugend
-
Wer ist die Zielgruppe?
- Viele Demos und Tutorials zu spec-driven Entwicklungs-Tools enthalten Dinge wie die Definition von Produkt- und Funktionszielen und verwenden Begriffe wie „User Story“
- Die Idee könnte sein, KI als Enabler für Cross-Skilling zu nutzen, damit Entwickler stärker an der Anforderungsanalyse teilnehmen
- Oder dass Entwickler in diesem Workflow gemeinsam mit Product-Verantwortlichen arbeiten?
- Nichts davon wird explizit erklärt; stattdessen wird so getan, als sei es selbstverständlich, dass Entwickler all diese Analyse selbst übernehmen
- Damit stellt sich die Frage: Für welche Problemgrößen und Problemtypen ist SDD gedacht?
- Für große Features, die noch sehr unklar sind, eignet es sich vermutlich eher nicht; dort braucht es sicher deutlich mehr spezialisierte Produkt- und Anforderungsarbeit sowie Recherche und Stakeholder-Einbindung
-
Spec-anchored und spec-as-source: Lernen wir aus der Vergangenheit?
- Viele ziehen Parallelen zwischen SDD und TDD oder BDD, doch besonders bei spec-as-source gibt es noch eine andere wichtige Analogie: MDD (Model-Driven Development)
- Zu Beginn der Karriere wurde in einigen Projekten intensiv mit MDD gearbeitet, und beim Ausprobieren des Tessl Frameworks drängte sich diese Erinnerung ständig auf
- Die Modelle in MDD waren im Grunde Spezifikationen, allerdings nicht in natürlicher Sprache, sondern in angepasstem UML oder textuellen DSLs ausgedrückt
- Um diese Spezifikationen in Code umzusetzen, wurden maßgeschneiderte Codegeneratoren gebaut
-
Vergleich von MDD und SDD
- Letztlich war MDD bei Business-Anwendungen nicht erfolgreich, weil es auf einem ungünstigen Abstraktionsniveau lag und zu viel Overhead sowie zu viele Einschränkungen erzeugte
- LLMs beseitigen jedoch einen Teil dieses Overheads und dieser Einschränkungen, sodass nun neue Hoffnung besteht, sich auf das Schreiben der Spezifikation zu konzentrieren und den Code generieren zu lassen
- Mit LLMs ist man nicht mehr auf eine vordefinierte, maschinenlesbare Spezifikationssprache festgelegt und muss auch keine ausgefeilten Codegeneratoren entwickeln
- Der Preis dafür ist natürlich der Nichtdeterminismus von LLMs
- Maschinell parsbare Strukturen hatten allerdings den Vorteil, dass sie Autoren von Spezifikationen viele Werkzeuge an die Hand geben konnten, um valide, vollständige und konsistente Spezifikationen zu erstellen — und genau diesen Vorteil verliert man nun
- spec-as-source und sogar spec-anchoring könnten am Ende die Nachteile von MDD und LLMs zugleich vereinen: mangelnde Flexibilität und Nichtdeterminismus
- Deshalb sollte man frühere Versuche von spec-from-code genauer betrachten und daraus lernen, wenn man heute spec-driven Ansätze untersucht
Fazit
- Persönlich wird beim Einsatz von KI-gestütztem Coding oft bereits viel Zeit investiert, um die Form der Spezifikation für Coding-Agenten sorgfältig zu formulieren
- Deshalb hat das allgemeine Prinzip von spec-first in vielen Situationen durchaus einen klaren Wert
- Unterschiedliche Ansätze zur Strukturierung von Spezifikationen werden dringend gebraucht und gehören aktuell zu den häufigsten Fragen aus der Praxis
- „Wie strukturiert man eine Memory Bank?“, „Wie schreibt man gute Spezifikations- und Design-Dokumente für KI?“
- Der Begriff „spec-driven development“ ist jedoch noch nicht sauber definiert und verwässert semantisch bereits
- Inzwischen hört man sogar, dass „spec“ im Grunde als Synonym für „detaillierter Prompt“ verwendet wird
-
Bewertung der Tools
- Einige versuchen, bestehende Workflows zu wörtlich für KI-Agenten abzubilden, und verstärken dadurch am Ende möglicherweise bekannte Probleme wie Review-Overload und Halluzinationen
- Besonders bei ausgefeilteren Ansätzen mit vielen erzeugten Dateien drängt sich das deutsche Kompositum „Verschlimmbesserung“ auf
- Also die Frage, ob der Versuch, etwas besser zu machen, es am Ende nicht sogar schlechter macht
3 Kommentare
Das wirkt ähnlich wie frühere Diskussionen über document driven development oder readme driven development.
https://de.news.hada.io/topic?id=15502
Hacker-News-Kommentare
Ich beobachte seit Kurzem den Trend zu SDD (Specification-Driven Development). Diese Entwicklung erscheint mir plausibel, fühlt sich aber auch ein wenig so an, als würden wir in die Zeit vor Agile mit Funktionsspezifikationen und Designdokumenten zurückkehren. Es ist zwar nicht ganz Big Design Up Front, aber es wirkt zunehmend wie „funktionierende Software == perfekte Dokumentation“.
Referenz zu Big Design Up Front, Referenz zum Agile Manifesto
Funktionsspezifikationen und Designdokumente sind letztlich so etwas wie Programmieren in natürlicher Sprache. Früher musste ein Mensch das dann noch einmal in einer Programmiersprache codieren, heute übernehmen automatisierte Compiler wie LLMs (Large Language Models) zunehmend diesen Schritt. Dadurch kann man eine Stufe überspringen, mit unterschiedlich hohem Erfolg.<br /> Agile hingegen kümmert sich nicht darum, in welcher Sprache Software erstellt wird. Im Kern geht es darum, „Manager auszuschließen“ und dass Entwickler auch die Managementarbeit selbst übernehmen. Die 12 Prinzipien gehen genauer darauf ein, was Entwickler tun müssen, wenn es keine Manager gibt.
Behaviour Driven Design kann wie Test Driven Design „lebende Spezifikationen“ hervorbringen. Von Kriterien zur Domänenerkundung bis hin dazu, ob Tests bestanden werden, bleibt alles in einer für Menschen lesbaren Dokumentform erhalten und kann direkt mit dem Test-Harness verbunden werden, um die aktuelle Funktionalität zu validieren. So erhält man über BDD-Reports klar validierte, kollaborative und iterierbare Spezifikationsdokumente und kann zugleich Agile, JIT und YAGNI ohne unnötige Vorarbeit mitnehmen. Es gibt keinen Grund, zu Waterfall zurückzukehren.
Man kann auch mit einem kleinen Design anfangen: eine ein- oder zweiseitige Spezifikation schreiben, mit einem LLM Code und Tests erzeugen und das dann iterativ verbessern. Wenn man 100 % LLM-Coding vertraut, ist es logisch, die Spezifikationseingaben (englische Prompts) systematisch zu verwalten. Wenn man die Prompts nicht wegwirft, sondern ordnet, kann man sie später wiederverwenden oder zusätzliche Einschränkungen klarer formulieren.<br /> Ich bin aber noch unsicher, LLMs für wichtigen Produktionscode zu nutzen, und experimentiere daher nur für Sandbox-, Test- oder Demo-Zwecke damit, also nur dort, wo Codequalität nicht ganz so kritisch ist.
Specification-Driven Development selbst ist eine gute Idee. Die aktuellen Implementierungen geben Agenten aber unstrukturierte Markdown-Dateien und liefern deshalb keine brauchbaren Ergebnisse, in der Praxis also überhaupt keine Reproduzierbarkeit. Wenn der Agent auch die Spezifikation schreibt, sollte daraus eine strukturierte Spezifikation werden, die sich automatisch in Stub-Code und Testcode umwandeln lässt. Man sollte Markdown nicht einfach verwerfen, sondern mit Codegeneratoren koppeln, dann wäre die Reproduzierbarkeit deutlich besser. In der Praxis könnte man so die Zeit für wiederholte Codegenerierung stark verkürzen.
Ich fand SpecKit beim Ausprobieren wirklich spannend und zufriedenstellend, hatte aber Schwierigkeiten, realistische komplexe Beispiele oder Anwendungsfälle zu finden. Die Tutorials bleiben meist beim simplen Installieren und „Baue eine To-do-Listen-App“ stehen. Ich würde gern echte Fälle sehen, in denen bestehende Legacy-Codebasen schrittweise verbessert oder refaktoriert werden, oder wie man an große Projekte herangeht, bei denen Specification-Driven Development nicht von Anfang an eingesetzt wurde.
Ich habe selbst gemerkt, dass es viel effektiver ist, Funktionen direkt im echten Code festzuhalten, während ich BDD-Ansätze und CLI-basiertes Coding kombiniere, statt lange, ausschweifende Markdown-Dateien zu schreiben. Wenn man eine Checkliste braucht, der die AI folgen soll, reicht eine Datei wie
agents.mdvöllig aus. Wenn man das Coding-Pattern und die nichtfunktionalen Anforderungen (NFR) einmal festhält, kann der Agent ihnen klar folgen.Für eine echte Nutzung muss man Templates oder Source Code direkt lesen, um zu verstehen, was tatsächlich passiert. Bei solchen Projekten halte ich das eher für einen selbstverständlichen Schritt.
Nach der Vorstellung eines AI-basierten Delivery-Experten von Thoughtworks und anschließendem Gerede über Memory Banks konnte ich sofort mitfühlen. Auch wir arbeiten in einem Umfeld, in dem „AI alles ist“, und sobald die Memory Banks größer werden, verliert die AI eher die Richtung und die Ergebnisse werden chaotisch. Am Ende muss jemand, der das Produkt vollständig versteht, die AI direkt führen, damit sie im realen Einsatz überhaupt nutzbar wird. Ich habe unzählige Male erlebt, wie sehr mich die AI in die Irre geführt hat, und wenn ein Mensch sie dann wieder auf Kurs bringt, entschuldigt sie sich zwar und behauptet, es jetzt verstanden zu haben, aber dadurch ändert sich letztlich nichts. Dass AI all die unzähligen Dokumente liest und validiert, die sie untereinander produziert, ist in der Realität ebenfalls unmöglich. Da denkt man sich schnell, dass man in der Zeit lieber einfach direkt selbst arbeitet.
Ich frage mich, was genau mit einer Memory Bank gemeint ist und was man konkret über ihre Rolle sagen will.
Zum jetzigen Zeitpunkt ist eine Memory-Funktion eher schädlich. Wenn man sie ohne eine ordentliche Such-/Retrieval-Strategie nutzt, verstärkt sie nur schlechte Ergebnisse. Die meisten Memory-Systeme sind für ein einzelnes Chat-Paradigma ausgelegt und verursachen in verschiedenen Umgebungen eher Probleme. Echtes „Gedächtnis“ sollte vielmehr als vom Hauptagenten getrenntes „Metakognitions-/Default-Mode-Network“ funktionieren, das asynchron Aufgabenstruktur und Kontext entwirft und dann jedem Prompt über dieses Metamodell eine Richtung gibt. Anders gesagt: Eigentlich braucht es „agentenbasierte Memory“.
Ich verstehe auch Titel wie „thought leader“ auf LinkedIn und ähnlichen Plattformen nicht. Was solche Bezeichnungen heute überhaupt noch bedeuten sollen, ist mir wirklich schleierhaft.
Ich möchte meine Erfahrungen aus den letzten zwei Wochen teilen, in denen ich mit SpecKit und Claude Code an zwei neuen Projekten experimentiert habe. Ich habe beide Projekte allein entwickelt, daher konnte ich ohne großes Risiko experimentieren. Das erste Projekt habe ich vollständig SpecKit überlassen. Nach zehn Tagen waren zwar alle Tasks abgearbeitet, aber die meisten Tests des Ergebnisses schlugen fehl und der Build war kaputt. Ich musste noch einmal genauso viel Zeit investieren, um die Probleme zu beheben, und jedes Mal, wenn Claude etwas reparierte, ging an anderer Stelle wieder etwas kaputt, was mein Vertrauen massiv geschwächt hat.<br /> Im zweiten Projekt wollte ich in kleineren Einheiten iterieren. Nach der Planung mit SpecKit habe ich daher Slash-Commands ergänzt,
backlog.mderstellt, mitplan-sprinteine Datei mit Sprint-Zielen und Arbeitsdetails erzeugt und dann mitimplement-sprintalles gesammelt abarbeiten lassen. Aber auch dieser Prozess funktionierte nicht zuverlässig: Trotz mehrerer Korrekturen des Ablaufs wurden Tests nicht erstellt oder einzelne Tasks vergessen.<br /> Deshalb habe ich das Setup erneut geändert und auf einen Ansatz umgestellt, bei dem es für einzelne Tasks Subagents gibt undimplement-sprintnur noch als Orchestrator dient. So konnte ich in jedem Sprint den Codezustand prüfen, was deutlich vertrauenswürdiger war. Es kommt zwar immer noch vor, dass behauptet wird, etwas sei fertig, obwohl Tests fehlschlagen, aber es ist trotzdem einfacher, als alles komplett selbst durchzugehen.<br /> Meine aktuelle Hypothese ist, dass Claude Schwächen bei TDD hat. Beim Schritt, zuerst Tests zu schreiben, gibt es immer Probleme. Als Nächstes will ich versuchen, Tests erst nach Abschluss der Implementierung schreiben zu lassen. Das ist nicht ideal, könnte aber zumindest die Produktivität so weit steigern, dass es besser ist, als direkt selbst zu coden.Ich fand es interessant, dass die meisten Tools stark auf eine „Spezifikation zuerst“-Strategie ausgerichtet sind, während unklar bleibt, wie die Spezifikationen gepflegt werden sollen. Ich setze persönlich gemeinsam mit meinem Cofounder voll auf „spec as source“. Ich halte es für den spannendsten Anwendungsfall, Spezifikationen wirklich zur Quelle zu machen, und wir experimentieren genau damit, aber es ist sehr schwierig, das tatsächlich zu etablieren. Falls jemand dazu Erfahrungen oder Feedback hat, würde ich das sehr gern hören.<br /> Wenn Interesse besteht, probiert auch gern specific.dev aus, das als Testfeld für unsere Experimente dient.
Ich habe den spec-driven Workflow von Kiro ausprobiert, und er spuckt unglaublich viele Aufgaben aus: mehr als vier Unteraufgaben pro Task, insgesamt mehr als zwölf Tasks. Der Workflow selbst war okay, aber er hat unvorhersehbar Code gelöscht und keine Rollbacks durchgeführt. Wahrscheinlich werden durch die Umsetzung als IDE Ressourcen in UI-Exception-Handling gebunden. Statt Dinge so stark zu zerlegen, ist es einfacher, schlicht iterativ zu verbessern. Das ist, als würde man „mit einem Vorschlaghammer eine Walnuss knacken“.
Mir gefiel der Ansatz mit benutzerdefinierten Slash-Commands, die Eingaben in gut strukturierte Prompts verpacken. Gut fand ich auch, dass aus Dateien wie
agents.mdzerlegte Teile zusammen mit Kontext eingespeist werden.<br /> Was mir aber nicht gefällt, ist der Versuch, jeden Knoten zu entwirren, weil sich das wieder wie Walnüsseknacken mit dem Hammer anfühlt und unnötige Komplexität erzeugt. Wenn man jedoch nur bei Bedarf zusätzliche Slash-Commands wie/experimentoder/stubfür selektives Kontextmanagement hinzufügt, könnte das leichtergewichtig sein. Am Ende könnte es dann einen reinen Abschlussbefehl wie"/wrap-up"geben, der alle losen Enden auf einmal zusammenbindet, so wie ein Arzt nach einer Operation noch einmal alles überprüft.Bei der Nutzung von SpecKit habe ich mich immer gefragt: „Wann werden all diese Specs endlich zu einem einzigen echten Ground Truth zusammengeführt?“ Es war enttäuschend, dass es diesen Schritt offenbar gar nicht gibt.<br /> Jetzt bleibt die Aufgabe, zu definieren und zu entwerfen, wie eine Kommunikationsspezifikation zwischen Mensch und Agent aussehen sollte. Ich überlege, wie sich Birgittas Konzept von „spec anchored“ umsetzen ließe.
Ich weiß nicht, warum SDD plötzlich so populär geworden ist, aber ich persönlich finde es einfach praktisch, Spezifikationsdateien anzulegen, um das „Endergebnis im Voraus zu erfassen“ und beim feingranularen Aufteilen eines Projekts den Fortschritt zu verfolgen. Ich verwende dafür keine besonderen Tools oder Frameworks, sondern nur Markdown-Dateien. Komplexere Systeme darüber hinaus haben für mich keinen erkennbaren Mehrwert.
Als ich spec-kit zum ersten Mal verwendet habe, war ich wirklich voller Erwartungen, aber in der Praxis hat es zwanghaft Aufgaben erzeugt, als müsste man „in einer Höhle einen Roboter bauen“, und selbst Arbeiten, bei denen man eigentlich nur eine Schraube festziehen müsste, unnötig aufgebläht. Ich war irgendwann vom ständigen Nachbessern erschöpft und habe aufgegeben. Ich finde, dieser übermäßig komplexe Workflow bietet nicht einmal genug Nutzen, um die nötigen Korrekturen zu rechtfertigen.
Eigentlich ist es einfach und praktisch, wenn man sich vorstellt, das in der Softwaretechnik Gelernte in Markdown umzusetzen. Es reicht schon, wenn man nur die Anforderungsspezifikation gut schreibt.