# Spezifikationsgesteuerte Entwicklung

> Wie Asana-Entwickler wiederholte Prompts an KI-Programmierassistenten in einen dauerhaften, spezifikationsgesteuerten Workflow umgewandelt haben und was wir nach rund drei Monaten interner Nutzung gelernt haben.

Source: https://asana.com/de/inside-asana/spec-driven-development

## Spezifikationsgesteuerte Entwicklung: Die positiven Aspekte – und was wir nach drei Monaten gelernt haben

_Nach drei Monaten hatten wir ein klareres Bild davon, wann die zusätzliche Struktur hilfreich war und wann sie eher hinderlich war._

Einer unserer Entwickler bereitete eine Datenmigration vor und entschied sich, die Arbeit mithilfe von Spec-Driven Development (SDD) zu planen. SDD sollte ihm helfen, Lücken frühzeitig zu erkennen, den Ansatz leichter zu überprüfen und dem Agenten eine klare Richtung vorzugeben. Der daraus resultierende Plan war detailliert und sah auf dem Papier ziemlich vernünftig aus. Die Arbeit wurde wie folgt strukturiert:

**Problem → Recherche → Spezifikation → Überprüfung → Implementierung → Verifizierung**

Im Laufe der Implementierung stellte der Entwickler fest, dass zwei Jobs gleichzeitig ausgeführt werden und dadurch doppelte benutzerdefinierte Felder erstellen könnten. Der Ansatz machte den Code auch immer komplexer und schwerer nachvollziehbar. Glücklicherweise erkannte er das Problem, stoppte die Implementierung, verfasste ein einseitiges Designdokument und markierte einige Kollegen, um deren Input einzuholen. Gemeinsam arbeiteten sie den Entwurf durch und fanden einen sichereren Ansatz.

Die ursprünglichen Spezifikationen haben ihren Zweck erfüllt: Sie haben dafür gesorgt, dass das Projekt in die ursprünglich geplante Richtung weitergeführt wurde. Das Problem war, dass die Richtung falsch war. Dank der detaillierten Spezifikation konnte das Projekt problemlos fortgesetzt werden, auch wenn die Ausgangsidee wackelig war. Der KI-Assistent konnte diese Idee schneller ausarbeiten, als die Menschen sie stoppen und hinterfragen konnten.

Dieses Projekt zeigte ein Risiko zusätzlicher Struktur auf: Ein Agent konnte dieselbe falsche Annahme aus der Spezifikation in den Code und die Tests übernehmen. Die Spezifikation, der Code und die Tests stimmten miteinander überein, aber das bedeutete nicht, dass die zugrunde liegende Annahme richtig war. Bei riskanteren Entscheidungen musste immer noch eine andere Person zum ursprünglichen Ziel zurückkehren und nach Möglichkeiten suchen, wie die Umsetzung dieses Ziel gefährden könnte.

Dennoch übernahmen die Agenten Aufgaben, die länger als eine Sitzung dauerten, und ein Prompt reichte oft nicht aus, um festzuhalten, was das Projekt bezweckte oder warum. Das veranlasste uns dazu, /spec-driven zu entwickeln, ein Workflow-Framework, bei dem die Spezifikation im Mittelpunkt steht. Die Spezifikation sorgte dafür, dass die Ausrichtung des Projekts auch in der nächsten Sitzung verfügbar war. Skripte lieferten Kontext und führten Prüfungen durch. Wenn bei einem Durchlauf eine fehlende Regel, Prüfung oder ein fehlender Kontextteil festgestellt wurde, konnten wir dies dem Workflow hinzufügen, damit spätere Agenten dieselbe Lücke nicht erneut entdecken mussten.

