Spec-Driven Development hat das Coding strukturiert, indem es eine saubere Spezifikation vor dem eigentlichen Implementieren verlangt. Plan-to-Plan sieht eine weitere Schicht vor: die Strategie. Beide Schritte sind explizit, d.h., beide produzieren ein gespeichertes Artefakt, in der Regel ein oder mehrere Markdown-Dateien. Die Methode reduziert Reibung, weil sie Entscheidungen, die sonst oft vermischt werden, sichtbar trennt.
Der Name Plan-to-Plan soll außerdem daran erinnern, dass sowohl die Strategie als auch die Planung jeweils im Plan-Modus eines Agenten erfolgen soll. Das Vorgehen ist nicht das, was die offizielle Anthropic-Empfehlung zum Plan-Mode beschreibt. Dort ist von einem Plan-Mode-Durchgang die Rede. Ich nutze ihn mindestens zweimal. Das klingt nach Mehraufwand, ist aber im Alltag genau das Gegenteil.
Auch wenn dieser Artikel mit Coding beginnt, ist das Vorgehen eins zu eins auf jede Art von Wissensarbeit anwendbar. Es zwingt einen, die strategischen, die taktischen und die operativen Schichten der Wissensarbeit zu trennen.
Das Problem mit ad-hoc-Prompting
Bei nicht-trivialen Aufgaben mischt sich beim ad-hoc-Prompting Strategie und Implementierung. Man fragt nach einer Lösung, das Werkzeug schreibt Code oder verfasst ein Dokument, und während es das tut, trifft es immer auch Annahmen, denn ein solcher Prompt lässt fast immer einen großen Spielraum. Welche Voraussetzungen gelten? Welche Architektur oder Struktur ist das Ziel? Welche Trade-offs sind akzeptabel? Wenn man das Ergebnis dann inspiziert, sieht es erstaunlich oft "irgendwie richtig" aus, "kann man so machen", ist aber eben nicht das, was ich mir vorgestellt habe.
Doch Korrekturen (nicht nur beim Coden) sind teuer. Man muss überprüfen, zurücknehmen, evtl. mit Teilen neu beginnen, oder im schlimmsten Fall das Ergebnis einfach akzeptieren, weil das Zurückdrehen den Aufwand übersteigt. Das ist kein Problem des Werkzeugs KI, das ist ein Problem der Herangehensweise. Die Spezifikation war zu wenig detailliert, die Strategie, d.h., der übergeordnete Kontext fehlte ganz.
Spec-Driven Development stellt eine Lösung für den zweiten Teil dieses Problems bei der Softwareimplementierung dar: die Spec vor den Code. Tools wie GitHub Spec Kit machen das systematisch. Der erste Teil aber bleibt weiter offen: die übergeordnete Strategie fehlt weiterhin. Die Spec beim Spec-Driven Development ist immer noch eine Mischung aus dem "Was" und dem "Warum". Hier setzt Plan-to-Plan an.
Die Methode in drei Schritten
Der erste Schritt: Konzept. Plan-Mode an, dem Werkzeug die Aufgabe stellen, aber ausdrücklich nicht zur Implementierung auffordern. Stattdessen: Ziel beschreiben und zur Kritik aufrufen, explizit Fragen stellen: Welche Optionen gibt es? Welche Annahmen liegen der Idee zugrunde? Welche Trade-offs müssen berücksichtigt werden? Welche Entscheidungen werden auf welcher Grundlage getroffen? Das Ergebnis ist ein Markdown-Dokument mit einer durchdachten übergeordneten Strategie, ohne eine einzige Zeile Ergebnis.
Zweiter Schritt: Implementierung. Kontext leeren, Plan-Mode an, der Konzept-Plan ist Eingabe. Wieder wird diskutiert: Wie wird das operationalisiert, welche Möglichkeiten hierzu bestehen? Welche Schritte, Dateien, Schnittstellen, Tests? Strategische Spielräume sind hier ausgeschlossen. Wenn etwas im Konzept unklar ist, kommt eine Rückfrage und die Unklarheiten müssen im ersten Dokument beseitigt werden. Das Ergebnis ist ein zweites Markdown-Dokument, das das Konzept in eine technische Spec übersetzt. Ist das Ziel keine Software, wäre diese der Ort für das konkrete Vorgehen zur Erstellung und die Struktur des Ergebnisdokuments, die Referenzen, auf die es sich bezieht, was dort enthalten sein soll und was nicht.
Dritter Schritt: Ausführung. Kontext leeren, Plan-Mode nur noch optional, je nach Größe des Schritts, Implementierungsplan ist die Eingabe. Der Implementierungs-Plan ist die Spec, an der sich die Ausführung nun orientiert. Die Steuerung von außen ist minimal, weil die Entscheidungen schon getroffen sind. Wenn doch eine strukturelle Frage auftaucht, soll diese nicht an dieser Stelle entschieden werden, sondern eine Ebene höher - die Sitzung wird also unterbrochen, der Fortschritt dokumentiert und in einer zweiten Session mit dem Werkzeug wird die Spec oder das Konzept erneut unter die Lupe genommen und nachgebessert.
Die drei Schritte zwingen einen, die getroffenen Entscheidungen auf den unterschiedlichen Ebenen sichtbar zu machen.
Drei Schichten als Konsequenz
Aus der Methode ergeben sich drei Schichten der Wissensarbeit mit eigenem Charakter. Die strategische Schicht produziert lange Prosa, weil Argumentation Raum braucht. Die taktische Schicht ist ein Verständigungsraum, in dem laut gedacht und immer wieder zurückgefragt wird. Die operative Schicht ist spec-getrieben, knapp, mit faktischen Korrekturen statt Methodendiskussionen. Die Schichten müssen getrennt bleiben: Wenn man auf strategischer Ebene konkrete Implementierungsdetails verhandelt, ist die Aufgabe entweder zu klein für die Methode oder man ist in der falschen Schicht. Die Trennung der Schichten ist die zentrale Disziplin von Plan-to-Plan.
Positionierung im Spec-Driven Development
Plan-to-Plan ist keine Konkurrenz zu Spec-Driven Development, sondern eine Erweiterung. Wer SpecKit nutzt, kann Plan-to-Plan sozusagen vor specify schalten. Die `specify`-Stufe dient dann nicht mehr der strategischen Entscheidung, sondern ist reine Übersetzung des Konzepts in eine technische Spezifikation. Das macht specify schärfer, weil die strategischen Annahmen vorher geklärt sind.
Ein zweites Tool, das in diesem Kontext erwähnt werden muss, ist die BMAD-Method. BMAD hat de facto bereits eine zweistufige Planungslogik, nur in Multi-Agent-Form. Die Analyst-Phase entspricht einem Konzept-Plan, die PM- und Architect-Phasen einem Implementierungs-Plan. Wer informiert ist, wird beim ersten Lesen fragen: Ist Plan-to-Plan dann nicht einfach BMAD light?
Methodisch ist beides ähnlich, im Wie aber unterschiedlich. BMAD ist ein Framework mit zwölf Agent-Personas und YAML-Workflows, das auf Software-Engineering-Vokabular mit SCRUM-Bezug spezialisiert ist. Plan-to-Plan ist ein Pattern, das aus zwei Markdown-Plänen besteht und werkzeug-agnostisch funktioniert. Für Wissensarbeiter ist die Werkzeug-Agnostik von Plan-to-Plan der Punkt.
Es gibt mehrere weitere SDD-Tools im Feld, die ich an dieser Stelle nur nenne. AWS Kiro ist Enterprise-State-of-the-Art mit dreistufigem Workflow, aber ohne explizite Konzept-/Spec-Trennung. Tessl versteht sich als "Spec-as-Source". Und Tools wie Cline, Plandex und Google Antigravity haben einen Plan-Mode, aber kein SDD-Vokabular. Sie sind damit eher weitere Werkzeuge, mit denen Plan-to-Plan ausgeführt werden kann, nicht der methodische Rahmen.
Wo die Methode nicht passt
Plan-to-Plan ist keine Methode für alle Aufgaben. Bei einer Aufgabe wie einer Dokumentenüberarbeitung oder einem kleinen Refactoring würde die Methode einen deutlichen Overhead darstellen. Aber vor allem bei einer ungewissen Aufgabe, bei der das Ziel noch nicht genau feststeht, ist die strategische Schicht der entscheidende Hebel.
Beispiel Kundenprojekt in der Beratung: Selten stehen alle Anforderungen zu Beginn fest, dazu kommen noch politische Themen, die in einer Spec nichts verloren haben. Genau hier ist der übergeordnete Kontext der Konzeptschicht wichtig, um der Spec die nötige Tiefe zu verleihen und die nötigen Grenzen zu setzen. Damit kommen Vision und Mission des Projekts explizit zur Geltung.