Planen, schneiden und kontrolliert implementieren

Planen, schneiden und kontrolliert implementieren

0:00 Es gibt einen Moment im agentischen Arbeiten, der leicht zu übersehen und außerordentlich wertvoll ist: der Augenblick, in dem der Plan vorliegt und noch kein Code geschrieben wurde. Das ist die letzte Stelle, an der eine Korrektur billig ist. Danach kostet jede Änderung nicht nur die Änderung, sondern auch das erneute Lesen dessen, was inzwischen entstanden ist.

0:20 Dieses Modul handelt davon, diesen Moment bewusst zu nutzen.

Planen, schneiden und kontrolliert implementieren

0:24 Vier Themen: die Prüfung des Plans, die Impact-Analyse über den eigenen MCP-Server, der Schnitt in kleine reversible Schritte und der Umgang mit Abbruch und Eskalation. Das letzte Thema wird am häufigsten ausgelassen und ist das folgenreichste — denn ein Lauf ohne Abbruchkriterium endet nicht, wenn er sollte, sondern wenn das Budget aufgebraucht ist.

Den agentischen Plan prüfen

0:45 Fangen wir mit dem Plan an. Ihn zu erzeugen ist heute Standard. Ihn zu prüfen noch nicht. Der agentische Plan ist die vom Agenten formulierte Folge von Schritten samt der Annahmen, auf denen sie beruht. Auf die Annahmen kommt es an — sie sind der Teil, den man prüfen muss und den die meisten überfliegen. Ein Plan, der auf einer falschen Annahme steht, ist in jedem einzelnen Schritt plausibel und im Ergebnis falsch.

1:10 Und weil er plausibel ist, fällt das beim Lesen nicht auf, sondern erst im Test. Fünf Fragen, die man in fünf Minuten beantwortet. Trifft er das Problem oder nur den Lösungsvorschlag aus dem Ticket — das ist die Verbindung zum vorigen Modul. Sind die Schritte einzeln prüfbar. Welche Annahmen stecken drin. Fehlen Schritte, etwa Tests, Migration oder Rückbau. Und wo müsste ein Mensch eingreifen.

1:35 Die Fußzeile fasst es zusammen: Ein Plan, der nur aus Implementieren und Testen besteht, ist keiner — das ist eine Absichtserklärung. Hier liegt ein Nutzen, den man beim ersten Mal nicht erwartet. Der Diff lässt sich gegen den Plan lesen, nicht nur gegen den Code. Das ist ein völlig anderer Lesemodus: Sie prüfen nicht jede Zeile, sondern fragen, ob das hier dem entspricht, was verabredet war.

2:00 Abweichungen fallen dabei auf, statt als Detail durchzugehen. Und der letzte Punkt ist ein Nebeneffekt, der sich lohnt: Zwei Pläne für denselben Auftrag zeigen die Streuung — und damit, wie klar Ihre Spezifikation wirklich war. Der zweite Punkt ist der, den ich für den gefährlichsten halte: Eine erkennbar falsche Annahme wird durchgewunken, weil sie plausibel klingt.

2:22 Plausibel ist bei generierten Texten der Normalzustand — das ist kein Qualitätsmerkmal. Der dritte Punkt hebt den ganzen Nutzen auf: Der Plan entsteht, nachdem der erste Code schon geschrieben ist. Dann ist er eine Beschreibung, keine Entscheidung. Und der vierte ist ein Dokumentationsthema, das im Zweifel zählt: Die Freigabe des Plans wird nirgends festgehalten.

Repository-Recherche und Impact-Analyse

2:43 Kommen wir zu dem Punkt, an dem unser MCP-Server endlich seinen Zweck erfüllt. Die Impact-Analyse bestimmt vor der Umsetzung, welche Komponenten, Schnittstellen und Datenbestände betroffen sind. Für einen Agenten ist sie kein Nebenprodukt, sondern eine eigene Phase mit eigenen Werkzeugen — in unserem Fall das Werkzeug zur Ermittlung betroffener Komponenten, das wir in Modul 5 gebaut haben.

