Die Macher – Realisierungsplan & Developer

Im vorherigen Post habe ich den Business Analysten und den Solution Architect vorgestellt – die Planungsphase meines Agenten-Teams. Sie produzieren keine einzige Zeile produktiven Code, aber sie legen die Grundlage für alles, was danach kommt: ein strukturiertes Use-Case-Dokument und ein technisches Lösungskonzept, das als Blaupause dient.

In diesem Post kommt der dritte und vierte Teil des Teams: der Realisierungsplan-Agent und der Developer-Agent. Sie sind die Macher – und gerade deshalb liegt die eigentliche Herausforderung nicht bei ihnen, sondern bei der Frage, wie man sie richtig einsetzt.

Das Problem nach dem Konzept

Man könnte meinen, mit einem fertigen Lösungskonzept sei die schwierige Arbeit getan. Der Developer-Agent bekommt das Dokument, liest es durch und setzt es um. Einfach.

In der Praxis funktioniert das nicht.

Ein Lösungskonzept ist eine Blaupause. Es beschreibt den Soll-Zustand – Klassendiagramme, Schemaänderungen, Sequenzdiagramme, einen Maßnahmenkatalog mit zehn oder zwanzig Punkten. Das ist exakt die Informationsmenge, die ein menschlicher Entwickler braucht, um eine gute Implementierung zu planen. Aber für einen Coding-Agenten mit einem begrenzten Kontextfenster ist dieselbe Informationsmenge ein Problem.

Das Modell liest das Konzept, beginnt mit der Implementierung – und verliert dabei den Überblick. Nicht sofort. Aber spätestens nach der dritten Änderung in der vierten Datei beginnt das, was die Forschung als „Context Rot" bezeichnet: Der frühe Teil des Konzepts, die Architekturentscheidungen vom Anfang, die Cleanup-Hinweise aus Seite zwei – sie sinken in der Aufmerksamkeit des Modells, weil der Code, den es gerade schreibt, das Kontextfenster dominiert. Was übrig bleibt, ist ein Coding-Agent, der im Großen und Ganzen auf dem richtigen Weg ist, aber im Detail immer mehr improvisiert.

Das ist das Fokus-Problem aus dem Post über die vier systemischen Schwächen – aber eine Ebene tiefer. Nicht mehr auf der Ebene des einzelnen Prompts, sondern auf der Ebene einer mehrstufigen Implementierungsaufgabe.

Der Realisierungsplan-Agent: Der atomare Schlachtplan

Die Antwort auf dieses Problem ist kein besseres Prompting und kein längeres Konzept. Die Antwort ist ein weiterer Schritt der Zerlegung.

Der Realisierungsplan-Agent nimmt das Lösungskonzept des Solution Architects und verwandelt es in einen atomaren, schrittweisen Implementierungsplan. Sein Output landet als Markdown-Datei unter docs/plan/. Das klingt nach noch mehr Dokumentation – und genau da liegt der entscheidende Unterschied zum klassischen Dokumentations-Overhead, der nie gelesen wird.

Dieser Plan ist keine Zusammenfassung. Er ist ein Ausführungsskript.

Jeder Schritt im Plan enthält:

• Betroffene Datei(en) mit vollständigem Pfad
• Eine Checkliste mit konkreten Aufgaben, die der Developer-Agent abhaken kann
• Vorher/Nachher-Codebeispiele, wenn die Änderung komplex ist
• Einen Validierungsbefehl – ein konkretes npm run build oder Type-Check-Kommando, das nach diesem Schritt grün sein muss
• Manuelle Verifikation – eine Tabelle: welche Aktion führt der Nutzer aus, was ist das erwartete Ergebnis
• Cleanup – welcher Code, welche Imports, welche temporären Workarounds sind durch diesen Schritt obsolet geworden
• Eine Risikoeinschätzung – von „keins" bis „hoch"

Und die wichtigste Eigenschaft dieses Plans: Nach jedem abgeschlossenen Schritt befindet sich die Anwendung in einem lauffähigen Zustand. Kein Schritt bricht den Build. Kein Schritt hinterlässt halbfertige Abhängigkeiten. Das ist kein Zufall, sondern eine explizite Anforderung an den Agenten, die er beim Erstellen des Plans einhalten muss.

Das klingt nach Aufwand. Es ist auch Aufwand – aber er entsteht einmal, im Voraus, in einer Phase, in der Korrekturen billig sind. Nicht verteilt über eine chaotische Implementierung, in der jeder Fehler erst durch npm run build ans Licht kommt.

Eine Idee, die ich mir geborgt habe

Dieser Ansatz ist nicht aus dem Nichts entstanden. Ich habe mir verschiedene Konzepte angeschaut, die in der Community rund um KI-gestützte Entwicklung entstanden sind – darunter das GitHub Spec-Kit, ein Framework, das den Gedanken des Spec-Driven Development (SDD) formalisiert.

