Planen statt drauflos.

5.1 Warum Agenten Planung brauchen

Mit Agenten ist die Versuchung groß, Planung zu überspringen. Der Agent ist schnell, er kann „einfach anfangen“, und ein großer Auftrag scheint Zeit zu sparen. In der Praxis kehrt sich das um. Je größer und offener ein Auftrag, desto mehr Entscheidungen trifft der Agent allein — und desto größer und schwerer prüfbar wird das Ergebnis.

Die Gründe dafür sind strukturell:

• Fehler verketten sich. Ein Agent arbeitet in einer Schleife aus Lesen, Handeln und Beobachten (Kapitel 2). Eine frühe Fehlannahme fließt in alle späteren Schritte ein. Bei einer kleinen Aufgabe ist die Kette kurz, bei einer großen lang.
• Der Kontext füllt sich. Lange Läufe sammeln Dateien, Befehlsausgaben und Zwischenstände an. Mit wachsendem Verlauf steigen Kosten und das Risiko, dass frühere Vorgaben aus dem Blick geraten.
• Reviews skalieren nicht. Einen Diff von 80 Zeilen liest ein Mensch gründlich. Einen Diff von 3 000 Zeilen überfliegt er. Eine Prüfung, die nicht stattfindet, ist keine.
• Rückgängig machen wird teuer. Ist eine kleine Aufgabe falsch umgesetzt, verwirfst du einen Branch. Ist ein Großauftrag zur Hälfte falsch, musst du gutes von schlechtem Ergebnis trennen.

Planung ist bei Agenten deshalb kein bürokratischer Vorlauf, sondern das Werkzeug, mit dem du die Größe jeder einzelnen Entscheidung kontrollierst. Die Faustregel: Eine Aufgabe ist richtig geschnitten, wenn du ihr Ergebnis in einem Review vollständig beurteilen kannst.

5.2 Zerlegung: vertikal statt horizontal

Es gibt zwei grundsätzliche Arten, ein Vorhaben zu zerlegen.

• Horizontal (nach Schichten): „Erst das Datenbankschema, dann alle Repositories, dann alle Services, dann alle Controller, dann die Oberfläche.“ Jede Aufgabe ist technisch homogen, aber keine liefert für sich genommen etwas Nutzbares. Fehler in der Schnittstelle zwischen den Schichten fallen erst ganz am Ende auf.
• Vertikal (nach Nutzen): „Erst ‚Auftrag anlegen‘ von der Datenbank bis zur Oberfläche, dann ‚Aufträge auflisten‘, dann ‚Auftrag zuweisen‘.“ Jede Aufgabe ist ein dünner, durchgehender Schnitt, der sich end-to-end testen lässt.

Für Agenten ist die vertikale Zerlegung fast immer besser. Jede Aufgabe lässt sich mit einem echten Test belegen, jeder Merge hinterlässt ein lauffähiges System, und Abweichungen in der Architektur fallen beim ersten Schnitt auf statt beim letzten. Horizontale Aufgaben bleiben sinnvoll für echte Querschnittsthemen: ein Build-Setup, eine Migration der Testinfrastruktur, ein Sicherheits-Header für alle Endpunkte.

Grafik in voller Größe öffnenGrafik in voller Größe öffnen

Gute Schnittgrößen

Eine brauchbare Aufgabe für einen Agentenlauf hat typischerweise diese Eigenschaften:

• ein klares, in einem Satz formulierbares Ziel,
• eine überschaubare Menge betroffener Dateien oder Module,
• zwei bis sechs Akzeptanzkriterien — deutlich mehr deutet auf eine zu große Aufgabe hin,
• ein Ergebnis, das ohne die nächste Aufgabe gemergt werden kann, ohne etwas kaputtzumachen.

Spikes für Unbekanntes

Manchmal weißt du schlicht nicht, wie etwas geht: Welche Bibliothek eignet sich? Funktioniert die Anbindung an das Altsystem überhaupt? Dann ist die erste Aufgabe keine Umsetzung, sondern eine Untersuchung (Spike) mit einem klaren Ergebnis — etwa einer kurzen Entscheidungsnotiz oder einem Wegwerf-Prototyp. Erst danach planst du die eigentliche Umsetzung. Agenten sind für Spikes gut geeignet, solange das Ergebnis ausdrücklich als Erkenntnis und nicht als Produktivcode gilt.

5.3 Eine Aufgabe gut beschreiben

Eine Aufgabe ist der Auftrag für genau einen Lauf. Sie sollte so beschrieben sein, dass ein Agent sie ohne Rückfrage umsetzen und ein Mensch das Ergebnis ohne Rätselraten prüfen kann. Bewährt hat sich ein kleines, festes Schema:

