Der sichere agentische Entwicklungszyklus

Der sichere agentische Entwicklungszyklus

0:00 Das fünfte Modul bündelt alles, was Sie bisher gehört haben, zu einem Ablauf. Neun Schritte, von der Klärung bis zur Übergabe. Ich sage gleich dazu: Das ist keine Methode mit Namen und kein Standard, sondern eine Zusammenstellung aus den belegten Einzelteilen der ersten vier Module. Der entscheidende Teil ist auch nicht die Zahl neun — es ist die Reihenfolge. Jeder Schritt setzt voraus, dass der vorige belastbar erledigt wurde.

0:26 Wer einen überspringt, merkt es erst weiter hinten, und dann ist es teuer.

Der sichere agentische Entwicklungszyklus

0:31 Damit schließen wir den ersten Tag ab — und zwar mit der Tagesübung, in der Sie ein Feature vollständig durch den Zyklus führen. Alles, was heute an Begriffen, Maßstäben und Zuschnitt-Handwerk dazugekommen ist, kommt hier zusammen. Und Sie werden am eigenen Beispiel merken, welcher Schritt sich für welche Aufgabengröße lohnt. Denn nicht jeder Schritt lohnt sich immer — auch das gehört zur ehrlichen Bilanz.

Der Zyklus im Überblick

0:54 Sehen wir uns zunächst das Ganze an, bevor wir in die einzelnen Schritte gehen. Neun Schritte klingen nach viel, und der erste Reflex ist meist Skepsis: So viel Prozess für eine kleine Änderung? Der Einwand ist berechtigt, und ich möchte ihn gleich beantworten — mit einem Blick darauf, wie lange das tatsächlich dauert. Für eine kleine Änderung dauert der gesamte Zyklus selten länger als eine halbe Stunde. Das überrascht viele, und der Grund ist einfach: Die meiste Zeit arbeitet ohnehin der Agent.

1:23 Ihre Zeit fällt bei drei Schritten an — beim Klären, beim Lesen des Plans und beim Prüfen des Ergebnisses. Das sind genau die Stellen, an denen Ihre Urteilskraft gebraucht wird. Alles andere läuft nebenher. Entscheidend ist deshalb nicht, ob die Liste vollständig ist, sondern dass kein Schritt den vorigen überholt. Ich gehe die Tabelle nicht Zeile für Zeile durch — sehen Sie sich lieber die rechte Spalte an. Dort steht jeweils, was ein Schritt liefert, und daran erkennen Sie die Logik.

1:52 Schritt zwei liefert eine Landkarte mit Belegen, nicht die Wahrheit. Schritt drei liefert die Annahmenliste, auf der alles Weitere ruht. Schritt vier den freigegebenen Plan — in Prosa, damit man ihn ohne Code beurteilen kann. Und dann erst wird umgesetzt, und zwar die kleinste sinnvolle Änderung. Die beiden Sätze in der Fußzeile fassen zusammen, warum die Reihenfolge trägt: Wer die Erkundung überspringt, plant im Nebel.

2:17 Wer den Plan überspringt, prüft am Ende die falsche Frage.

Klären und Erkunden

2:21 Beginnen wir mit den ersten beiden Schritten. Sie kosten am wenigsten und sparen am meisten — das ist eine der wenigen Stellen in der Softwareentwicklung, an der das so klar zutrifft. Und beim Erkunden liegt zugleich der beste Einsatzzweck eines Agenten überhaupt, weil das Risiko dabei praktisch null ist. Klären heißt, den Auftrag so weit zu präzisieren, dass ein Erfolgskriterium darin vorkommt.

2:44 Und das hat eine harte Konsequenz: Ohne dieses Kriterium ist der letzte Schritt des Zyklus — die Abnahme — gar nicht durchführbar. Sie können am Ende nicht sagen, ob Sie fertig sind. Erkunden heißt, sich ein Bild vom Ist-Zustand zu verschaffen, bevor man über den Soll-Zustand entscheidet: Welche Dateien tragen das Thema, wo liegen die Regeln, welche Tests gibt es, welche Konventionen sind erkennbar.

3:08 Vier Gründe, und der erste ist der wichtigste: Die Arbeit ist rein lesend und trägt damit kein Risiko. Es kann nichts kaputtgehen. Dazu kommt, dass ein Agent schneller liest als jeder Mensch und Dateien findet, die Sie übersehen hätten. Aber — und das ist die Einschränkung, die dazugehört — das Ergebnis ist keine Wahrheit, sondern eine Landkarte.

3:28 Verlangen Sie deshalb Belegstellen: Jede Aussage sollte auf eine Datei und eine Zeile zeigen, damit Sie stichprobenartig nachsehen können. Ohne Belege ist die Landkarte hübsch und wertlos. Der erste Punkt ist der zentrale: die Landkarte für einen Befund halten statt für eine Hypothese. Sie liest sich souverän, und genau das ist die Gefahr.

