Von AI-assisted Coding zu Agentic Coding

Von AI-assisted Coding zu Agentic Coding

0:00 Jetzt kommt der Teil des Seminars, über den in Entwicklerrunden am meisten geredet und am wenigsten systematisch gearbeitet wird: die Zusammenarbeit mit Coding Agents. Ich möchte vorweg etwas zur Belastbarkeit dieses Moduls sagen: Fast alles, was hier steht, steht wörtlich in den Dokumentationen zweier Anbieter — unabhängig voneinander geschrieben, mit denselben Schlüssen.

0:20 Das ist kein Zufall und keine Modeerscheinung, sondern ein Hinweis darauf, dass hier etwas Strukturelles am Werk ist. Und deshalb bleibt es gültig, auch wenn Sie morgen das Werkzeug wechseln.

Von AI-assisted Coding zu Agentic Coding

0:31 Der Leitsatz für dieses Modul knüpft an Modul 8 an: Ein grüner Testlauf sagt, dass etwas funktioniert — nicht, dass es richtig gebaut wurde. Wir gehen die vier Stufen der Unterstützung durch, klären, welche Aufgaben sich überhaupt delegieren lassen, und bauen dann Schritt für Schritt einen brauchbaren Auftrag. Danach die beiden Punkte, an denen es in der Praxis am häufigsten scheitert: Wer prüft, und wer weist nach?

0:55 Zum Schluss die Übung — und dort ist der Plan das Prüfstück, nicht der Code.

Vier Stufen der Unterstützung

1:00 Beginnen wir mit einer Sortierung. Vier Stufen der Unterstützung — und sie unterscheiden sich nicht im Modell dahinter, sondern in Vorbereitung und Kontrolle. Wichtig: Das ist kein Reifegradmodell. Alle vier haben ihren Platz; falsch wird es erst, wenn man die Vorbereitung der einen für eine andere einsetzt. Die erste Stufe ergänzt die nächste Zeile beim Tippen. Die zweite beantwortet eine Frage im Gespräch. Die dritte kennt das Projekt und darf darin arbeiten.

1:28 Und die vierte läuft über längere Zeit ohne ständige Begleitung. Ein Bild aus dem Handwerk: Das reicht vom Kollegen, der Ihnen das Werkzeug anreicht, bis zum Subunternehmer, der ein Gewerk übernimmt. Und was sich zwischen diesen Stufen ändert, ist nicht die Fähigkeit — es ist, wie viel Sie vorher sagen müssen und wie Sie hinterher kontrollieren.

1:49 Lesen Sie diese Tabelle als Steigerung — beide Spalten wachsen gemeinsam. Bei der Ergänzung beim Tippen brauchen Sie keine Vorbereitung, und die Kontrolle passiert sofort, weil Sie es ja sehen. Beim Gespräch ist die Vorbereitung die Frage selbst. Ab der dritten Stufe brauchen Sie Kontext und Konventionen, und die Kontrolle ist der Änderungssatz.

2:09 Und bei der delegierten Aufgabe brauchen Sie Auftrag, Plan und Prüfkriterium — und verlangen einen Nachweis statt einer Behauptung. Je weniger Sie zusehen, desto mehr müssen Sie vorher festlegen. Vier Punkte, und der erste ist der Kern: Die Kontrolle muss zur Stufe passen, sonst prüft man das Falsche. Wer eine delegierte Aufgabe wie eine Ergänzung beim Tippen kontrolliert — also nur mal draufschaut —, prüft die Oberfläche.

2:35 Je länger ein Lauf, desto weniger trägt spontanes Zusehen. Ab der dritten Stufe ist Vorbereitung keine Kür mehr, sondern Voraussetzung. Und der vierte Punkt ist der schärfste: Wer eine Aufgabe delegiert, braucht ein Kriterium, das ohne ihn gilt. Sonst hat er nicht delegiert, sondern nur gewartet.

Geeignete und ungeeignete Aufgaben

2:54 Jetzt die Frage, die vor jeder Delegation steht: Eignet sich diese Aufgabe überhaupt? Und dafür gibt es einen erfreulich einfachen Test aus zwei Fragen — beschreibbar und maschinell prüfbar. Beide müssen mit Ja beantwortet sein. Gut geeignet ist alles, was sich klar beschreiben und maschinell überprüfen lässt: Migrationen über viele Dateien, Testabdeckung, mechanische Refaktorierungen, Fehlersuche mit reproduzierbarem Symptom.