Es gibt immer noch erhebliche Meinungsverschiedenheiten darüber, ob die zusätzliche Struktur von SDD es wert ist. [Microsoft](https://developer.microsoft.com/blog/spec-driven-development-ai-native-engineering) und [AWS](https://aws.amazon.com/blogs/machine-learning/how-frontier-teams-are-reinventing-ai-native-development/) befürworten SDD, während [Thoughtworks es als aufstrebend und umstritten bezeichnet](https://www.thoughtworks.com/en-sg/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices) und [Praktiker von gemischten Erfahrungen berichten](https://news.ycombinator.com/item?id=45610996). Kritiker warnen davor, dass SDD mehr Markdown erzeugen kann, als Entwickler warten können, eine detaillierte Spezifikation in in Prosa verfassten Code verwandeln oder eine weitere Beschreibung des Systems hinterlassen kann, die vom Code abweicht.[1][2][3]

Nach drei Monaten praktischer Anwendung haben wir erkannt, dass die wichtige Frage nicht darin bestand, ob wir SDD verwenden sollten. Es ging darum, was dem Agenten bei diesem Projekt fehlte. Manchmal war die Antwort eine Spezifikation. Manchmal war es ein besseres Beispiel, eine automatisierte Überprüfung oder ein Entwickler, der sich mit dem Bereich auskannte.

## Warum wir /spec-driven entwickelt haben

Einige Entwickler bei Asana hatten bereits [GitHub Spec Kit](https://github.com/github/spec-kit/blob/main/docs/reference/workflows.md) und [OpenSpec](https://github.com/Fission-AI/OpenSpec/blob/main/docs/customization.md) ausprobiert, aber keines davon wurde Teil ihres regulären Workflows. Wir wollten eine Version, die wir im Laufe der Zeit anpassen und mit dem Entwicklungsprozess von Asana verknüpfen konnten.

Der integrierte Planungsmodus konnte bereits die Codebasis analysieren und einen nützlichen Implementierungsplan erstellen, bevor Änderungen vorgenommen wurden. SDD hat diesem Plan mehr Struktur verliehen: Es sorgte dafür, dass das Problem, die wichtigsten Entscheidungen und die Akzeptanzkriterien während der Implementierung und Verifizierung sichtbar blieben.

Vor der Implementierung gab /spec-driven sein Verständnis des Problems wieder und stellte die Fragen, die den Plan ändern könnten. Dadurch hatte der Entwickler die Möglichkeit, die Richtung zu korrigieren, bevor Code umgeschrieben werden musste.

Wir haben diesen Status im Repository gespeichert, damit bei späteren Sitzungen nicht geraten werden musste, was passiert war. Wir wollten, dass die Regeln des Workflows deterministisch sind, daher übernahmen Skripte die Buchführung und die Prüfungen. Das Modell übernahm die Teile, bei denen ein Urteilsvermögen von Vorteil war: Fragen stellen, Kompromisse abwägen und Entscheidungen begründen.

Der Workflow umfasste mehrere Befehle. Die Entwickler verwendeten /spec-driven spec, um offene Fragen zu klären und eine Spezifikation sowie einen Implementierungsplan zu erstellen. Nach der Überprüfung des Plans verwendeten sie /spec-driven ship, um ihn umzusetzen, das Ergebnis zu verifizieren und die Arbeit für die Überprüfung vorzubereiten. Ein Zustandsautomat verfolgte das Projekt, während es diese Befehle durchlief, sodass in späteren Sitzungen bekannt war, was geschehen war und was als Nächstes anstand.

Von Anfang an wollten wir, dass /spec-driven mehr ist als nur eine Möglichkeit, Spezifikationen zu verfassen und umzusetzen. Wir wollten damit auch agentische Workflows koordinieren. Es ordnet Aufgaben nach Abhängigkeiten und führt sich überschneidende Dateiänderungen in separaten Ausführungsrunden durch. Es weist mehrere Agenten parallel mit unabhängigen Aufgaben, und verwendet dann die Ergebnisse, um zu entscheiden, was als Nächstes ausgeführt werden kann.

Es fühlt sich an wie ein GPS für die Arbeit: Zu jedem Zeitpunkt ist klar, was der nächste Schritt ist und wo die wirklich wichtigen Entscheidungen zu treffen sind, sodass es kaum zu Verzögerungen kommen kann.Entwickler bei Asana haben /spec-driven sowohl im Spec-First- als auch im Spec-Anchored-Modus verwendet. Im Spec-First-Ansatz verwendeten sie eine Spezifikation, um eine Richtung festzulegen, und aktualisierten sie anschließend nicht mehr. Im Spec-Anchored-Ansatz hielten sie die Spezifikation auf dem neuesten Stand, während sich die Arbeit veränderte. Die Entwickler erstellten auch unabhängige Spezifikationen für Teile eines größeren Vorhabens, sodass eine einzelne Person den Workflow nutzen konnte, ohne das gesamte Team um die Einführung zu bitten.

## Wann sich /spec-driven trotz des zusätzlichen Aufwands lohnt

Die zusätzliche Struktur zahlte sich am meisten aus, wenn wichtiger Kontext über mehrere Sitzungen, Übergaben oder viele zusammenhängende Aufgaben hinweg erhalten bleiben musste. Die Entwickler konnten nachvollziehen, wie sich der Plan geändert hatte, und die Ausrichtung des Projekts blieb auch dann erhalten, wenn die Arbeit in eine andere Agent-Sitzung oder an eine andere Person übergeben wurde. Bei zwei Produktprojekten wurden die Spezifikationen etwa zwei bis drei Monate lang aktuell gehalten: Bei dem einen wurde eine wichtige neue Funktion entwickelt, bei dem anderen wurden die Termine von Unteraufgaben auf die übergeordneten Aufgaben übertragen.

Ich habe gerade eine ziemlich große Initiative mit Spec-driven abgeschlossen und ich denke, es hat mir wirklich geholfen! Ich habe etwa zwei Tage an dem Plan gearbeitet und dann alle Entwicklungsarbeiten erledigt und in drei Tagen gemergt.Spezifikationen erleichterten die Übergabe. Jemand, der ein pausiertes Projekt übernahm, konnte sehen, was das Team erreichen wollte, warum es diese Form angenommen hatte und was noch zu erledigen war. Sie mussten das Projekt nicht anhand von Commits und Diskussionen rekonstruieren.

Die Entwickler*innen nutzten /spec-driven auch, um große Mengen von Aufgaben zu koordinieren, die von Agenten ausgeführt wurden. In der Admin-Konsole von Asana, in der IT-Teams bei Kundenunternehmen unternehmensweite Sicherheits-, Zugriffs-, Integrations- und Freigabeeinstellungen verwalten, haben Entwickler sie genutzt, um 66 Einstellungen in gemeinsame Frameworks zu überführen. Die Übertragung dieser Einstellungen erforderte rund 150 Migrationen über mehrere Frameworks der Admin-Konsole hinweg. Jede Migration wurde zu einem Asana-Ticket für einen Cloud-Agenten, und die Entwickler führten sie in parallelen Batches aus und aktualisierten die verbleibenden Tickets basierend auf früheren Ergebnissen.

Das Team, das diesen Vorgang durchführte, berichtete, dass 91 % der Migrationen nach der Überprüfung keine Überarbeitung erforderten und dass der gesamte Vorgang mehr als einen Monat früher als ursprünglich geplant abgeschlossen wurde.

Eine weitere umfangreiche Migration erforderte nur eine kurze Eingabe. Der Unterschied lag darin, wie viel die Codebasis bereits verdeutlichte. Sie enthielt Beispiele, denen die Agenten folgen konnten, und Prüfungen, mit denen das Ergebnis verifiziert werden konnte. Die Agenten der Admin-Konsole konnten nicht alle Anforderungen aus dem Code ableiten, sodass die Arbeit mehr Struktur benötigte.

/spec-driven half auch bei der schnellen Prototypenentwicklung. Die Entwickler konnten schnell gerade so viele der offenen Produktfragen beantworten, dass sie eine funktionierende End-to-End-Erfahrung erstellen konnten. Produktmanager und Designer konnten einen Prototyp ausprobieren, bevor die Entwickler in die Optimierung für die Produktion investierten. Wenn die Entwickler beschlossen, den Code beizubehalten, musste er in der Regel gründlich überarbeitet werden, bevor er gemergt werden konnte. Zu diesem Zeitpunkt hatte der Prototyp bereits gezeigt, ob es sich lohnte, die Idee weiterzuverfolgen.

## Was die ersten Zahlen zeigten

Wir haben alle ermutigt, /spec-driven einmal auszuprobieren, haben aber keine fortgesetzte Nutzung vorgeschrieben. Etwa die Hälfte der Entwickler hat es ausprobiert. Im letzten Monat lag die wöchentliche Nutzung zwischen 30 und 50 Entwickler*innen. Unter den integrierten und von Asana entwickelten Agent-Fähigkeiten, die von den Entwicklern direkt aufgerufen wurden, belegte /spec-driven den dritten Platz. Die fortgesetzte Nutzung war ermutigend, aber sie gab uns keinen Aufschluss darüber, wie sich /spec-driven auf die Bereitstellung auswirkte.

Die Geschwindigkeit der Entwicklung lässt sich bekanntermaßen nur schwer messen. Pull Requests und Ergänzungen des Implementierungscodes sind ungenaue Indikatoren für die Produktivität, aber wir glauben, dass sie oft hilfreiche Anhaltspunkte liefern. Für den Vergleich der Entwicklungsgeschwindigkeit haben wir sieben Entwickler und 524 gemergte Pull Requests über einen Zeitraum von vier Monaten untersucht. Wir haben die Arbeit vor und nach der ersten eindeutigen Verwendung von /spec-driven durch jeden Entwickler verglichen und Spezifikationen, Pläne und andere Workflow-Artefakte ausgeschlossen. Für den Vergleich der Rückgängigmachungen haben wir einen Pull Request als /spec-driven eingestuft, wenn er die Projektdateien des Workflows geändert hat.

Die Anzahl der Pull Requests pro Woche stieg um 38 %, und die Anzahl der hinzugefügten Zeilen Implementierungscode stieg um das 2,66-Fache. Ein kurzer Zeitraum mit ungewöhnlich hohem Volumen beeinflusste das Ergebnis der Hinzufügungen. Auch ohne dieses Zeitfenster waren die Hinzufügungen immer noch um 66 % höher. Auch die Rate der expliziten Rückgängigmachungen war geringfügig niedriger: 1,2 % bei /spec-gesteuerter Arbeit im Vergleich zu 1,66 % bei anderen Pull Requests.

Mehr Code ist nicht unbedingt ein gutes Ergebnis. Ein Agent kann eine umfangreiche Implementierung erstellen, obwohl eine kleinere ausreichen würde. Der Anstieg der Code-Hinzufügungen könnte daher eher auf unnötig umfangreiche Lösungen als auf mehr erledigte Arbeit zurückzuführen sein. Die normale Überprüfung gab uns eine Möglichkeit, diese Fehlerursache zu erkennen. Wir verließen uns darauf, dass die Prüfer Implementierungen kennzeichnen, die größer oder komplexer waren, als es das Problem erforderte, und diese Änderungen wurden trotzdem akzeptiert. Das gab uns die Gewissheit, dass überdimensionierte Implementierungen nicht für den gesamten Anstieg verantwortlich waren.

Diese Vergleiche wurden nicht kontrolliert, und wir konnten den Effekt von /spec-driven nicht von der Projektmischung oder umfassenderen Verbesserungen bei den Tools für Agenten trennen. Trotz dieser Einschränkungen waren wir von den Ergebnissen ermutigt.

## Was noch verbessert werden muss

### Die Überprüfung der Dokumente kann zu einem Engpass werden

Die Erstellung einer Spezifikation dauerte zwischen 30 Minuten und mehreren Tagen, je nachdem, wie vertraut der Entwickler mit dem Bereich war und wie komplex und risikoreich das Projekt war. Entwickler konnten /spec-driven verwenden, damit ein Agent schnell eine Spezifikation entwirft, aber die Überprüfung nahm immer noch Zeit in Anspruch.

Bei einem Versuch verbrachte ein Entwickler Stunden damit, einen Pull Request mit research.md zu überprüfen, einer Arbeitsdatei, in der der Agent festhielt, was er aus der Codebasis, der Dokumentation und früheren Entscheidungen gelernt hatte, bevor er den Entwurf der Spezifikation erstellte. Einige dieser Erkenntnisse waren vage, ungenau oder leicht fehlerhaft.

Diese Überprüfung zeigte, dass wir uns nicht darüber einig waren, ob es sich bei diesen Dateien um temporäre Arbeitsnotizen oder um Dokumentationen handelte, auf die sich zukünftige Entwickler verlassen sollten. Einige Entwickler schätzten die Dokumentation darüber, wie eine Entscheidung getroffen wurde. Andere befürchteten, dass das Einchecken unvollständiger Forschungsergebnisse den Anschein erwecken könnte, dass diese Ergebnisse verbindlich seien.

Bei einem Infrastrukturteam wurde die Überprüfung der Spezifikation zu einem neuen Hindernis vor der Implementierung.

Ich hatte den Eindruck, dass die Befehle und der Workflow viel komplizierter und zeitaufwändiger waren, als einfach nur einen Plan zu erstellen und ihn dann umzusetzen.Die meisten Prüfer wollten keine lange Spezifikation lesen und dann auch noch den Code überprüfen. Als die Arbeit einen Pull Request erreichte, musste die Übergabe die Entscheidung zusammenfassen, warum wir sie getroffen haben, was riskant erschien und wie wir das Ergebnis überprüft haben. Wenn die Richtung selbst überprüft werden musste, mussten wir dies früher anfordern, solange es noch einfach war, Änderungen vorzunehmen.

### Eine nützliche Spezifikation verändert sich im Laufe des Projekts

Die Entwickler lernten ständig dazu, während sie den Plan umsetzten. Die Aktualisierung der Spezifikation mit den gewonnenen Erkenntnissen war mit Aufwand verbunden. Die Details der Spezifikation waren bei der Implementierung hilfreich, da sie zeigten, was der Agent nach seiner Vorstellung entwickeln sollte. Im Anschluss wiederholte ein Großteil dieser Details den Code.

Wir sind jetzt der Ansicht, dass eine funktionierende Spezifikation wachsen sollte, solange das Projekt noch unsicher ist, und schrumpfen sollte, sobald der Code die Implementierung erklären kann. Was übrig bleibt, sollte dem/der nächsten Leser*in helfen, das Design, wichtige Entscheidungen, Einschränkungen und ungelöste Risiken zu verstehen.

Erledigte Spezifikationen werfen eine damit zusammenhängende Frage auf: Was soll mit ihnen geschehen? Wir haben zu lange gewartet, um sie zu beantworten. Wenn wir sie im Monorepo belassen, sind sie zwar leicht zu finden, aber es bleiben auch Dokumente zurück, für die niemand verantwortlich ist. Wir verschieben sie in ein separates Archiv. Wir brauchen immer noch eine kürzere Übergabe, bei der das, was später wichtig ist, erhalten bleibt. Wenn ein Dokument mehr Arbeit verursachte, als es einsparte, war es nicht hilfreich.

## Einbau von Feedbackschleifen in das System

Manchmal war die Lösung nicht ein weiteres Dokument, sondern eine Änderung des Systems rund um den Agenten. Ein Beispiel war ein Fehler bei der Art und Weise, wie /spec-driven Markdown liest: Überschriften und Checkboxen in Beispielen konnten mit tatsächlichen Meilensteinen oder unerledigten Aufgaben verwechselt werden. Nachdem wir den Fehler erfasst hatten, durchsuchten wir den Rest von /spec-driven und fanden mehrere Befehle mit einem eigenen kleinen Markdown-Parser und derselben Schwachstelle. Wir haben sie durch einen gemeinsamen Parser ersetzt, Regressionstests und eine Architekturprüfung hinzugefügt und die Korrektur in die Umgebung implementiert. [OpenAI beschreibt einen ähnlichen Ansatz als Harness Engineering](https://openai.com/index/harness-engineering/): Wichtiges Wissen dort bereitstellen, wo Agenten es finden können, Regeln durchsetzbar machen und Fehler nutzen, um die Umgebung des Agenten zu verbessern.

Andere Erkenntnisse konnten nicht in einen Test oder eine Architekturregel umgewandelt werden. Wir haben wiederkehrende Fehler zu Leitlinien zusammengefasst. Da /spec-driven die Benutzer durch einen vorhersehbaren Workflow führte, konnten wir jede Lektion anzeigen, wenn der Agent den entsprechenden Schritt erreichte. Die Entwickler entschieden nach wie vor, welche Erkenntnisse über das ursprüngliche Projekt hinaus Anwendung fanden.

Wir haben die Leitlinien an acht früheren Pull Requests sowie an synthetischen Fällen getestet, die darauf ausgelegt waren, irrelevante Ratschläge zu erkennen. In einem Folgetest haben wir drei dieser früheren Aufgaben mit kurzen, mittleren und ausführlichen Prompts getestet, was insgesamt neun Vergleiche ergab. In acht der neun Vergleiche lieferte die Anleitung eine nützliche zusätzliche Frage oder eine Abgrenzung für die Planung. In einem separaten Test wurden drei weitere frühere Aufgaben untersucht. Dabei wurden zwei Pläne eindeutig verbessert; beim dritten hatte der Agent ohne Unterstützung bereits das Problem erkannt.

Die nützlichsten Hinweise betrafen Verhaltensänderungen, betroffene Verbraucher und Varianten sowie Verträge zwischen APIs, Schemata oder Parsern. Die Evaluierungen umfassten nur Fragen und Pläne. Wir haben nicht gemessen, ob die Anleitung die Implementierung beschleunigt hat. Spezifische Leitlinien wurden auch schneller veraltet und tauchten manchmal bei nicht zusammenhängenden Arbeiten auf.

Die Pflege der Leitlinien und Bewertungen erforderte mehr Arbeit als die Erstellung der ersten Version. Wir konnten die Problemstelle mit Hilfe von Leitlinien lokalisieren, sie durch die Behebung des zugrunde liegenden Systems beseitigen oder das Risiko in Kauf nehmen, dass ein Agent oder Prüfer sie erneut finden müsste. In der Regel haben wir sie zuerst markiert, weil das günstiger war. Die Behebung von Problemen mit der zugrunde liegenden API, dem Test, der Dokumentation oder dem Beispiel war zwar mit mehr Arbeit verbunden, kam aber allen zugute und machte die Leitlinien überflüssig.

## Wie wir jetzt /spec-driven angehen würden

Wir wollten verhindern, dass Entwickler immer wieder die gleichen Eingabeaufforderungen wiederholen und das Projekt erneut erklären müssen, ohne dabei die nützliche Reibung zu beseitigen. Der Agent musste immer noch anhalten, wenn er eine wichtige Frage hatte, Belege fehlten oder der nächste Schritt menschliches Urteilsvermögen erforderte. Wir haben einige praktische Richtlinien erarbeitet:
- Für die meisten kleinen, lokalen Änderungen reicht eine Diskussion oder ein kurzer Plan aus.
- Nutzen Sie den Spec-First-Ansatz, um sich auf eine Richtung zu einigen. Halten Sie die Spezifikation fest, wenn Entscheidungen auch in späteren Sitzungen oder Übergaben Bestand haben müssen.
- Nehmen Sie nicht jedes fehlende Puzzleteil in die Spezifikation auf. Das Harness sollte Kontext liefern und Prüfungen durchführen; architektonische Beurteilungen müssen nach wie vor von Menschen überprüft werden.

Wenn es sich lohnt, eine Spezifikation zu pflegen, schreiben Sie sie für die nächste Person, die sie liest. Sorgen Sie dafür, dass Entscheidungen und Risiken leicht zu finden sind, verlinken Sie auf Belege, anstatt sie zu kopieren, und entscheiden Sie, was mit der Spezifikation geschehen soll, wenn das Projekt endet.

## Wie geht es nun weiter?

Nach drei Monaten verwenden die Entwickler immer noch /spec-driven, wenn die Arbeit über mehrere Sitzungen hinweg andauert, zwischen verschiedenen Personen übergeben wird oder in viele zusammenhängende Aufgaben unterteilt wird. Sie haben es genutzt, um Projekte, die sich über mehrere Monate erstrecken, am Laufen zu halten und große Mengen an von Agenten ausgeführten Arbeiten zu organisieren. Das ist ein gutes Ergebnis für ein internes Experiment.

Als wir /spec-driven erweiterten, um mehr Arten von Arbeit zu unterstützen, lösten einige neue Funktionen zwar echte Probleme für bestimmte Teams, machten den Workflow aber für alle komplexer. In der nächsten Version wollen wir uns in Richtung eines kleineren, fokussierteren Kerns bewegen.

Die Menschen haben eine ausgeprägte Meinung zu SDD und Harness Engineering. Wir haben mehr gelernt, indem wir sie bei der tatsächlichen Arbeit ausprobiert haben, als indem wir über sie diskutiert haben. Bevor wir weitere Prozesse hinzufügen, fragen wir jetzt, was dem Agenten bei diesem Projekt fehlt. Beginnen Sie klein, beobachten Sie, wo der Workflow hilft oder im Weg steht, und nehmen Sie dann Anpassungen auf der Grundlage Ihrer Erkenntnisse vor.

[1] Birgitta Böckeler, „[Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)“, Oktober 2025.

[2] François Zaninotto, „[Spec-Driven Development: The Waterfall Strikes Back](https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html)“, November 2025.

[3] Gabriella Gonzalez, „[A sufficiently detailed spec is code](https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code)“, März 2026.

#### **Über den Autor**

Walter Li ist Softwareentwickler im Team für die zentrale Speicherinfrastruktur von Asana, und Rohan Batra ist Softwareentwickler im Team für Backend-Frameworks. Beide waren einige Monate lang im Agent Success Tiger Team tätig, wo sie die Entwicklung und Bewertung des in diesem Beitrag beschriebenen /spec-driven-Workflows leiteten.

#### **Dank an das Team**

Besonderen Dank an Leo Zhang, Karol Krupa, Gordie Levitsky und Mitch Conquer, die uns bei der Gestaltung und Entwicklung von /spec-driven unterstützt haben und zu den ersten Nutzern gehörten.

- [Spezifikationsgetriebene Entwicklung: Die positiven Aspekte – und was wir nach drei Monaten gelernt haben](/de/inside-asana/spec-driven-development)

Entwicklung

Nach drei Monaten hatten wir ein klareres Bild davon, wann die zusätzliche Struktur hilfreich war und wann sie eher hinderlich war.Einer unserer Entwickler bereitete eine Datenmig ...

- [Entwicklung](/inside-asana/engineering-spotlight)