Best Practices: Implementierungsplan

Implementierungspläne machen die Zusammenarbeit mit AI-Coding-Agenten steuerbar, nachvollziehbar und überprüfbar. Entscheidend sind ihr Aufbau, ihre Nutzung und die Abgrenzung zum Plan Mode.

---

Einleitung

In meinem letzten Beitrag habe ich den Bootstrap-Prompt als zentrales Steuerungsinstrument vorgestellt, um AI-Coding-Agenten mit dem nötigen Projektkontext auszustatten. Der Bootstrap beantwortet die Frage: “Was weiß der Agent?”. Er stellt sicher, dass der Agent die Architektur, Konventionen, Dokumentation und Regeln des Projekts versteht.

Der Implementierungsplan, um den es in diesem Beitrag geht, adressiert hingegen die eigentliche Umsetzung eines Features, also das “Wie”. Selbst mit einem guten Bootstrap ist nicht garantiert, dass der Agent die anstehende Implementierungsaufgabe in der gewünschten Qualität und im definierten Scope umsetzt. Statt Agenten sofort beginnen zu lassen, lassen wir sie zunächst einen Implementierungsplan erstellen, der das Feature in sequenzielle Umsetzungsschritte zerlegt. Wir Entwickler:innen bleiben als Human-in-the-Loop (HITL) verantwortlich für die Überprüfung und Freigabe der vorgeschlagenen Schritte.

Seit der Freigabe der neuesten Frontier-Modelle beobachte ich allerdings häufiger die These, dass Implementierungspläne überflüssig geworden seien. Modelle wie Claude Fable 5 oder GPT-5.6 Sol sind, Stand Juli 2026, tatsächlich in der Lage, auch komplexe Features ohne Plan zu implementieren. Ob daraus folgt, dass wir auf den Plan als Kontrollinstrument verzichten sollten, betrachte ich in diesem Beitrag differenzierter.

Was ist ein Implementierungsplan?

Ein Implementierungsplan ist ein Markdown-Dokument oder ein spezielles Artefakt im verwendeten Tool, das ein Feature in sequenzielle Aufgaben für einen AI-Agenten zerlegt. Die Aufgaben beschreiben die notwendigen Umsetzungsschritte in einem, nun ja, “vernünftigen” Detailgrad. Tatsächlich ist es in der Praxis nicht ganz einfach, das richtige Maß zu finden. Implementierungspläne werden nicht manuell, sondern von Agenten erstellt. Diese neigen, je nach Modell und eingestelltem Reasoning-Aufwand, zu mehr oder weniger detailliert ausgearbeiteten Umsetzungsschritten. Meiner Erfahrung nach ist ein zu detaillierter Plan allerdings kontraproduktiv. Er kann dazu führen, dass die KI während der Umsetzung des Plans versucht, diesen strikt einzuhalten, ohne das Gesamtbild zu verstehen oder sinnvolle Alternativen zu betrachten. Er ähnelt damit einem schlecht geschriebenen Ticket mit zu vielen Details “up-front”. Viele Details ergeben sich erst während der Umsetzung, wenn die KI das Feature in der Codebasis verankert und die relevanten Schnittstellen und Patterns erkennt. Ein zu detaillierter Plan kann also die Kreativität der KI einschränken und zu suboptimalen Lösungen führen. Tatsächlich vermute ich, dass diese Problematik der Grund ist, warum in Teilen der Community empfohlen wird, Frontier-Modelle ohne Plan arbeiten zu lassen. Ein “schlechter” Plan ist schlimmer als gar kein Plan.

Ein guter Plan gliedert ein Feature auf einer sinnvollen Abstraktionsebene in die relevanten Umsetzungsschritte. Beispielsweise legt der Plan in einer Backend-Anwendung mit mehreren Schichten fest, in welcher Schicht die Umsetzung beginnt (Top-Down oder Bottom-Up), ob zuerst Testfälle geschrieben werden und auf welche Art und Weise Schnittstellen angesprochen werden. Der Plan enthält aber keine konkreten Klassen- oder gar Methodennamen. Diese Details ergeben sich erst während der Umsetzung. Ein guter Plan beschreibt also die Architektur der Umsetzung, nicht die konkrete Implementierung. Am einfachsten erreicht man dieses Ziel, indem man die Modellierungsregeln für Implementierungspläne aufschreibt und der KI als Referenz mitgibt.

Elemente eines Implementierungsplans

Wie schon erwähnt, muss der Plan insbesondere die relevanten Umsetzungsschritte und deren Reihenfolge festlegen. Jeder Schritt im Plan sollte enthalten:

• Ziel: Einzeiliger Satz, was mit dem Umsetzungsschritt erreicht werden soll
• Scope: Konkrete Auflistung, welcher Teil der Feature-Spezifikation in diesem Schritt umgesetzt wird (z. B. “Implementierung der API-Endpunkte für die Umfrageverwaltung”, “Erstellung der Unit-Tests für die Validierung der Eingaben”)
• Nicht im Scope: Explizite Abgrenzung von dem, was nicht umgesetzt wird (z. B. “Keine Änderungen an der Datenbankstruktur”, “Keine Änderungen an bestehenden Schnittstellen”)
• Akzeptanzkriterien: Messbare Done-When-Bedingungen für den Schritt (z. B. “Alle Unit-Tests laufen erfolgreich”, “Die API liefert die erwarteten Ergebnisse: x, y, z”)
• Entscheidungen: Agenten fragen bei der initialen Erstellung eines Implementierungsplans oft nach Entscheidungen, die sie nicht selbst treffen können. Unsere Antworten darauf sollten im Plan dokumentiert werden, damit sie für die Umsetzung und spätere Reviews nachvollziehbar sind.
• Referenzdokumente: Verweise auf Feature-Spec, Datenmodell, Architektur, etc.