Der Kerngedanke von SDD ist präzise: Bevor der Coding-Agent auch nur eine Zeile schreibt, wird eine hochpräzise Spezifikation erstellt – eine Leitplanke, die verhindert, dass das Modell rät, improvisiert oder Annahmen trifft, die später korrigiert werden müssen.

Ich habe das Spec-Kit ausprobiert und war von diesem Grundprinzip sofort überzeugt. Nicht alles davon war jedoch für mich direkt relevant. Ich habe deshalb die Aspekte übernommen, die für meine Situation passen, und den Rest weggelassen: konkret die Idee, dass der Coding-Agent eine fertige Spezifikation als Leitplanke bekommt, nicht eine vage Aufgabenbeschreibung.

Der Realisierungsplan ist meine Version dieser Spezifikation. Er ist enger, konkreter und auf meinen Stack zugeschnitten – aber er folgt demselben Grundprinzip: Die KI soll nicht raten. Sie soll ausführen.

Der Developer-Agent: Präzisionswerkzeug, kein kreativer Freigeist

Mit dem fertigen Plan bekommt der Developer-Agent nicht mehr das gesamte Lösungskonzept als Kontext. Er bekommt genau einen Schritt. Den aktuellen Schritt. Und sonst nichts.

Das ist Absicht.

Ein Developer-Agent, der das gesamte Lösungskonzept kennt, beginnt zu optimieren. Er sieht, dass Schritt 7 eigentlich gut zu Schritt 3 passen würde, und zieht sie zusammen. Er merkt, dass es eine elegantere Lösung gäbe, wenn man die Reihenfolge tauscht – und ändert sie, ohne zu fragen. Er improvisiert die Architektur, weil er glaubt, das große Bild zu sehen.

Das ist genau das Verhalten, das mich Stunden gekostet hat. Es ist der Coding-Agent als kreativer Freigeist – und Kreativität ist in der Implementierungsphase das Letzte, was ich brauche.

Ein Developer-Agent mit einem einzigen Schritt als Kontext kann das nicht. Er liest die Aufgabe, führt sie aus, hakt die Checkliste ab, führt den Validierungsbefehl aus und wartet. Er macht keine architektonischen Entscheidungen, weil keine zu machen sind. Die Entscheidungen wurden bereits im Konzept und im Plan getroffen.

Was dieser Agent stattdessen sehr gut kann: strikte Einhaltung von Coding-Guidelines, TypeScript-Typisierung ohne Abkürzungen, Cleanup nach jeder Änderung, Rückfragen wenn die Aufgabe ambivalent ist. Alles innerhalb eines fokussierten, kleinen Kontexts – und genau das ist seine Stärke.

Human-in-the-Loop: Ein neues Muster auf der Umsetzungsebene

Im Post über die Strategen habe ich beschrieben, wie der Human-in-the-Loop-Checkpoint auf Konzept-Ebene funktioniert: Ich reviewe einen Use Case und ein Lösungskonzept – Dokumente, die ich beurteilen kann, bevor auch nur eine Zeile Code entsteht.

Auf der Umsetzungsebene ist das Muster ähnlich, aber mit einem entscheidenden Unterschied.

Der Realisierungsplan ist kein abstrakter Architektur-Entwurf mehr. Er ist konkret: Diese Datei. Diese Funktion. Diese drei Zeilen, die sich ändern. Dieser Befehl, der danach grün sein muss. Ich kann den Plan lesen und sofort beurteilen, ob er plausibel ist – ohne den Code dafür zu lesen. Ich sehe, ob die Reihenfolge der Schritte Sinn ergibt, ob eine Abhängigkeit fehlt, ob ein Risiko unterschätzt wurde.

Das ist der Checkpoint, an dem ich eingreife: nicht auf Code-Ebene, sondern auf Plan-Ebene, bevor der Developer-Agent die erste Zeile schreibt.

Danach läuft der Developer-Agent Schritt für Schritt durch den Plan. Und nach jedem Schritt ist die Anwendung lauffähig – was bedeutet, dass ich nicht warten muss, bis alles fertig ist, um zu sehen, ob die Richtung stimmt. Ich kann nach Schritt 3 unterbrechen, die Änderungen anschauen, und entscheiden: weiter, oder Richtungskorrektur?

Das ist ein anderes Muster als das klassische Code-Review am Ende. Es ist kein Durchwinkeln von tausend Zeilen, die bereits geschrieben sind und kaum noch geändert werden können, ohne alles neu zu machen. Es ist eine iterative Kontrolle in einem Tempo, das ich selbst bestimme.

Warum das kein Kontrollproblem ist, sondern ein Steuerproblem

Hier ist der Punkt, den ich lange nicht klar genug formulieren konnte: Ich reviewe nicht, um Fehler zu finden. Ich reviewe, um die Richtung zu halten.

