Spec-driven Development

Was ist Spec-driven Development

Eine Spezifikation ist ein Dokument, das sagt, was entstehen soll, bevor irgendjemand anfängt, Code zu schreiben. Sie beschreibt nicht jede Codezeile. Sie nennt das Ziel, den Umfang, also was zur Arbeit gehört und was nicht, und die Bedingungen, die erfüllt sein müssen, wenn die Arbeit fertig ist.

Die Arbeit verläuft in drei Schritten:

• Spezifikation. Ein Mensch schreibt sie selbst oder mit Hilfe eines Agenten, liest sie dann und überarbeitet sie, bevor die Lieferung beginnt.
• Lieferung. Ein Coding-Agent bekommt das ganze Dokument und arbeitet danach. Fehlt darin etwas, sollte er fragen und nicht raten.
• Prüfung. Das Ergebnis wird mit dem verglichen, was die Spezifikation angekündigt hat. Die Arbeit wird abgenommen oder geht zur Nacharbeit zurück.

Die Spezifikation ist ein eigenes Dokument und keine der Nachrichten im Gespräch mit dem Agenten. Sie können sie überarbeiten, einer anderen Sitzung oder einer anderen Person geben und nach einer Woche nachlesen, was vereinbart war. Ändert das Team seine Meinung, ändert es das Dokument.

Spec-driven Development mit KI-Agenten

Beim Agentic Coding, bei dem ein KI-Agent ganze Entwicklungsaufgaben übernimmt, ist die Spezifikation die Aufgabe des Agenten. Eine kurze Bitte im Chat lässt vieles offen, und der Agent entscheidet jeden offenen Punkt auf seine Weise oder hält an, um Sie zu fragen. Eine Spezifikation klärt diese Punkte, bevor die Arbeit beginnt. Für einen Agenten enthält sie meist:

• Ziel und Umfang. Wozu die Arbeit dient, was dazugehört und was außen vor bleibt, damit der Agent weder zu wenig tut noch nebenbei etwas ändert.
• Abnahmekriterien. Überprüfbare Aussagen, die zutreffen müssen, wenn die Arbeit erledigt ist. Jede beurteilen Sie mit Ja oder Nein, wenn der Agent die Arbeit meldet.
• Eine Prüfung, die der Agent selbst ausführt. Tests oder ein Build, die mit Erfolg oder Fehler enden, damit der Agent seine Arbeit prüfen kann, bevor er sie meldet.

Auch die Größe zählt. Eine Spezifikation für einen Agenten sollte eine Arbeit beschreiben, die ein Agent in einer Sitzung vollständig liefern kann. Größere Vorhaben, etwa eine ganze Funktion aus einem PRD, werden auf mehrere Spezifikationen in einem Epic verteilt, und die Reihenfolge zwischen ihnen wird festgehalten.

Die Arbeit macht der Agent, das Ergebnis beurteilt ein Mensch: Er vergleicht es mit der Spezifikation und nimmt es ab oder schickt es zur Nacharbeit zurück. Diese Arbeitsweise, bei der an den wichtigen Punkten ein Mensch entscheidet, heißt Human-in-the-Loop. Der Beitrag Wie Sie einen Plan schreiben, den ein KI-Agent ohne Raten liefert zeigt Schritt für Schritt und an einem Beispiel, wie eine solche Spezifikation entsteht.

Spec-driven Development in featureloom

In featureloom ist die Spezifikation der Plan: ein Dokument in Markdown auf einem Kanban-Board. Sie schreiben ihn selbst mit „Neuer Plan“, ausgehend von einem leeren Dokument, generieren ihn in der App aus eingefügtem Text oder einem PDF- oder Word-Dokument oder bitten einen Agenten in der Konsole, ihn aus Ihrem Material zu schreiben, zum Beispiel aus der Abschrift einer Besprechung, die Sie ihm als Datei geben.

Ein in der App generierter Plan entsteht nach der Planvorlage des Projekts, und der Prompt Planer weist den Agenten an, Pläne in den Abschnitten dieser Vorlage zu schreiben. Die eingebaute Vorlage fragt unter anderem nach Ziel, Umfang, Schritten, Abnahmekriterien und der Definition of Done. Abnahmekriterien sind überprüfbare Aussagen, die zutreffen müssen, wenn die Arbeit erledigt ist. Die Vorlage passen Sie für Ihr Team auf dem Bildschirm „Projekteinstellungen“ im Reiter „Planvorlage“ an.

Der Befehl aus einem Plan, zum Beispiel featureloom umsetzer INV-14, gibt dem Agenten in einem Aufruf den Prompt mit dem Prozess Ihres Teams, das ganze Plandokument und die Dokumente der gelieferten Pläne, von denen dieser Plan direkt abhängt. Der Prompt Umsetzer, den jede neue Organisation hat, weist den Agenten an, nur das zu tun, was im Plan steht, und zu fragen, statt zu raten, wenn der Plan etwas offenlässt. Die Frage und Ihre Antwort landen im Plandokument.

Am Ende weist derselbe Prompt den Agenten an, die Lieferung mit einer Notiz zu melden: was er getan hat, worin er vom Plan abgewichen ist und warum, und was er nicht getan hat. Sie vergleichen das Ergebnis mit dem Plan und wählen „Abnehmen“ oder „Nicht abnehmen“, mit oder ohne Begründung. Die Entscheidung trifft nur eine Person in der App, und eine Entscheidung aus einer Konsole lehnt der Server ab. Nach einer Ablehnung liest der Agent die Entscheidung und bessert nach.

Ein Plan kann sich mit dem ändern, was das Team lernt. Jedes Speichern, das den Text ändert, ergibt eine neue Version, und ein Plan behält seine letzten 100 Versionen. Den ganzen Weg eines Plans, vom Board bis zur Abnahme, zeigt die Seite So funktioniert featureloom. Wie diese Arbeitsweise mit Claude Code aussieht, von der Spec bis zur abgenommenen Arbeit, zeigt Spec-driven Development mit Claude Code.