Ein Beispiel für einen Implementierungsplan findet sich unter diesem Link: Implementierungsplan für das Feature “Survey Management”.

Braucht man Pläne auch in Zukunft noch?

Wie ich weiter oben schon erwähnt habe, mehren sich in der Praxis die Stimmen, die bei den neuesten Frontier-Modellen auf einen Implementierungsplan verzichten wollen. Die Begründung: Die Modelle sind so leistungsfähig, dass sie auch komplexe Features ohne Plan umsetzen können. Ich sehe das differenzierter. Frontier-Modelle können komplexe Features ohne Plan umsetzen, die Qualität hängt aber stark von der Qualität des Prompts und der Anforderungen ab (in unserem Fall also von der Feature-Datei).

Ohne Implementierungsplan entfällt ein früher Prüfpunkt für das gemeinsame Verständnis von Anforderungen, Scope und Umsetzungsstrategie. Missverständnisse fallen dann unter Umständen erst beim Code-Review auf. Der Abgleich eines kompakten Plans mit den Anforderungen ist in der Praxis meist einfacher als der vollständige Abgleich eines umfangreichen Diffs. Ein Plan garantiert keine gute Implementierung, macht problematische Annahmen aber früher sichtbar.

Auch die Kostenfrage ist relevant. Die Erstellung und Prüfung eines Plans kostet zunächst Zeit und Tokens. Bei komplexen oder risikoreichen Features kann sich dieser Aufwand auszahlen, weil Fehlentwicklungen erkannt werden, bevor umfangreicher Code und teure Rework-Sessions entstehen. Für kleine, klar umrissene Änderungen kann der Planungsaufwand dagegen höher sein als sein Nutzen. Ein Implementierungsplan ist daher kein automatischer Kostensenker, sondern ein Instrument zur Begrenzung des Rework-Risikos.

Noch vor sechs Monaten habe ich einen Plan für praktisch jede Implementierungsaufgabe empfohlen. Mittlerweile halte ich ihn vor allem bei komplexen oder architektonisch relevanten Änderungen für notwendig. Bei einfachen Aufgaben kann ein leistungsfähiges Frontier-Modell direkt mit der Umsetzung beginnen. Diese Grenze wird sich mit zunehmender Modellleistung vermutlich weiter verschieben. Gut möglich, dass wir in absehbarer Zukunftr auch komplexe Features ohne Plan umsetzen können.

Plan Mode vs. Implementierungsplan als Markdown

Eine weitere praktische Frage betrifft die Form des Implementierungsplans. In den letzten Monaten haben einige Anbieter von AI-Coding-Agenten sogenannte Plan Modes eingeführt. Dabei handelt es sich um native Funktionen, mit denen ein Plan direkt im Tool erstellt, überprüft und anschließend umgesetzt werden kann. Dadurch wird der Wechsel zwischen Planung und Implementierung flüssiger.

Native Plan Modes und Markdown-Pläne schließen einander allerdings nicht aus. Wie dauerhaft und teilbar ein Plan ist, hängt vom jeweiligen Tool ab: Manche Werkzeuge halten ihn primär in der Session, andere können ihn im Workspace speichern oder erzeugen von vornherein eine Datei. Cursor kann Pläne beispielsweise in den Workspace übernehmen, Codex kombiniert Plan Mode bei Bedarf mit einem PLANS.md-Workflow, und Amazon Kiro erzeugt im Spec-Workflow eine versionierbare Tasks.md-Datei.

Tools wie Amazon Kiro und Google Antigravity bieten zudem gut integrierte Review-Möglichkeiten, über die sich einzelne Umsetzungsschritte kommentieren, genehmigen oder ablehnen lassen. Die Arbeit im Plan Mode geht dadurch häufig schneller von der Hand als ein vollständig manueller Markdown-Workflow.

Ein bewusst im Projekt abgelegter und versionierter Markdown-Plan bleibt dennoch unabhängig vom eingesetzten Tool. Das Team kann ihn gemeinsam prüfen, Agenten können über mehrere Sessions hinweg darauf zugreifen, und er dokumentiert Entscheidungen für spätere Reviews oder Audits. Ich persönlich bevorzuge deshalb bei komplexen Features weiterhin einen versionierten Markdown-Plan.

Fazit

Ein Implementierungsplan ist zumindest Stand heute ein wertvolles Werkzeug, um die Zusammenarbeit mit AI-Coding-Agenten zu steuern und Missverständnisse vor der eigentlichen Implementierung sichtbar zu machen. Auch wenn Frontier-Modelle komplexe Features ohne Plan umsetzen können, bietet ein gut strukturierter Plan Vorteile bei Kontrolle, Nachvollziehbarkeit und Teamkommunikation. Ob der Aufwand gerechtfertigt ist, hängt nicht nur von der Modellleistung ab, sondern auch von Komplexität, Unsicherheit und Risiko der Änderung.