Plan Mode und agentische Workflows

Plan Mode und agentische Workflows

0:00 Es gibt eine Versuchung, der fast jeder erliegt, der zum ersten Mal mit einem Coding-Agenten arbeitet: Man beschreibt kurz, was man will, und schaut zu, wie Code entsteht. Das fühlt sich produktiv an. Und es geht erstaunlich oft schief — nicht weil das Modell schlecht wäre, sondern weil auf dem Weg Dutzende Entscheidungen fallen, die niemand gesehen hat.

0:19 In diesem Modul geht es darum, wie Sie diese Entscheidungen sichtbar machen, bevor sie in Code gegossen sind. Der Schlüssel ist ein eigener Arbeitsmodus, in dem der Agent liest und fragt, aber nichts ändert.

Plan Mode und agentische Workflows

0:31 Der Leitsatz dieses Moduls: Der teuerste Fehler entsteht nicht beim Programmieren, sondern beim Loslegen. Acht Kapitel führen von der Frage, warum man den Agenten bremsen sollte, über die praktische Arbeit im Plan Mode bis zu dem Kreislauf aus Analyse, Planung, Umsetzung und Review. Es geht dabei ausdrücklich nicht um Bürokratie — für einen Einzeiler ist Planen verschwendete Zeit. Es geht darum, die Grenze zu erkennen, ab der sich der Umweg lohnt.

Warum nicht sofort programmieren

0:58 Beginnen wir mit dem, was passiert, wenn ein Agent sofort losschreibt. Auf den ersten Blick ist das der schnellste Weg, und manchmal ist er es auch. Aber er hat einen Preis, der erst später sichtbar wird — nämlich im Review. Sehen wir uns an, worin dieser Preis besteht und woran Sie erkennen, ob Sie ihn in einem konkreten Fall zahlen sollten oder nicht.

1:19 Ein Agent, der sofort schreibt, trifft alle Entwurfsentscheidungen implizit und unsichtbar. Erst die Trennung von Analyse und Umsetzung macht diese Entscheidungen zu etwas, das man prüfen, verwerfen oder ändern kann. Das Bild dazu: Ein Handwerker kann direkt losbauen oder Ihnen vorher eine Skizze zeigen. Beim Bauen entsteht dasselbe Haus — nur haben Sie in einem Fall die Chance, vorher „Moment, das Fenster gehört auf die andere Seite" zu sagen.

1:45 Im anderen Fall sehen Sie die Wand, wenn sie steht. Vier Punkte. Der gewählte Ansatz erscheint erst im fertigen Diff — Sie sehen das Ergebnis, nicht die Überlegung. Missverständnisse zeigen sich nach der Arbeit statt davor, und dann sind sie teuer. Ein großes Diff wird eher überflogen als geprüft; das ist keine Charakterschwäche, sondern menschlich.

2:07 Und verworfener Code kostet Zeit auf beiden Seiten — Ihre beim Lesen, Rechenzeit beim Erzeugen. Zusammen ergibt das ein klares Muster: Alles, was schiefgehen kann, geht später und teurer schief. Diese Gegenüberstellung dreht sich um einen einzigen Unterschied: Wo findet die Korrektur statt? Links, beim sofortigen Umsetzen, korrigiert man nach der Arbeit — der Entwurf bleibt implizit, am Ende steht ein großes Diff.

2:32 Rechts korrigiert man vorher, der Entwurf steht als Text da, und es entstehen prüfbare Teilschritte. Die letzte Zeile bringt es auf den Punkt: Der eine Weg führt schnell zum ersten Ergebnis, der andere schnell zum richtigen. Und die Fußzeile zieht die Grenze — für Einzeiler ist Planen Aufwand ohne Ertrag, ab mehreren Dateien kippt es.

2:53 Vier Warnungen, und die erste richtet sich gegen den Übereifer: Planen für triviale Aufgaben ist reine Zeremonie. Wer jede Umbenennung durch einen Plan schickt, verliert die Zeit, die er anderswo gewinnt. Die zweite betrifft die Qualität — ein Plan ohne Prüfung ist nur eine längere Antwort; wenn Sie ihn durchwinken, hätten Sie ihn nicht gebraucht.