3:20 Das sind alles Aufgaben, bei denen niemand über den Zielzustand streitet. Schlecht geeignet ist alles, wo die Anforderung selbst noch verhandelt wird oder wo das Urteil über Angemessenheit den Kern der Aufgabe bildet. Und diese zweite Kategorie ist keine Schwäche der Werkzeuge — sie ist eine Aussage darüber, dass manche Arbeit im Wesentlichen aus Entscheiden besteht.

3:41 Fünf Aufgaben, zweimal geprüft — und die Trennlinie verläuft sauber. Bei den oberen drei steht zweimal Ja: Eine Migration prüft der Compiler, die Testabdeckung prüft der Testlauf, und ein Fehler mit Reproduktion prüft sich selbst — der Test schlägt vorher fehl und danach nicht mehr. Bei den unteren beiden steht zweimal Nein, und das ist konsistent: Was sich nicht beschreiben lässt, lässt sich auch nicht prüfen.

4:04 Eine Architekturentscheidung und eine ungeklärte fachliche Anforderung sind Ihre Arbeit — nicht, weil das Werkzeug zu schwach wäre, sondern weil es keinen Maßstab gibt. Der erste Punkt ist der Fehler, der die meiste Zeit verbrennt: eine unklare Anforderung delegieren und die Klärung dann im Änderungssatz suchen. Sie bekommen eine Interpretation geliefert und müssen aus Code rekonstruieren, was Sie eigentlich wollten. Das ist der umständlichste denkbare Weg zu einer Anforderung.

4:32 Der zweite: Angemessenheit maschinell prüfen wollen — dafür gibt es schlicht kein Kriterium. Und der dritte ist die Versuchung, aus einer ungeeigneten Aufgabe eine geeignete zu machen, statt sie vorher zu klären. Die Klärung ist die Arbeit.

Erkunden vor dem Ändern

4:46 Jetzt ein Schritt, den fast alle überspringen, weil er sich nach Verzögerung anfühlt. Beide Herstellerdokumentationen sagen dasselbe, und ich halte es für den wichtigsten Satz dieses Kapitels: Erkundung ist keine Vorstufe, die man weglassen kann — sie entscheidet über alles Weitere. Bevor eine Änderung sinnvoll ist, muss klar sein, welche Dateien überhaupt betroffen sind und welche Muster im Projekt bereits gelten.

5:12 Denn ein Agent, der sofort loslegt, schreibt Code — und zwar guten Code, der ein Problem löst. Nur eben nicht unbedingt das vorliegende. Das Bild dazu: ein Handwerker, der ohne Besichtigung anfängt zu bohren. Er kann bohren, das ist unbestritten. Ob es die richtige Wand war, stellt sich später heraus. Und in der Software heißt „später" oft: im Review, wenn die Arbeit schon getan ist.

5:36 Vier sehr praktische Regeln. Nennen Sie bestimmte Dateien, statt zu beschreiben, wo der Code ungefähr liegt — Suchen kostet Kontext und findet manchmal das Falsche. Zeigen Sie auf ein vorhandenes Muster, dem gefolgt werden soll; damit bekommen Sie Code, der zu Ihrem Projekt passt statt zum Durchschnitt des Internets. Nennen Sie die Quelle, die eine Frage beantwortet, statt raten zu lassen. Und bei einem Fehler: Symptom, vermuteter Ort und Sollzustand.

6:03 Diese drei Angaben ersparen Ihnen erfahrungsgemäß die halbe Sitzung. Der erste Punkt beschreibt eine Falle, die aus dem guten Rat von eben entsteht: Erkundung unbegrenzt laufen lassen. Sie füllt dann den Kontext und verdrängt genau das Wichtige, das Sie am Anfang hineingegeben haben. Erkundung braucht eine Grenze. Der zweite ist die konkrete Form davon: den Umfang nicht eingrenzen und hunderte Dateien lesen lassen.

6:28 Und der dritte ist ein Arbeitshinweis, der viel bringt: Erkundung und Umsetzung nicht in derselben Sitzung vermischen. Zwei Schritte, zwei Sitzungen — dazwischen lesen Sie.

Der Auftrag hat vier Teile

6:38 Jetzt das Herzstück des Moduls: Wie sieht ein brauchbarer Auftrag aus? Vier Teile — Ziel, Kontext, Randbedingungen und Abschlusskriterium. Diese vier stehen wörtlich in einer der Herstellerdokumentationen. Und das vierte ist das, was am häufigsten fehlt. Ein brauchbarer Auftrag nennt vier Dinge, und drei davon schreiben die meisten ohnehin — Ziel, Kontext, Randbedingungen ergeben sich fast von selbst, wenn man über eine Aufgabe nachdenkt.