Ein Developer-Agent, der strikt nach Plan arbeitet, macht selten technische Fehler im engeren Sinne. Er schreibt keinen kaputten Code. Was er tut, ist auf sehr kleiner Ebene zu interpretieren: Wenn die Aufgabe „extrahiere diese Logik in ein Composable" lautet und es zwei Wege gibt, das zu tun, wählt er einen. Nicht den falschen – aber vielleicht nicht meinen.

Der Human-in-the-Loop-Checkpoint erlaubt es mir, diese kleinen Interpretationsentscheidungen zu sehen, bevor sie sich über zehn Schritte hinweg zu einer Abweichung summieren, die ich später nicht mehr nachvollziehen kann. Es ist weniger Fehlerkorrektur als Kurshaltung.

Und das ist ein fundamentaler Unterschied zu dem, was ich früher gemacht habe: dem Agenten alles auf einmal geben, am Ende schauen, was dabei herausgekommen ist, und dann stundenlang in einem Diff aus 800 geänderten Zeilen suchen, wo es schiefgelaufen ist.

Ja, es ist auch ein Workaround

Wie schon im vorherigen Post angesprochen, ist auch dieser Schritt eine Reaktion auf die begrenzten Kontextfenster heutiger Modelle. Der Realisierungsplan-Agent löst das Problem nicht durch bessere Prompts, sondern durch Zerlegung: Statt das Modell zu zwingen, ein komplexes Konzept als Ganzes zu verarbeiten, bekommt es die kleinstmögliche sinnvolle Einheit – einen Schritt, einen Validierungsbefehl, einen definierten Endzustand.

Das ist ein Workaround, aber einer, der funktioniert. Und „es funktioniert" ist im Engineering das entscheidende Kriterium. Ob künftige Modelle diese Zerlegung überflüssig machen, weiß ich nicht. Heute ist sie die zuverlässigste Methode, die ich gefunden habe.

Was das in der Praxis bedeutet

Ich möchte das Muster einmal konkret durchdeklinieren, damit der Ablauf greifbar wird.

Ausgangslage: Das Lösungskonzept vom Solution Architect liegt unter docs/loesungskonzept/. Es beschreibt eine neue Feature-Implementation in zwölf Maßnahmen, verteilt auf drei Schichten – Datenbank, Backend und Frontend.

Schritt 1: Der Realisierungsplan-Agent liest das Konzept und analysiert die bestehende Codebase. Er erstellt einen Plan unter docs/plan/ mit achtzehn konkreten Schritten, gruppiert in drei Phasen. Jede Phase hinterlässt einen lauffähigen Build.

Schritt 2: Ich lese den Plan. Nicht den Code – den Plan. Das dauert zehn Minuten. Ich stelle fest, dass Schritt 9 eine Abhängigkeit annimmt, die so im Konzept nicht beschrieben war. Ich ergänze eine Anmerkung, der Realisierungsplan-Agent korrigiert den Schritt.

Schritt 3: Der Developer-Agent bekommt Schritt 1 des Plans als Kontext. Er führt die Aufgaben aus, hakt die Checkliste ab, führt npm run build aus – grün. Er wartet.

Schritt 4: Ich schaue mir die Änderungen an. Eine Datei, drei Funktionen, ein neuer Typ. Alles wie geplant. Ich gebe den nächsten Schritt frei.

Das ist kein Schnellverfahren. Für ein kleines, isoliertes Feature ist es eindeutig Overkill. Aber für eine mittlere bis große Implementierung, die mehrere Schichten betrifft und in eine gewachsene Codebase integriert werden muss, ist es die Methode, die am Ende weniger Zeit kostet – weil Architekturbrüche, Duplikationen und Regelverstöße gar nicht erst entstehen.

Fazit

Der Business Analyst und der Solution Architect stellen sicher, dass das Richtige geplant wird. Der Realisierungsplan-Agent stellt sicher, dass der Plan umsetzbar ist. Der Developer-Agent stellt sicher, dass der Plan tatsächlich umgesetzt wird – Schritt für Schritt, validiert, ohne Improvisation.

Jeder dieser Agenten tut genau eine Sache. Kein Agent muss alles wissen. Kein Agent muss das große Bild im Blick behalten – das tue ich.

Das ist der Kern des Human-in-the-Loop-Prinzips, wie ich es verstehe: nicht als Misstrauensvotum gegenüber der KI, sondern als bewusste Entscheidung, die kognitiven Stärken von Mensch und Modell an den richtigen Stellen einzusetzen. Das Modell ist gut im Ausführen fokussierter Aufgaben. Der Mensch ist gut im Beurteilen von Richtung, Kontext und Intention. Beides zusammen ist stärker als jedes von beiden allein.

Im nächsten Post zeige ich, wie dieses Vier-Agenten-Team durch einige spezialisierte Ergänzungen abgerundet wird – und wo die Grenzen des ganzen Ansatzes liegen.