3:12 Die dritte beschreibt einen psychologischen Effekt: Ein schöner Plan verführt dazu, auch die Umsetzung durchzuwinken. Und die vierte ist die Zusammenfassung: Wer den Plan nicht liest, hätte ihn nicht gebraucht.

Komplexe Aufgaben analysieren

3:25 Bevor geplant wird, muss klar sein, worüber geplant wird. Das klingt banal, wird aber ständig übersprungen — man beschreibt, was man haben will, und lässt den Agenten den Rest herausfinden. Sehen wir uns an, wie eine gute Analyse aussieht, was der Agent dabei leisten kann und warum die Frage nach seinen Annahmen die wertvollste ist, die Sie stellen können.

3:45 Analyse heißt: Der Agent liest, sucht und fragt nach, ohne etwas zu verändern. Das Ergebnis ist ein Bild vom Ist-Zustand — welche Dateien betroffen sind, wie sie zusammenhängen und wo die Unklarheiten liegen. Der letzte Teil ist der wertvollste. Ein Agent, der nichts ändern darf, hat auch keinen Anlass, Unklarheiten schnell selbst zu entscheiden. Er benennt sie stattdessen.

4:08 Und genau diese Liste offener Punkte ist oft mehr wert als die ganze Beschreibung darüber. Fünf Schritte, deren Mitte den Ausschlag gibt. Sie nennen das Ziel und verbieten ausdrücklich Änderungen. Sie lassen die betroffenen Bereiche lokalisieren. Dann — Schritt drei — fragen Sie nach offenen Fragen und Annahmen. Sie prüfen und beantworten diese Annahmen. Und erst danach geht es in die Planung.

4:32 Warum ist Schritt drei der wertvollste? Weil unausgesprochene Annahmen die häufigste Fehlerquelle sind. Der Agent trifft sie ohnehin — die Frage ist nur, ob Sie sie zu sehen bekommen, bevor sie in Code stehen. Vier Zeilen für unser Beispielprojekt. Analysieren, Dateien mit ihren Rollen benennen, offene Fragen und Annahmen auflisten — und dann die vierte Zeile: Ändere nichts.

4:55 Diese Zeile ist die entscheidende, denn ohne sie beginnt ein hilfsbereiter Agent gern gleich mit der Umsetzung. Die Fußzeile macht eine wichtige Einschränkung: Im Plan Mode brauchen Sie diese Zeile nicht, weil der Modus das technisch durchsetzt. Außerhalb davon brauchen Sie sie sehr wohl — und das ist ein guter Grund, den Modus überhaupt zu nutzen.

5:16 Der erste Punkt wiederholt die eben gemachte Erfahrung: Ohne ausdrückliches Verbot beginnt der Agent gern zu ändern. Der zweite ist ein Qualitätsmerkmal, an dem Sie Analysen messen können — eine Analyse ohne Fragen ist meist zu oberflächlich. Wenn alles klar ist, hat jemand nicht genau genug hingesehen. Der dritte betrifft den Suchraum: zu weit gefasst, und Sie bekommen Fließtext statt Erkenntnis.

5:39 Und der vierte ist eine Erinnerung, die durch das ganze Seminar läuft: Die Analyse ersetzt nicht Ihr eigenes Verständnis.

Plan Mode gezielt einsetzen

5:47 Jetzt zum Werkzeug selbst. Codex kennt einen eigenen Modus für genau diese Arbeitsweise — er darf lesen und fragen, aber nichts ändern. Das ist mehr als Bequemlichkeit: Es ist der Unterschied zwischen einer Bitte und einer Grenze. Sehen wir uns an, wie man ihn einschaltet, wie er sich in die anderen Modi einreiht und für welche Aufgaben er sich lohnt.

6:07 Im Plan Mode darf Codex Dateien lesen, die Codebasis durchsuchen und Rückfragen stellen — aber keine Dateien ändern und keine verändernden Befehle ausführen, bis der vorgeschlagene Plan freigegeben ist. Der Unterschied zur Bitte „ändere bitte nichts" ist wesentlich: Hier ist es technisch durchgesetzt. Sie müssen also nicht darauf vertrauen, dass der Agent sich daran hält, und Sie müssen es auch nicht nachträglich kontrollieren.