7:07 Das vierte fehlt am häufigsten, und es ist das einzige, das eine Delegation überhaupt erlaubt. Der Satz, den ich Ihnen mitgeben möchte, steht am Ende: Ohne ein Kriterium, das ohne den Auftraggeber prüfbar ist, ist fertig, was fertig aussieht. Und „sieht fertig aus" ist ein schlechter Abnahmemaßstab — bei Menschen wie bei Maschinen.

7:27 Vier Leitfragen, die Sie sich als Checkliste merken können. Was soll geändert oder gebaut werden? Welche Dateien, Ordner, Beispiele oder Fehler zählen? Welche Standards, welche Architektur, welche Sicherheitsvorgaben gelten? Und: Was muss wahr sein, damit es fertig ist — Tests grün, Verhalten geändert, Fehler weg? Die Fußzeile nennt die Begründung aus der Dokumentation, und die ist bemerkenswert nüchtern: Der Agent bleibt im Rahmen, trifft weniger Annahmen und ist leichter zu prüfen.

7:58 Drei Wirkungen für vier Sätze — das ist ein gutes Verhältnis. Der zweite Punkt ist der, der am meisten Wiederholung erzeugt: Randbedingungen mündlich mitgeben, statt sie ins Repository zu schreiben. Dann sagen Sie sie beim nächsten Auftrag wieder, und beim übernächsten auch — und jemand anders im Team weiß nichts davon. Genau darum geht es im nächsten Modul.

8:20 Der erste Punkt ist das fehlende Abschlusskriterium. Und der dritte ist die subtile Variante davon: ein Kriterium formulieren, das nur der Auftraggeber selbst prüfen kann. „Es soll sich sauber anfühlen" ist kein Kriterium, sondern ein Termin mit Ihnen.

Planen — und wann nicht

8:35 Jetzt ein Kapitel mit einer Ausnahme, und die Ausnahme ist mir wichtig. Denn ohne sie wird aus guter Praxis ein Ritual — und Rituale verlieren Menschen schnell die Lust an Werkzeugen. Planen lohnt oft. Aber eben nicht immer. Bei unklarem Ansatz, bei Änderungen über mehrere Dateien und in fremdem Code lohnt es, zuerst einen Plan erstellen und abnehmen zu lassen — dort ist der Plan das billigste Korrekturmittel, das es gibt.

9:01 Bei kleinen, klar umrissenen Änderungen kostet das Planen mehr, als es einbringt. Die Dokumentation formuliert die Regel so schön, dass ich sie wörtlich vorlese: Wenn Sie den Änderungssatz in einem Satz beschreiben können, lassen Sie den Plan weg. Das ist ein Kriterium, das jeder sofort anwenden kann. Vier Gegenüberstellungen, und sie lassen sich auf eine Frage reduzieren: Ist unsicher, wie es gemacht werden soll?

9:25 Wenn der Ansatz unsicher ist, wenn mehrere Dateien betroffen sind, wenn der Code unbekannt ist, wenn die Anforderung noch unscharf ist — dann planen. Wenn der Änderungssatz in einem Satz beschreibbar ist, wenn es eine Umbenennung oder eine Logzeile ist, wenn die Stelle bekannt und klein ist — dann nicht. Die rechte Spalte ist der Grund, warum ich dieses Kapitel überhaupt so ausführlich mache: Ohne sie planen die Leute drei Tage lang alles und hören dann ganz damit auf.

9:51 Vier Wirkungen, und die zweite ist die unterschätzte. Er macht den Ansatz prüfbar, bevor Code entsteht. Er zeigt, was der Agent verstanden hat — und, viel wichtiger, was nicht. Ein Plan ist ein Spiegel Ihres Auftrags: Was darin fehlt, fehlte meist schon in der Beauftragung. Er lässt sich korrigieren, ohne dass Arbeit verloren geht — Sie werfen einen Absatz weg, keinen Nachmittag.

10:15 Und er wird später zum Maßstab für den Review: Sie prüfen den Änderungssatz gegen den Plan, nicht gegen ein Gefühl.

Prüfungen vom Agenten ausführen lassen

10:23 Und jetzt der wirksamste einzelne Hebel des ganzen Moduls. Ein Check, der Bestanden oder Nicht-bestanden liefert, schließt die Schleife. Ohne einen solchen Check bleibt „sieht fertig aus" das einzige Signal — und Sie selbst sind die Prüfschleife. Ein Agent hört auf, wenn die Arbeit fertig aussieht. Das ist keine Kritik, das ist die Funktionsweise.