3:06 Der Unterschied zwischen ermitteln und vermuten ist hier entscheidend, und er ist in den Protokollen sichtbar: Entweder gab es einen Werkzeugaufruf, oder es gab keinen. Vier Fragen, die vor jeder Umsetzung beantwortet sein sollten, und je eine Quelle im Anliegenbuch. Wo wird heute validiert. Wer ruft das auf. Welche Tests decken das ab.

3:27 Und was hat der Fachbereich dazu entschieden. Beachten Sie die Fußzeile: Alle vier Antworten gehören in den Plan, nicht erst in den Pull Request. Wenn sie erst im Pull Request auftauchen, waren sie beim Planen nicht bekannt — und der Plan stand auf Vermutungen. Vorhandene Tests zeigen, welches Verhalten als zugesichert gilt. Das ist die wichtigste Information, bevor man etwas ändert — und sie steht nirgends sonst.

3:52 Der zweite Punkt ist ein Warnsignal, auf das man achten sollte: Ein neuer Test neben einem widersprüchlichen bedeutet, dass zwei Erwartungen im Umlauf sind. Und bei Bestandscode ohne Tests helfen Characterization Tests: Man schreibt fest, was das System heute tut — nicht, was es tun soll. Das klingt bescheiden und ist die einzige verlässliche Grundlage für eine Änderung im Dunkeln.

4:15 Der erste Punkt ist der häufigste und der teuerste: Die Analyse beschränkt sich auf die Datei, die im Ticket genannt ist. Der zweite nennt die Stellen, die auch gute Werkzeuge übersehen — Aufrufwege über Konfiguration oder Reflexion. Der dritte ist der, auf den man im Protokoll achten sollte: Der Agent erklärt die Wirkung, statt sie zu ermitteln. Das liest sich überzeugend und beruht auf nichts.

4:39 Prüfen Sie, ob ein Werkzeugaufruf dahintersteht.

Kleine, reversible Schritte

4:42 Jetzt zum Schnitt. Er entscheidet darüber, ob Sie am Ende prüfen können, was entstanden ist. Ein guter Schnitt erzeugt Schritte, die sich einzeln prüfen und einzeln zurücknehmen lassen. Die Arbeit läuft in einem isolierten Zweig oder Arbeitsbereich, Zwischenstände werden als Checkpoints festgehalten. Der Zweck ist nicht Ordnung, sondern die Möglichkeit zum Rückschritt: Wenn Schritt drei schiefgeht, wollen Sie zu Schritt zwei zurück und nicht an den Anfang.

5:09 Ohne Checkpoints kostet jeder Fehler den ganzen Lauf. Vier Glieder für eine einzige Validierungsregel — das wirkt übertrieben und ist es nicht. Erst der Test, der die Regel einfordert und rot ist. Dann die Regel selbst. Dann die Anbindung an das Formular. Und zum Schluss der Rückbau dessen, was die alte stillschweigende Annahme getragen hat.

5:30 Jeder dieser Schritte ist einzeln prüfbar, jeder einzeln umkehrbar. Als ein Schritt wäre es ein Diff, den man liest oder überfliegt — und man überfliegt. Vier Gründe, und der vierte ist der, den man erst im Team merkt: Ohne Isolation vermischen sich Agentenarbeit und Handarbeit. Dann steht im Diff etwas, das niemand zuordnen kann, und die Frage „hat das der Agent gemacht?" ist nicht mehr beantwortbar.

5:55 Das ist kein Misstrauensthema, sondern ein Nachvollziehbarkeitsthema — und es wird spätestens bei der Auswertung in Modul 13 wichtig. Der erste Punkt hebt den ganzen Schnitt wieder auf: Alle Schritte landen in einem Commit und sind nicht mehr trennbar. Der dritte ist eine ehrliche Beobachtung — Checkpoints werden gesetzt, aber nie zum Zurücksetzen genutzt. Dann sind sie Dekoration.

6:18 Und der vierte ist der, der in echten Projekten wehtut: Ein Schritt ist umkehrbar, seine Datenmigration aber nicht. Umkehrbarkeit endet an der Datenbank — das gehört in den Plan und in die Risikobewertung.