6:31 Genau das macht den Modus für unbekannten oder heiklen Code so nützlich. Vier Handgriffe. Sie schalten den Modus ein, wahlweise gleich mit einem Auftrag. Sie wechseln mit einer Tastenkombination zwischen den Modi. Und Sie prüfen mit status, in welchem Modus Sie gerade sind. Die Fußzeile beschreibt die Staffelung, die dahintersteht: Es gibt reines Planen, dann das Arbeiten mit Freigabe je Schritt und schließlich die eigenständige Ausführung.

6:58 Diese drei Stufen werden Sie im Alltag durchwandern — planen, freigeben, laufen lassen. Der Wechsel ist ein Tastendruck, nicht ein Neustart. Vier Situationen, in denen sich der Umweg auszahlt. Wenn mehrere Dateien oder Schichten betroffen sind. Wenn es mehr als einen vertretbaren Lösungsweg gibt — dann wollen Sie mitentscheiden, welcher genommen wird.

7:20 Wenn die Aufgabe fremden oder alten Code berührt, wo Sie selbst nicht sicher sind, was Nebenwirkungen hat. Und wenn der Fehler noch nicht verstanden, sondern nur beobachtet ist. Der letzte Fall ist der häufigste im Alltag: Etwas funktioniert nicht, und niemand weiß genau, warum. Diese Übung lässt sich nicht durch Zuhören ersetzen.

7:40 Nehmen Sie eine Aufgabe, die mindestens drei Dateien berührt — bei kleineren zeigt sich der Unterschied nicht —, und lassen Sie sie zweimal laufen: einmal direkt, einmal mit vorherigem Plan. Vergleichen Sie nicht nur das Ergebnis, sondern auch, wie gut Sie es jeweils prüfen konnten. Am Ende sollten Sie für sich begründen können, wann Sie welchen Weg wählen.

8:00 Diese Begründung ist mehr wert als jede allgemeine Empfehlung.

Anforderungen in Arbeitsschritte zerlegen

8:04 Ein Plan ist nicht einfach eine Beschreibung dessen, was passieren soll. Er ist eine Folge von Zwischenständen — und ob diese Zwischenstände taugen, entscheidet darüber, ob Sie die Umsetzung überhaupt kontrollieren können. Sehen wir uns an, woran ein guter Plan zu erkennen ist. Es gibt dafür eine erstaunlich einfache Prüffrage, die Sie an jeden Plan stellen können — unabhängig davon, wie groß das Vorhaben ist und wer den Plan geschrieben hat.

8:30 Ein brauchbarer Plan besteht aus Schritten, die einzeln umsetzbar und einzeln prüfbar sind. Jeder Schritt hinterlässt einen Zustand, in dem das Projekt weiterhin baut und die Tests laufen. Das ist die Prüffrage: Könnte ich hier aufhören? Wenn die Antwort nein ist — weil das Projekt zwischen Schritt zwei und drei kaputt wäre —, dann sind das keine zwei Schritte, sondern einer.

8:51 Diese Regel klingt streng, ist aber der einzige zuverlässige Weg, ein großes Vorhaben prüfbar zu halten. Vier Merkmale. Jeder Schritt hat ein sichtbares Ergebnis — man kann also nach jedem Schritt sagen, ob er geklappt hat. Nach jedem Schritt ist das Projekt lauffähig. Die Reihenfolge ist begründet und nicht beliebig; wo Abhängigkeiten bestehen, stehen sie vorn. Und Risiken und offene Punkte sind benannt, statt stillschweigend mitzulaufen.

9:18 Wenn ein Plan diese vier Merkmale erfüllt, können Sie ihn gefahrlos freigeben — und im Zweifel nach jedem Schritt aufhören, ohne etwas Halbfertiges zu hinterlassen. Vier Schritte für unsere Stornofrist-Änderung. Beachten Sie das Muster: Zuerst wird etwas herausgezogen, ohne das Verhalten zu ändern — Tests bleiben grün. Dann wird es konfigurierbar gemacht, ein Test kommt dazu. Dann ändert sich der Wert, mit einem Test für den Grenzfall. Und zum Schluss die Dokumentation.

9:47 An keiner Stelle ist das Projekt kaputt. Man könnte nach Schritt eins aufhören und hätte trotzdem etwas verbessert. Genau das ist das Kriterium, an dem Sie jeden Plan messen sollten. Der erste Punkt ist die häufigste Schwäche erzeugter Pläne: Schritte ohne Prüfung sind nur Absätze. Sie beschreiben, was passiert, aber nicht, woran man Erfolg erkennt.