10:44 Gibt es aber einen Check, den er selbst ausführen kann, schließt sich die Schleife ohne Menschen: arbeiten, prüfen, Ergebnis lesen, nacharbeiten. Ein Bild: der Unterschied zwischen einem Lehrling, der Ihnen jedes Werkstück zum Nachmessen bringt, und einem, der die Lehre selbst in der Hand hat. Ohne Check sind Sie die Prüfschleife — und jeder Fehler wartet darauf, bemerkt zu werden. Meistens von Ihnen, meistens später.

11:09 Dieselben drei Skripte, die wir in Modul 8 in die Pipeline gehängt haben. Jetzt haben sie einen zweiten Nutzer. Und die Fußzeile schlägt den Bogen zurück: Deshalb bekam dort jedes Tor ein eigenes Skript. Ein Agent ruft sie einzeln auf und arbeitet gezielt nach — bei einem Typfehler anders als bei einem fehlgeschlagenen Test.

11:29 Wären alle drei in einem Sammelaufruf versteckt, bekäme er nur „irgendetwas ist rot" und müsste raten. Es ist bemerkenswert, wie oft gute Praxis für Menschen sich als gute Praxis für Maschinen herausstellt. Vier Merkmale, und das letzte ist das anspruchsvollste. Er liefert ein eindeutiges Bestanden oder Nicht-bestanden — kein „mit Warnungen".

11:50 Er ist ohne Rückfrage ausführbar und braucht keine Sonderrechte; alles, was nach einer Freigabe fragt, unterbricht die Schleife. Sein Ergebnis ist lesbar, nicht nur ein Rückgabewert — der Agent muss verstehen, was schiefging. Und dann der vierte: Er prüft das Ziel der Aufgabe, nicht nur die Syntax. Ein Testlauf, der die neue Anforderung gar nicht abdeckt, ist ein grüner Check ohne Aussage.

Nachweis statt Behauptung

12:15 Jetzt zum Review. Und die Kernregel ist knapp: den Änderungssatz prüfen, nicht die Zusammenfassung. Dazu gehört allerdings auch eine Warnung in die andere Richtung — auch der Prüfer hat eine Schlagseite, und wer beauftragt ist, Lücken zu finden, findet welche. Ein Agent, der berichtet, alles sei erledigt, hat damit nichts nachgewiesen.

12:35 Verlangt wird der Beleg: die Testausgabe, der ausgeführte Befehl mit seinem Ergebnis, der Änderungssatz. Und jetzt der Satz, den ich für den praktisch wichtigsten dieses Kapitels halte: Der Review gilt den Entscheidungen im Änderungssatz, nicht der Zusammenfassung am Ende. Denn die Zusammenfassung ist die unzuverlässigste Stelle des ganzen Laufs — sie entsteht zuletzt, aus dem Gedächtnis, und sie ist genau dazu gemacht, plausibel zu klingen.

13:01 Vier Prüfrichtungen. Die getroffenen Entscheidungen, nicht das Endergebnis allein — warum wurde es so gebaut? Änderungen außerhalb des beauftragten Umfangs, denn die passieren, und sie sind selten böswillig, aber immer ungeplant. Belege: Welche Prüfung lief, mit welchem Ergebnis? Und der vierte Punkt ist zugleich eine Entlastung: fehlende Fälle statt Stilfragen. Stil lässt sich automatisieren und ist selten die Ursache eines Ausfalls.

13:28 Ein nicht behandelter Fall schon. Der zweite Punkt ist mir wichtig, weil er in die entgegengesetzte Richtung warnt: nicht jeden Befund eines Prüfers abarbeiten. Wer beauftragt ist, Lücken zu finden, findet welche — und wenn man alle Funde abarbeitet, landet man beim Über-Engineering. Sie bleiben derjenige, der entscheidet, was zählt.

13:49 Der erste Punkt ist der bekannte: der Zusammenfassung glauben, ohne den Änderungssatz geöffnet zu haben. Und der dritte ist ein methodischer Hinweis: Lassen Sie nicht dieselbe Sitzung prüfen, die den Code geschrieben hat. Sie prüft ihre eigenen Annahmen mit.

Werkzeugunabhängigkeit