Akzeptanzkriterien je Aufgabe

Das wichtigste Element sind die Akzeptanzkriterien. Sie verwandeln eine Absicht in etwas Prüfbares. Ohne sie lautet die einzige Frage nach dem Lauf „Sieht das gut aus?“ — mit ihnen lautet sie „Sind alle Kriterien belegt?“. Gute Kriterien beschreiben beobachtbares Verhalten, nicht Implementierung, und decken auch den Fehlerfall ab:

• „Wenn ein Disponent einen offenen Auftrag einem aktiven Techniker zuweist, dann soll das System den Techniker am Auftrag speichern und den Status auf ‚zugewiesen‘ setzen.“
• „Falls der Techniker deaktiviert ist, dann soll das System die Zuweisung mit einer verständlichen Meldung ablehnen.“

Das sind bereits Formulierungen nach dem EARS-Muster. Wie man solche Kriterien systematisch schreibt, mit IDs versieht und in Tests überführt, ist Thema von Kapitel 4. Für die Planung genügt: Jede Aufgabe verweist auf die Kriterien, die sie erfüllt, statt sie neu und leicht anders zu formulieren.

Definition of Done

Akzeptanzkriterien sind aufgabenspezifisch. Daneben gibt es Bedingungen, die für jede Aufgabe gelten: Build grün, Tests vorhanden und grün, keine neuen kritischen Befunde im Quality Gate, Dokumentation angepasst, wo nötig. Das ist die Definition of Done. Sie gehört einmal aufgeschrieben ins Projekt — nicht in jede Aufgabe kopiert.

5.4 Abhängigkeiten und Reihenfolge

Aufgaben sind selten völlig unabhängig. „Aufträge auflisten“ setzt „Auftrag anlegen“ voraus; „Auftrag abschließen“ braucht die Zuweisung. Solche Beziehungen bilden einen gerichteten Graphen: Jede Kante sagt „B kann erst beginnen, wenn A fertig ist“. Damit eine Reihenfolge existiert, darf dieser Graph keine Zyklen enthalten — hängt A von B und B von A ab, kann keine von beiden je starten. Man spricht von einem DAG (directed acyclic graph).

Grafik in voller Größe öffnenGrafik in voller Größe öffnen

Was ein Abhängigkeitsgraph leistet

• Reihenfolge: Aus dem Graphen ergibt sich, welche Aufgaben jetzt startbar sind — alle, deren Vorgänger erledigt sind.
• Parallelität: Aufgaben ohne gegenseitige Abhängigkeit könnten gleichzeitig laufen. Wann das sicher ist, behandelt Kapitel 7.
• Risiko: Aufgaben, von denen viele andere abhängen, verdienen besondere Sorgfalt. Ein Fehler dort blockiert alles dahinter.

Was „erledigt“ bedeutet

Eine scheinbar kleine Frage mit großer Wirkung: Ist eine Aufgabe erledigt, wenn der Agent Code geschrieben hat? Wenn der Build grün ist? Oder erst, wenn das Ergebnis im Hauptzweig liegt? Für Abhängigkeiten zählt nur Letzteres. Baut B auf A auf und A liegt noch auf einem Branch, arbeitet B gegen einen Stand, den es im Hauptzweig nicht gibt. „Erledigt“ sollte deshalb „gemergt“ heißen.

Abhängigkeiten minimieren

Jede Abhängigkeit schränkt die Reihenfolge ein und verlängert den kritischen Pfad. Gute Planung versucht, sie zu reduzieren: durch einen frühen, kleinen Schnitt, der eine gemeinsame Grundlage schafft (etwa das Datenmodell des Kernobjekts), durch klare Schnittstellen zwischen Modulen oder durch vorab vereinbarte Verträge. Letzteres ist das Fundament paralleler Arbeit in Kapitel 7.

5.5 Plan und Anforderung verbinden

Ein Plan beschreibt, was als Nächstes gebaut wird. Eine Anforderung beschreibt, was gelten muss. Beide sind verwandt, aber nicht dasselbe: Eine Anforderung kann über mehrere Aufgaben verteilt umgesetzt werden, und eine Aufgabe kann mehrere Anforderungen bedienen. Wenn Akzeptanzkriterien nur im Fließtext der Aufgabe stehen, entstehen zwei Probleme:

• Doppelte Wahrheit: Die Aufgabe formuliert das Kriterium leicht anders als die Anforderung. Welche Fassung gilt?
• Keine Nachverfolgbarkeit: Ändert sich die Anforderung, weiß niemand, welche geplanten Aufgaben betroffen sind.