10:09 Der zweite betrifft die Größe — ein Schritt, der alles ändert, ist kein Schritt. Der dritte betrifft die Reihenfolge: nach Bequemlichkeit statt nach Abhängigkeit sortiert, rächt sie sich in der Umsetzung. Und der vierte ist eine klassische Lücke: Der Plan endet vor Dokumentation und Tests, weil beides nach Kür aussieht.

Architekturentscheidungen prüfen

10:28 Jetzt zum wertvollsten Teil des Planens, den viele überspringen. In jedem Plan stecken Entwurfsentscheidungen — sie sind nur oft nicht als solche markiert. Wer sie erkennt und hinterfragt, spart sich später Umbauten, die niemand eingeplant hatte. Und es gibt vier Fragen, die dabei besonders zuverlässig funktionieren — unabhängig davon, worum es fachlich geht. Sehen wir sie uns an.

10:52 Jeder Plan enthält Entwurfsentscheidungen — wo etwas hingehört, welche Abstraktion entsteht, was konfigurierbar wird. Im Plan sind sie ein Satz Text; im Code sind sie eine Woche Arbeit. Dieses Verhältnis ist der ganze Grund, warum sich das Hinterfragen lohnt. Eine Entscheidung im Plan zu ändern kostet Sie eine Minute Gespräch.

11:11 Dieselbe Entscheidung nach der Implementierung zu ändern kostet den Umbau, das erneute Testen und das erneute Review. Das Verhältnis liegt leicht bei eins zu hundert. Fünf Schritte, und einer davon ist erstaunlich wirksam. Lassen Sie die Entscheidungen ausdrücklich benennen — viele Pläne verstecken sie in Nebensätzen. Fragen Sie nach der verworfenen Alternative. Halten Sie das Ergebnis gegen die Regeln in Ihrer AGENTS.md. Schätzen Sie die Folgen für Test und Betrieb ab.

11:40 Und halten Sie die Entscheidung fest, statt ihr nur zuzustimmen. Die Fußzeile hebt Schritt zwei hervor: Die Frage nach der Alternative deckt mehr auf als jede Nachfrage zum gewählten Weg — weil sie zeigt, was überhaupt im Blick war. Vier Fragen, die Sie sich merken sollten. Was hast du verworfen? — deckt unausgesprochene Annahmen auf. Was wird dadurch schwerer?

12:02 — deckt verschwiegene Kosten auf; jede Entscheidung macht irgendetwas schwieriger. Was passiert bei Fehlern? — deckt fehlende Fehlerbehandlung auf, die im Plan meist gar nicht vorkommt. Und: Was, wenn es doppelt läuft? — deckt Nebenläufigkeitslücken auf, die klassische Quelle für Fehler, die erst in Produktion auffallen.

12:22 Die Fußzeile ist nicht übertrieben: Diese vier Fragen kosten eine Minute und sparen regelmäßig einen Tag. Bei dieser Übung geht es nicht darum, den Plan zu verbessern, sondern darum, die Entscheidungen darin überhaupt zu sehen. Nehmen Sie einen erzeugten Plan und suchen Sie die Stellen, an denen etwas festgelegt wird, ohne dass es begründet ist. Stellen Sie mindestens eine davon in Frage.

12:45 Und dann — das ist der Hinweis — notieren Sie die Begründung, egal wie die Entscheidung ausfällt. Sie gehört später in die Commit-Nachricht oder in die Spezifikation. Sonst fragt in drei Monaten jemand genau dasselbe noch einmal.

Pläne gemeinsam überarbeiten

12:59 Selten ist der erste Plan der richtige. Die spannende Frage ist, was man dann tut: den Auftrag neu stellen oder den vorhandenen Plan gezielt ändern? Die Antwort hat handfeste Konsequenzen für Ihre Arbeitszeit — und für die Qualität des Ergebnisses. Sehen wir uns an, wie man einen Plan nachschärft, ohne dass er dabei komplett neu erfunden wird.