14:04 Zum Abschluss die Einordnung, die diesem Modul seine Haltbarkeit gibt. Zwei Anbieter, unabhängig geschriebene Dokumentationen — und dieselben Schlüsse. Das ist der Grund, warum wir hier Vorgehen unterrichten und nicht Bedienung. Das Vorgehen dieses Moduls ist keine Eigenheit eines Produkts. Die Dokumentationen zweier Anbieter kommen unabhängig voneinander zu denselben Punkten: erst erkunden, dann planen, präzisen Kontext geben, ein prüfbares Abschlusskriterium setzen, den Agenten selbst prüfen lassen und den Änderungssatz begutachten.

14:37 Sechs Punkte, zweimal unabhängig gefunden. Wenn zwei Hersteller, die miteinander konkurrieren, dasselbe empfehlen, dann liegt das sehr wahrscheinlich nicht am Produkt, sondern an der Sache. Fünf Punkte, fünfmal Ja in beiden Dokumentationen — und in mehreren Fällen sogar mit eigenen Funktionen dafür, etwa einem eigenen Planmodus. Erst erkunden und planen.

14:59 Die Anforderung im Gespräch schärfen und dann festhalten. Präzisen Kontext geben statt zu beschreiben. Ein prüfbares Abschlusskriterium als Bedingung für „fertig". Und: nicht aufhören, wenn der Code erzeugt ist, sondern Prüfung und Nachweis verlangen. Die Belegstellen aus beiden Dokumentationen stehen in unserem Quellendossier — Sie können das selbst nachlesen.

15:22 Vier Folgerungen, und die letzte ist eine handfeste Empfehlung für Ihr Weiterbildungsbudget. Ein Werkzeugwechsel ändert die Bedienung, nicht das Vorgehen. Was Sie einüben, bleibt gültig, wenn das Produkt wechselt — und in diesem Feld wechseln Produkte schnell. Werkzeuge lassen sich dann daran vergleichen, wie gut sie dieses Vorgehen unterstützen; das ist ein deutlich besseres Auswahlkriterium als eine Funktionsliste.

15:46 Und deshalb: Schulung lohnt sich auf das Vorgehen, nicht auf die Oberfläche.

Übung — eine Aufgabe delegieren

15:51 Jetzt delegieren Sie eine Aufgabe vollständig. Und achten Sie auf die Tagline, denn sie beschreibt die Pointe der Übung: Der Plan ist das Prüfstück, nicht der Code. Was im Plan fehlt, sagt Ihnen etwas über Ihren Auftrag. Das Lernziel: einen Auftrag so formulieren, dass er ohne Rückfragen bearbeitbar ist und sein Abschluss ohne Sie überprüfbar bleibt.

16:12 Erfolgreich sind Sie, wenn der erstellte Plan vor der ersten Codeänderung geprüft wurde und Sie die im Plan gefundene Lücke auf eine fehlende Angabe im Auftrag zurückführen können. Das ist der eigentliche Erkenntnismoment, und er stellt sich fast immer ein: Die Lücke im Plan steht in direktem Zusammenhang mit dem Element, das im Auftrag fehlte.

16:31 Wer früh fertig ist, gibt denselben Auftrag einem zweiten Werkzeug und vergleicht — was unterscheidet sich, und was nicht? Fünf Schritte, und Schritt vier trägt den Lerneffekt, wie die Fußzeile sagt. Zuerst schreiben Sie den Auftrag mit allen vier Elementen — und das Kriterium zuletzt, damit Sie es nicht vergessen. Dann fordern Sie ausdrücklich nur einen Plan an, keine Änderung. Sie prüfen den Plan gegen den Auftrag und notieren die Lücken.

16:56 Dann ergänzen Sie den Auftrag, lassen den Plan neu erstellen und vergleichen — der zweite Plan zeigt unmittelbar, welche Angabe die Lücke verursacht hatte. Und im letzten Schritt lassen Sie umsetzen und verlangen einen Nachweis statt einer Zusammenfassung. Vier Sätze zum Mitnehmen. Ein Auftrag nennt Ziel, Kontext, Randbedingungen und Abschlusskriterium — und das vierte ist das, das fehlt.

17:19 Planen lohnt bei Unsicherheit, nicht, wenn der Änderungssatz in einen Satz passt. Ein selbst ausführbarer Check schließt die Prüfschleife ohne Menschen und ist der wirksamste einzelne Hebel. Und das Vorgehen ist werkzeugunabhängig — das ist belegt, nicht behauptet. Im nächsten Modul lösen wir das Problem mit den mündlich mitgegebenen Randbedingungen: Wir schreiben sie ins Repository.