3:49 Der zweite folgt daraus — ohne verlangte Belegstellen ist nichts davon nachprüfbar. Der dritte betrifft das Klären: Wer es überspringt, kann am Ende nicht abnehmen. Und der vierte ist ein häufiger Zuschnittfehler: Erkunden und Ändern im selben Auftrag zu beauftragen. Dann verlieren Sie die Risikofreiheit des Lesens und den Zwischenhalt für Ihre eigene Beurteilung.

Planen und Risiken benennen

4:11 Jetzt zum Werkstück, das die meiste Prüfaufmerksamkeit verdient — und das gleichzeitig am schnellsten zu lesen ist. Das ist ein seltenes Verhältnis, und man sollte es ausnutzen. Hier entscheidet sich mehr als in jedem anderen Schritt des Zyklus, denn ein Fehler im Plan pflanzt sich in alles Folgende fort. Und es gibt einen Bestandteil, der fast immer fehlt und gerade der wertvollste ist.

4:34 Ein Plan sollte drei Dinge enthalten: die vorgesehenen Schritte in Reihenfolge, die betroffenen Dateien, und die Annahmen, auf denen er ruht. Der dritte Punkt wird am häufigsten weggelassen und ist am wertvollsten — denn Annahmen sind der Ort, an dem sich Missverständnisse verstecken. Die Schritte selbst sehen fast immer plausibel aus. Ein Plan, der annimmt, dass Fahrten ohne Kilometerstand ignoriert werden dürfen, liest sich völlig unauffällig.

4:59 Erst die ausgesprochene Annahme macht den Irrtum sichtbar. Fünf Punkte, und zwei davon sind die eigentlichen. Punkt drei, die Annahmen, haben wir gerade besprochen. Punkt vier ist die Risikofrage: Was könnte diese Änderung kaputt machen, das nicht offensichtlich mit ihr zu tun hat? Beim Fahrtenbuch lautet die Antwort erstaunlich oft: die Abrechnung. Dort landet am Ende fast alles.

5:23 Und Punkt fünf ist der aus Modul vier bekannte — was der Plan ausdrücklich nicht tut. Wichtig noch: Der Plan muss kurz genug sein, dass man ihn wirklich liest. Ein Plan, den niemand liest, ist schlechter als keiner, weil er Sicherheit vortäuscht. Der erste Punkt ist die Kernfalle: Ohne Annahmen prüft man Schritte statt Verständnis.

5:43 Der zweite ist die Code-Falle — ein Plan mit Code lässt sich nicht mehr fachlich beurteilen, weil die Aufmerksamkeit auf die Syntax rutscht. Der dritte ist der ernsteste: Wer freigibt, ohne gelesen zu haben, hat trotzdem freigegeben. Mit der Freigabe wandert die Verantwortung, unabhängig davon, wie gründlich Sie waren. Und der vierte betrifft die Risiken — sie auf das zu beschränken, was der Auftrag ohnehin nennt, macht die Frage überflüssig.

Implementieren in kleinsten Schritten

6:09 Zur Umsetzung. Hier gilt eine einzige Regel, die alles andere trägt, und sie ist schnell gesagt: Ein Schritt, eine Sache. Interessant ist weniger die Regel selbst als der Grund, warum sie bei agentischer Arbeit schwerer einzuhalten ist als früher. Der Grund ist nämlich kein Werkzeugfehler, sondern eine Anreizfrage. Nicht ein Refactoring zusammen mit einer Verhaltensänderung. Nicht drei Fehlerkorrekturen in einem Durchgang.

6:35 Und vor allem nicht die Formatierung der ganzen Datei zusammen mit der Fachlichkeit — das ist der sicherste Weg, eine inhaltliche Änderung im Rauschen von zweihundert geänderten Zeilen unsichtbar zu machen. Sie kennen das aus eigenen Reviews: Wenn der Diff überwiegend aus Einrückungen besteht, findet niemand mehr die eine Zeile, in der die Regel gekippt wurde.

6:55 Man scrollt, nickt und übersieht. Diese Tabelle erklärt, warum gute Vorsätze hier nicht reichen. Lesen Sie sie spaltenweise. Ein zusätzlicher Schritt kostet einen Menschen Zeit und Mühe — das begrenzt ihn ganz von allein. Einen Agenten kostet er praktisch nichts. Gleichzeitig erkennt der Agent Zusammenhänge sehr gut und sieht deshalb wirklich Verbesserungsmöglichkeiten. Und jetzt die entscheidende Zeile: Wer zahlt den Preis?