13:20 Ein Plan ist ein Entwurf zur Diskussion. Statt ihn zu verwerfen und neu zu beauftragen, wird er gezielt geändert: einzelne Schritte ergänzen, streichen, umstellen oder in kleinere zerlegen. Das ist genau die Arbeitsweise, die Sie aus einem Review kennen — Sie schreiben den Pull Request eines Kollegen ja auch nicht neu, sondern kommentieren einzelne Stellen.

13:40 Der Unterschied zum Neustart ist größer, als er wirkt: Beim Nachschärfen bleibt alles erhalten, was der Agent schon gelesen und verstanden hat. Vier Gründe. Der gesammelte Kontext bleibt erhalten — der Agent hat Dateien gelesen, Zusammenhänge erfasst, das alles ginge sonst verloren. Änderungen sind gezielt statt zufällig neu: Sie ändern, was Ihnen nicht passt, und der Rest bleibt.

14:03 Der Weg zur Entscheidung bleibt nachvollziehbar, was für spätere Fragen wertvoll ist. Und es geht schlicht schneller als eine zweite Analyse. Wer stattdessen neu beauftragt, würfelt im Grunde noch einmal — mit derselben Wahrscheinlichkeit, das gleiche Problem zu bekommen. Vier Zeilen Rückmeldung zu einem Plan. Beachten Sie, wie konkret sie sind: Schritt zwei vor Schritt eins, weil sonst Tests brechen. Schritt drei zerlegen.

14:29 Eine fehlende Migration ergänzen. Und dann die vierte Zeile, die scheinbar überflüssig wirkt: Alles Übrige bleibt. Genau diese Zeile verhindert, dass der Agent den ganzen Plan neu erfindet. Ohne sie neigt er dazu, aus Ihrer Kritik einen kompletten Neuentwurf abzuleiten — und dann prüfen Sie wieder alles von vorn. Der erste Punkt ist der häufigste: Vage Kritik führt zu einem beliebig anderen Plan. „Das gefällt mir nicht so" produziert einen anderen, aber nicht zwangsläufig besseren Entwurf.

15:00 Der zweite betrifft das Maß — alles auf einmal zu ändern macht das Ergebnis unprüfbar. Der dritte ist die eben erwähnte fehlende Zeile darüber, was bleiben soll. Und der vierte warnt vor dem Gegenteil des Losstürmens: Endlose Planrunden ersetzen keine Entscheidung. Irgendwann muss gebaut werden.

Umsetzung kontrolliert freigeben

15:18 Der Plan steht, die Entscheidungen sind geprüft. Jetzt kommt der Übergang, an dem viel Sorgfalt verloren geht: die Freigabe. Denn es macht einen erheblichen Unterschied, ob Sie den ganzen Plan auf einmal freigeben oder Schritt für Schritt. Sehen wir uns an, wie eine kontrollierte Umsetzung praktisch abläuft — und warum Commits dabei die eigentliche Absicherung sind.

15:39 Mit der Freigabe wechselt der Agent von der Analyse in die Umsetzung. Kontrolliert heißt dabei zweierlei: Der Umfang je Freigabe bleibt überschaubar, und nach jedem Schritt steht eine Prüfung — nicht erst am Ende. Das ist der Unterschied zwischen „lauf mal durch und melde dich, wenn du fertig bist" und einer schrittweisen Zusammenarbeit.

15:58 Der erste Weg ist bequemer und liefert Ihnen am Ende ein Diff, bei dem Sie nicht mehr rekonstruieren können, an welcher Stelle es abgebogen ist. Fünf Schritte, die zusammen eine Schleife bilden. Plan freigeben, Umfang bewusst begrenzen. Nach jedem Schritt das Diff ansehen. Tests laufen lassen — selbst laufen lassen, nicht die Meldung glauben. Zwischenstand committen. Und Abweichungen vom Plan sofort klären, nicht später.

16:23 Die Fußzeile nennt den praktischen Kern: Ein Commit je Planschritt macht jeden Zwischenstand rückholbar. Das ist die Versicherung, die Ihnen erlaubt, mutiger zu sein — wenn etwas schiefgeht, kostet es einen Schritt und nicht den ganzen Nachmittag. Der erste Punkt beschreibt die Hauptfalle: Freigabe für alles auf einmal erzeugt ein unprüfbares Diff — und dann war das ganze Planen umsonst.