Die Lösung ist, Aufgaben per ID auf Anforderungen zu verweisen statt sie abzuschreiben: „Diese Aufgabe setzt AC-012-03 und AC-012-04 aus SPEC-012 um.“ Dann gibt es genau eine Formulierung, und bei Änderungen ist berechenbar, welche Aufgaben betroffen sind. Das ist der Kern der Traceability, die Kapitel 4 ausführlich behandelt.

5.6 Meilensteine und Releases

Aufgaben sind die kleinste Planungseinheit, Meilensteine die nächstgrößere. Ein Meilenstein bündelt mehrere Aufgaben zu einem Stand, der für Nutzer eine Bedeutung hat — typischerweise eine Version. Meilensteine beantworten Fragen, die Aufgaben allein nicht beantworten:

• Was gehört in die nächste Version, was nicht?
• Wann ist die Version fertig? (Wenn alle zugeordneten Aufgaben erledigt sind.)
• Was hat sich gegenüber der letzten Version geändert? (Der Changelog.)

Ein sauberer Release-Prozess macht aus einem Meilenstein drei Dinge: einen Changelog-Eintrag, der die erledigten Aufgaben zusammenfasst, eine unveränderliche Markierung im Versionskontrollsystem (ein Git-Tag) und gegebenenfalls eine Veröffentlichung auf der Plattform des Git-Hosts. Wichtig ist die Unveränderlichkeit: Ein freigegebener Stand wird nicht nachträglich umgeschrieben; Korrekturen kommen in die nächste Version.

Zeitliche Rhythmen

Neben inhaltlich getriebener Planung gibt es zeitliche Rhythmen: eine wöchentliche Planungsrunde, ein nächtlicher Lauf, der Abhängigkeiten aktualisiert, eine regelmäßige Bestandsaufnahme technischer Schulden. Solche Routinen lassen sich automatisieren. Die Grenze ist dieselbe wie überall in diesem Kurs: Automatisierung ersetzt nicht die menschlichen Freigabepunkte, sondern sorgt dafür, dass zu diesen Punkten verlässlich etwas Prüfbares vorliegt.

5.7 Typische Planungsfehler

5.8 Zusammenfassung

• Kleine, abgegrenzte Aufgaben machen Agentenarbeit zuverlässig und prüfbar. Eine Aufgabe ist richtig geschnitten, wenn ihr Ergebnis in einem Review vollständig beurteilbar ist.
• Vertikale Zerlegung liefert mit jeder Aufgabe einen testbaren Nutzen; Spikes klären Unbekanntes vor der Umsetzung.
• Jede Aufgabe hat Titel, Begründung, Umfang, Akzeptanzkriterien und Aufwand; die Definition of Done gilt für alle.
• Abhängigkeiten bilden einen zyklenfreien Graphen; „erledigt“ heißt „gemergt“.
• In der Fabrik schlägt ein Plan-Run Aufgaben als plans/NNNN-*.md vor, ohne Code zu übernehmen; das Backlog verwaltet Status, Abhängigkeiten und Spec-Bezug; Aktivieren startet einen Build-Run; Meilensteine erzeugen Changelog, Tag und optional ein GitHub-Release; Routinen und Auto-Folgevorschläge schließen den Loop.

Kapitelfragen

1. Nenne drei strukturelle Gründe, warum Agenten mit kleinen Aufgaben zuverlässiger arbeiten als mit großen.

   Musterantwort

   Fehler verketten sich in der Agenten-Schleife — bei kleinen Aufgaben ist die Kette kurz. Der Kontext füllt sich bei langen Läufen mit Zwischenständen, was Kosten und das Risiko erhöht, frühere Vorgaben zu übersehen. Reviews skalieren nicht: Kleine Diffs werden gründlich geprüft, große überflogen. Außerdem ist das Verwerfen einer kleinen, falschen Aufgabe billig.

2. Was ist der Unterschied zwischen vertikaler und horizontaler Zerlegung, und wann ist horizontal trotzdem sinnvoll?

   Musterantwort

   Horizontal wird nach technischen Schichten geschnitten (erst alle Datenbanktabellen, dann alle Services …), vertikal nach Nutzen (ein Anwendungsfall durch alle Schichten). Vertikale Aufgaben sind einzeln testbar und mergebar und decken Schnittstellenfehler früh auf. Horizontal ist sinnvoll für echte Querschnittsthemen wie Build-Setup, Test-Infrastruktur oder einen Sicherheits-Header für alle Endpunkte.