7:21 Beim Menschen er selbst — er muss den größeren Diff auch selbst wieder verstehen. Beim Agenten zahlt ihn jemand anderes, nämlich Sie. Ein Anreiz, der so verteilt ist, korrigiert sich nicht von selbst. Deshalb gehört die Begrenzung in den Auftrag. Der erste Punkt ist der aus der Definition: Formatierung und Fachlichkeit im selben Durchgang.

7:42 Der zweite ist verführerisch — ein angebotenes Zusatz-Refactoring mitnehmen, weil es ohnehin schon da ist. Es ist eben nicht umsonst; es kostet Prüfzeit. Der dritte ist der eigene Anteil: den Umfang im Auftrag nicht begrenzen und ihn hinterher beklagen. Und der vierte ist die falsche Reaktion auf einen zu großen Diff — schneller lesen. Die Zahlen aus Modul vier sagen deutlich, dass das nicht funktioniert.

Prüfen, Rückmelden, Nacharbeiten

8:07 Damit zum Prüfen. Drei Prüfungen in fester Reihenfolge, und die Reihenfolge folgt keiner Konvention, sondern schlicht den Kosten — jede Stufe macht die nächste billiger. Das ist der Grund, warum sie sich lohnt, auch wenn sie zunächst nach Umständlichkeit aussieht. Anschließend sehen wir uns an, wie eine Rückmeldung aussehen muss, damit sie tatsächlich wirkt. Das ist eine eigene Fertigkeit, und sie wird selten geübt.

8:33 Zuerst die maschinellen Prüfungen: bauen, Tests, Linter, statische Analyse. Der Grund steht in Schritt zwei — was hier scheitert, muss kein Mensch ansehen. Erst danach der Diff, gelesen mit genau einer Frage: Wurde das Beauftragte getan, nicht mehr und nicht weniger. Dann das Verhalten, an einem Beispiel, das Sie selbst gewählt haben.

8:54 Dieses Detail ist wichtig: Ein vom Agenten gewähltes Beispiel bestätigt seine eigene Annahme. Und erst danach wird zurückgemeldet — je Durchgang ein Punkt. Eine gute Rückmeldung beschreibt das beobachtete Problem und stellt die Erwartung dagegen. Sie gibt keine Lösung vor — und das ist der Punkt, den die meisten überraschend finden.

9:14 Wer die Lösung mitliefert, prüft am Ende die eigene Idee statt das Problem. Und dann die praktische Beobachtung: Eine Liste mit acht Rückmeldungen führt zuverlässig dazu, dass drei davon halbherzig erledigt werden. Das ist derselbe Aufmerksamkeitsmechanismus wie bei überladenem Kontext, den wir in Modul sechs messen werden. Ein Punkt nach dem anderen ist langsamer und am Ende schneller.

Git als Sicherheitsnetz

9:37 Jetzt zur technischen Grundlage, die diesen ganzen Zyklus überhaupt risikofrei macht. Ohne saubere Versionsverwaltung ist alles bisher Gesagte theoretisch, denn dann können Sie weder zuordnen, was der Agent geändert hat, noch zu einem guten Stand zurück. Drei Gewohnheiten genügen dafür, und sie sind unspektakulär genug, dass jeder sie kennt. Angewendet werden sie trotzdem selten konsequent.

10:01 Erstens: ein sauberer Ausgangszustand vor Beginn. Zweitens: ein Commit nach jedem für sich sinnvollen Schritt. Und drittens — der psychologisch schwierigste Teil — die Bereitschaft zu verwerfen. Der Rücksprung auf den letzten guten Stand ist keine Niederlage, sondern der billigste verfügbare Weg, wenn eine Änderung in die falsche Richtung gelaufen ist.

10:22 Und hier passiert etwas Interessantes: Wer weiß, dass der Rücksprung billig ist, arbeitet mutiger. Das Sicherheitsnetz macht nicht vorsichtig, es macht frei. Achten Sie auf die rechte Spalte, denn dort steht jeweils, was ohne die Gewohnheit passiert. Ohne sauberen Ausgangszustand ist der Lauf schlicht nicht prüfbar — Sie können nicht mehr unterscheiden, was der Agent geändert hat und was schon vorher anders war.

10:46 Ohne Zwischencommits haben Sie einen großen Sprung ohne Zwischenhalt, also keinen Punkt, zu dem sich zurückkehren ließe. Und ohne die Bereitschaft zu verwerfen landen Sie bei der Reparatur einer Lösung, die von Anfang an nicht trug. Diese dritte Zeile ist die teuerste von allen. Der erste Punkt ist der häufigste Anfängerfehler und passiert auch Erfahrenen: einen Agenten auf einem bereits veränderten Arbeitsverzeichnis loslassen.