16:47 Der zweite ist eine Erinnerung, die durch das Seminar läuft: Eine grüne Meldung ohne eigenen Testlauf ist keine Prüfung. Der dritte betrifft stille Abweichungen vom Plan, die sonst erst im Review auffallen, wenn der Umbau schon steht. Und der vierte ist praktisch: Ohne Commits ist ein Rückschritt teuer. Das Erfolgskriterium ist hier ungewöhnlich konkret: Je Planschritt ein Commit, und nach jedem laufen die Tests.

17:12 Wenn Sie das durchhalten, haben Sie am Ende nicht nur ein Ergebnis, sondern eine nachvollziehbare Geschichte, wie es entstanden ist. Der Hinweis nennt außerdem eine nützliche Rückkopplung: Wenn ein Schritt zu groß für ein Review wird, war der Plan zu grob. Sie lernen also beim Umsetzen etwas über Ihre eigene Planung — und der nächste Plan wird besser.

Der geschlossene Workflow

17:32 Zum Abschluss die Zusammenschau. Analyse, Planung, Umsetzung, Review — das klingt nach einem Wasserfall, und genau das ist es nicht. Sehen wir uns an, warum die Rückwege wichtiger sind als die Vorwärtsbewegung, wo in diesem Kreislauf jeweils die Entscheidung liegt und was passiert, wenn man ihn am Ende verlässt, um noch schnell etwas zu flicken.

17:52 Die vier Phasen bilden keinen Einbahnweg, sondern einen Kreis. Was das Review zutage fördert, gehört zurück in Analyse oder Plan und nicht in eine improvisierte Korrektur am Ende der Session. Das ist die eigentliche Disziplin. Denn die Versuchung ist groß: Man ist fast fertig, das Review findet noch etwas, und man flickt es schnell.

18:11 Damit verlässt man aber genau die Struktur, die das Ergebnis prüfbar gemacht hat — und die letzte Änderung ist dann die einzige, die niemand geplant hat. Diese Tabelle hat eine Aussage, die in der rechten Spalte steht. In der Analyse liest und fragt der Agent, Sie beantworten. In der Planung schlägt er vor, Sie entscheiden.

18:31 In der Umsetzung ändert und testet er, Sie geben frei und prüfen. Im Review erklärt und korrigiert er, Sie bewerten. In jeder einzelnen Phase liegt die Entscheidung beim Menschen — der Agent liefert die Vorarbeit. Das ist keine Höflichkeitsformel, sondern die Arbeitsteilung, die diese Arbeitsweise überhaupt tragfähig macht.

18:52 Vier Dinge. Korrekturen, die den ursprünglichen Entwurf verletzen — das passiert, wenn man am Ende flickt statt zurückzugehen. Erkenntnisse, die nur im Chatverlauf existieren und mit ihm verschwinden. Immer neue Anläufe statt gezielter Änderung. Und Fertig-Meldungen ohne belegte Prüfung. Der gemeinsame Nenner: Ohne den Rückweg sammelt sich alles Unerledigte am Ende an, wo am wenigsten Zeit ist, es sauber zu behandeln.

19:18 Für diese Übung nehmen Sie eine echte Aufgabe und gehen den vollständigen Zyklus — mit sichtbaren Artefakten je Phase: die Analyse, der Plan, die Commits, das Review-Ergebnis. Der interessanteste Teil steht im Hinweis: Halten Sie fest, an welcher Stelle Sie in eine frühere Phase zurückgekehrt sind und warum. Diese Rücksprünge sind kein Zeichen schlechter Planung.

19:38 Sie sind der Normalfall — und wer sie beobachtet, erkennt mit der Zeit, welche Fragen er schon in der Analyse hätte stellen sollen. Vier Punkte zum Mitnehmen. Sofortiges Schreiben verdeckt die Entwurfsentscheidungen im fertigen Diff. Im Plan Mode liest und fragt der Agent, ändert aber technisch gesichert nichts. Ein guter Plan besteht aus einzeln prüfbaren, lauffähigen Zwischenständen — die Prüffrage lautet: Könnte ich hier aufhören?

20:05 Und was das Review findet, gehört zurück in Analyse oder Plan. Im nächsten Modul wird es konkret: Wir sehen uns an, wie sich diese Arbeitsweise in einem echten, gewachsenen Softwareprojekt schlägt.