Abbruch, Eskalation und Neuplanung

6:30 Bleibt das Thema, das am häufigsten fehlt: das geordnete Aufhören. Abbruchkriterien legen vor dem Start fest, wann ein Lauf endet, ohne fertig zu sein. Human Escalation beschreibt, welche Entscheidungen der Agent nicht treffen darf und an wen sie gehen. Beides gehört in den Auftrag, nicht in die Bewertung hinterher. Denn hinterher ist die Frage immer dieselbe: Warum hat das so lange gedauert? Und die Antwort ist meistens, dass niemand gesagt hat, wann Schluss ist.

7:00 Drei Signale mit klarer Konsequenz. Die dritte Korrekturschleife am selben Test — Abbruch und Neuplanung. Eine fachliche Frage ohne Antwort im Kontext — Eskalation. Eine sicherheitsrelevante Stelle — Eskalation und unabhängiges Review. Besonders die erste Zeile lohnt das Merken, und die Fußzeile sagt warum: Wiederholtes Nachbessern am selben Punkt ist fast immer ein Planungsfehler, kein Codefehler.

7:25 Der Agent behebt das Symptom, weil er die Ursache nicht sehen kann. Vier Argumente, und das dritte ist das ökonomische: Kosten und Laufzeit wachsen, der Erkenntnisgewinn nicht. Ab der dritten Runde lernen Sie nichts Neues mehr über das Problem, Sie zahlen nur weiter. Und das vierte Argument ist eine Haltungsfrage, die ich wichtig finde: Ein Abbruch mit klarem Befund ist ein brauchbares Ergebnis.

7:48 „Wir haben festgestellt, dass die Anforderung an dieser Stelle unklar ist" ist eine Erkenntnis — und deutlich mehr wert als ein durchgedrückter Pull Request, den niemand versteht. Der erste Punkt ist der aus der Einleitung: Der Lauf hat kein Abbruchkriterium und endet erst am Budget. Der dritte ist der, den man im Diff finden muss: Der Agent bessert nach, indem er den Test anpasst.

8:11 Das ist logisch aus seiner Sicht — der Test war rot, jetzt ist er grün — und es ist genau das, was in Modul 12 unsere Übung wird. Und der vierte ist die verlorene Lernchance: Nach dem Abbruch wird neu gestartet, ohne den Plan zu ändern.

Übung

8:26 Jetzt lassen wir einen Agenten arbeiten — aber nur so weit, wie wir es freigeben. Die Übung hat eine ungewöhnliche Begrenzung: Nur der erste Schritt wird ausgeführt. Das fühlt sich unbefriedigend an, ist aber der Punkt. Geprüft wird nicht das Ergebnis, sondern die Kontrolle über den Weg dorthin — und die entscheidet sich am Anfang, nicht am Ende.

8:48 Der Agent bearbeitet die spezifizierte Änderung und nutzt dabei anliegen-mcp zur Kontextbeschaffung. Prüfen Sie den Plan und geben Sie ihn mit mindestens einer Korrektur frei — mindestens eine, weil ein Plan, an dem man nichts zu korrigieren findet, meist nicht gründlich genug gelesen wurde. Dann lassen Sie den ersten Schritt ausführen und protokollieren jede Abweichung mit Zeitpunkt und Anlass.

9:11 Wichtig ist der Hinweis: Die Impact-Analyse läuft über das Werkzeug, nicht über Vermutung. Der erste Punkt ist die Abkürzung, die alles entwertet: Der Plan wird freigegeben, ohne die Impact-Analyse zu verlangen. Der zweite ist ein Aufbauthema — der Agent führt gleich mehrere Schritte aus, weil ihn nichts begrenzt. Das muss man technisch vorgeben, nicht erbitten.

9:32 Und der vierte ist der, der die Auswertung wertlos macht: Das Protokoll entsteht nachträglich aus der Erinnerung. Im nächsten Modul geht es darum, was mit dem Ergebnis passiert — und warum eine grüne Pipeline nichts beweist.