11:11 Danach ist der Diff wertlos. Der zweite ist bequem und teuer — am Ende einmal alles committen. Damit sind die Zwischenschritte weg. Der dritte und vierte gehören zusammen: an einer untragfähigen Lösung festhalten und das Verwerfen als Eingeständnis werten. Es ist keins. Es ist die Entscheidung, die aus dem misslungenen Versuch den Gewinn zieht.

Wann der Agent stoppen muss

11:32 Zum letzten fachlichen Kapitel dieses Moduls: Haltepunkte. Autonomie braucht Grenzen, und diese Grenzen gehören vorher festgelegt — nicht im Einzelfall entschieden. Denn im Einzelfall ist man immer geneigt weiterzumachen, weil schon Arbeit steckt und der Abbruch wie ein Rückschritt wirkt. Vier Kategorien haben sich bewährt, und die vierte ist die, die man am leichtesten übersieht und zugleich am dringendsten braucht.

11:56 Ich möchte diese Haltepunkte richtig rahmen, weil sie leicht als Misstrauen gelesen werden. Sie sind kein Misstrauen gegenüber dem Werkzeug. Sie markieren die Stellen, an denen ein Mensch eine Information hat, die im Repository schlicht nicht steht — dass diese Migration während des Monatsabschlusses nicht laufen darf, dass auf dieses Datenformat ein anderes Team hört, dass diese Bibliothek im Haus nicht erlaubt ist.

12:18 Kein Modell kann das wissen, weil es nirgends geschrieben steht. Die ersten drei Kategorien sind naheliegend: schwer Rückgängigmachbares, Verträge nach außen, Kosten und neue Abhängigkeiten. Bemerkenswert ist, dass sie sich mit einer aktuellen Sicherheitsklassifikation decken — in den OWASP-Regeln für KI-Anwendungen steht Excessive Agency, also übermäßige Handlungsvollmacht, in der Fassung von 2026 auf Platz drei, aufgestiegen von Platz sechs.

12:45 Der Grund dafür sind reale Schäden in Produktion. Die vierte Kategorie steht in keiner Liste und ist die wichtigste: Die Aufgabe stellt sich als grundlegend anders heraus als angenommen. Ein Agent meldet das selten von sich aus. Der erste Punkt ist der zentrale: Haltepunkte erst im Einzelfall festlegen, wenn die Lage schon eskaliert ist. Dann entscheidet der Druck, nicht das Urteil.

13:08 Der zweite ist der eben genannte vierte Punkt — der Agent meldet einen Irrtum im Auftrag praktisch nie von sich aus, also müssen Sie danach fragen. Der dritte ist die bequeme Ausnahme: neue Abhängigkeiten durchwinken, weil sie den Auftrag lösen. Und der vierte betrifft die Kommunikation im Team: Wer Haltepunkte als Misstrauen erklärt, bekommt Widerstand. Es ist eine Informationsgrenze, keine Kontrolle.

Tagesübung: Ein Feature durch den Zyklus führen

13:33 Damit zur Tagesübung, die den ersten Tag abschließt. Sie führen eine echte Änderung am Fahrtenbuch vollständig durch alle neun Schritte — mit einem Coding-Agenten Ihrer Wahl, denn der Zyklus ist bewusst werkzeugunabhängig formuliert und funktioniert mit jedem gängigen Produkt. Am Ende stehen zwei Fragen, von denen die zweite die ehrlichere ist. Sie zielt darauf, wo der Prozess für Ihre Aufgabengröße zu viel war.

13:56 Die Aufgabe kennen Sie schon aus Modul eins, dort haben Sie die Arbeit verteilt. Jetzt setzen Sie sie um: die nachträgliche Korrektur einer Fahrt. Wichtig ist das Protokoll — zu jedem der neun Schritte ein kurzer Eintrag, was Sie getan haben und was dabei herauskam. Besonders wichtig sind die Annahmen aus Schritt drei und der Plan aus Schritt vier, und zwar beide datiert vor der ersten Codezeile.

14:19 Das ist kein Formalismus: Es ist der einzige Weg, hinterher zu belegen, dass Sie geplant und nicht rekonstruiert haben. Der Ablauf ergibt sich aus dem Zyklus. Interessant sind die beiden Fragen am Ende. Die erste: An welcher Stelle hätte das Überspringen eines Schritts Sie tatsächlich Zeit gekostet? Die zweite, und die ist die ehrlichere: An welcher Stelle war der Schritt für diese Aufgabengröße unverhältnismäßig?

14:43 Denn nicht jeder Schritt lohnt sich bei jeder Aufgabe, und ein Zyklus, den man nur pflichtschuldig abarbeitet, wird bald gar nicht mehr abgearbeitet. Halten Sie beide Antworten fest — sie fließen in Modul zwölf in die Definition of Done Ihres Teams ein.