3. Worin unterscheiden sich Akzeptanzkriterien und Definition of Done?

   Musterantwort

   Akzeptanzkriterien sind aufgabenspezifisch und beschreiben beobachtbares Verhalten, das diese Aufgabe liefern muss. Die Definition of Done gilt für jede Aufgabe gleich und beschreibt den Abgabezustand (Build grün, Tests vorhanden, Gate ohne kritische Befunde, Doku angepasst). In der Fabrik liegt die Definition of Done als DEFINITION_OF_DONE.md im Projekt.

4. Was passiert in der Fabrik am Ende eines Plan-Runs, wenn der Agent entgegen der Direktive auch eine Java-Datei geändert hat?

   Musterantwort

   Die Fabrik committet am Ende eines Plan-Runs ausschließlich die Dateien unter plans/ und verwirft alle anderen Änderungen. Die Java-Änderung landet also nicht im Workspace-Stand. Ein Build-Gate läuft beim Plan-Run nicht; die Pläne werden als Backlog-Items indexiert und der Run abgeschlossen.

5. Warum sollte eine Aufgabe erst als erledigt gelten, wenn sie gemergt ist, und wie setzt die Fabrik das um?

   Musterantwort

   Abhängige Aufgaben bauen auf dem Hauptzweig auf. Liegt die Vorarbeit nur auf einem Branch, arbeitet die Folgeaufgabe gegen einen Stand, den es dort nicht gibt. Die Fabrik setzt ein Backlog-Item automatisch erst auf DONE, wenn sein Build-Run gemergt ist (im PR-Modus nur mit aktivierter PR-Rückkopplung; sonst zählt schon das Eröffnen des PR); ein Item mit nicht erledigtem Blocker lässt sich nicht aktivieren.

6. Du versuchst, Item A als Blocker von Item B einzutragen, obwohl B bereits (über C) ein Blocker von A ist. Was passiert, und warum ist das sinnvoll?

   Musterantwort

   Die Fabrik lehnt die Abhängigkeit mit dem Hinweis ab, dass sie einen Zyklus erzeugen würde; sie prüft auch indirekte Zyklen. Das ist sinnvoll, weil in einem zyklischen Abhängigkeitsgraphen keine der beteiligten Aufgaben je aktivierbar wäre — es gäbe keine gültige Reihenfolge.

7. Ein Projekt steht im Spec-Modus STRENG. Ein Plan-Run erzeugt einen Plan mit Spec: SPEC-004 und AC: AC-004-07, aber SPEC-004 hat nur einen Entwurf. Was zeigt das Backlog, und was passiert beim Aktivieren?

   Musterantwort

   Das Backlog zeigt am Item einen Hinweis, dass die Spec keine freigegebene Fassung hat. Im Modus STRENG lehnt die Fabrik die Aktivierung ab, bis eine Fassung von SPEC-004 freigegeben ist, die AC-004-07 enthält. Im Modus LEICHT wäre es nur ein Hinweis; der Build-Run liefe dann ohne Spec-Bindung.

8. Warum ist es besser, wenn ein Plan Akzeptanzkriterien per ID referenziert, statt sie im Fließtext zu wiederholen?

   Musterantwort

   Es gibt dann nur eine verbindliche Formulierung (in der Spec) statt zweier, die auseinanderlaufen können. Außerdem ist berechenbar, welche Aufgaben von einer Änderung der Anforderung betroffen sind, und die Kette lässt sich bis in Commits, Tests und den Warum-Trace verfolgen.

9. Dein Team möchte, dass „die Fabrik einfach jede Nacht weiterarbeitet“. Welche Bausteine würdest du kombinieren, und welche Vorkehrungen triffst du?

   Musterantwort

   Eine Routine (/projects/{id}/routines) mit Cron-Ausdruck, etwa ein nächtlicher Plan-Run, gegebenenfalls ergänzt um Auto-Folgevorschläge (run.auto-followup-plan) nach erfolgreichen Build-Runs. Vorkehrungen: Budgets bzw. Token-Limits setzen, Freigabepunkte (vor Ausführung, vor Merge) aktiv lassen, damit nichts ungeprüft gemergt wird, und feste Zeit zum Sichten des Backlogs einplanen. BUILD-Routinen nur mit klar abgegrenztem Fokus, weil sie ohne Planfreigabe Code erzeugen.

10. Was erzeugt die Fabrik beim Release eines Meilensteins, und was ist anders, wenn keine GitHub-Remote gesetzt ist?

    Musterantwort

    Sie erzeugt aus den erledigten Items des Meilensteins einen Changelog-Abschnitt in der CHANGELOG.md des Workspace, committet ihn und setzt einen Git-Tag v<Zielversion>; der Meilenstein geht auf RELEASED. Mit GitHub-Remote und Token pusht sie den Tag und legt zusätzlich ein GitHub-Release an. Ohne Remote bleibt es bei lokalem Tag und Changelog.