Feature-Entwicklung mit dem Agenten

Feature-Entwicklung mit dem Agenten

0:00 Jetzt wird es ernst. Bis hierher haben wir vorbereitet: Konventionen festgelegt, Kontext aufgeschrieben, eine Prüfroutine entwickelt. In diesem Modul geben wir einem Agenten zum ersten Mal eine echte Aufgabe an einem echten Projekt. Und Sie werden dabei etwas Interessantes beobachten: Der spannendste Moment ist nicht, wenn der Code entsteht.

0:20 Es ist der Moment davor — wenn der Plan auf dem Tisch liegt und Sie entscheiden, ob er stimmt. Das ist die günstigste Eingriffsstelle im ganzen Ablauf.

Feature-Entwicklung mit dem Agenten

0:30 Der Nachmittag des zweiten Tages gehört der Praxis. Wir lassen uns Lagerwerk erklären, prüfen die Erklärung gegen den Code, ermitteln den Umfang einer neuen Anforderung, korrigieren einen Implementierungsplan und nehmen am Ende ein Ergebnis ab. Ab jetzt ist die Anweisungsdatei aus dem letzten Modul im Einsatz — behalten Sie im Hinterkopf, welche Ihrer Regeln greifen und welche nicht.

0:51 Genau das ist die interessante Beobachtung. Vier Ziele. Wir lassen einen Agenten ein unbekanntes Java-Repository erklären — und prüfen die Erklärung, statt sie zu glauben. Wir erleben praktisch den Unterschied zwischen einem Auftrag und einer Analyse; das klingt nach Wortklauberei und ist der größte Hebel des Tages. Wir lernen, einen Implementierungsplan zu lesen und gezielt zu korrigieren. Und wir setzen ein Feature in Lagerwerk um und nehmen es begründet ab.

1:19 Am Ende haben Sie einen Ablauf, den Sie am Montag wiederholen können.

Ein fremdes Spring-Boot-Repository erschließen

1:24 Beginnen wir mit einer Regel, die einfach klingt und im Alltag ständig gebrochen wird: Die erste Aufgabe an einen Agenten ist nie eine Änderung. Sie ist eine Erklärung. Und die Erklärung wird geprüft. Warum das so wichtig ist, sehen Sie gleich — was ein Agent falsch beschreibt, wird er auch falsch ändern. Die Erklärung ist also nicht Höflichkeit, sondern Diagnostik.

1:47 Wenn eine neue Kollegin an Ihr Projekt kommt, lassen Sie sie erst lesen und dann erzählen, was sie verstanden hat. Nicht weil Sie ihr misstrauen, sondern weil Sie so herausfinden, wo die Dokumentation lügt. Mit einem Agenten machen Sie es genauso: erklären lassen, dann gegen den Code prüfen. Die Stellen, die er falsch beschreibt, sind wertvoll — sie zeigen Ihnen, wo Kontext fehlt. Und sie zeigen es Ihnen jetzt, wo es nichts kostet, statt später im Diff.

2:14 Achten Sie auf zwei Dinge in diesem Auftrag. Erstens: Er fragt nach einem Weg, nicht nach einer Zusammenfassung. „Von der Schnittstelle bis in die Datenbank" zwingt zu einer nachprüfbaren Kette statt zu allgemeinen Sätzen. Zweitens der letzte Satz — „Ändere nichts". Das ist keine Höflichkeitsfloskel, sondern die eigentliche Anweisung.

2:34 Ohne sie beginnt ein Agent gern hilfsbereit mit kleinen Verbesserungen, und dann diskutieren Sie über Code, statt das Projekt zu verstehen. Der Satz kostet drei Wörter und spart eine Viertelstunde. Der dritte Punkt ist der, den ich Ihnen als Arbeitstechnik empfehle: Falsch beschriebene Stellen sind Kandidaten für zusätzlichen Kontext.

2:55 Sie bekommen hier also eine kostenlose Lückenanalyse Ihrer Anweisungsdatei. Wenn der Agent behauptet, die Fachlogik liege in der API-Schicht, dann liegt sie entweder wirklich dort — oder Ihre Beschreibung war unklar. Beides ist eine nützliche Information. Und der letzte Punkt: Die Antwort zeigt, ob die Datei aus dem fünften Modul überhaupt wirkt. Das ist der erste echte Test dafür.

3:18 Der erste Punkt ist die Kernfalle des ganzen Seminars, deshalb steht er auch hier wieder: Die Erklärung glauben, weil sie flüssig formuliert ist. Ein Agent beschreibt ein Projekt, das er falsch verstanden hat, genauso souverän wie eines, das er richtig verstanden hat. Es gibt kein Zögern in der Formulierung. Der dritte Punkt ist der, der Zeit spart: Fehler in der Erklärung nicht achselzuckend hinnehmen.

3:41 Jeder Fehler, den Sie jetzt durch eine Zeile Kontext beheben, taucht später nicht im Code auf.

Analysieren, bevor geändert wird

3:47 Im zweiten Kapitel geht es um zwei Sätze, die dasselbe zu wollen scheinen und zu völlig verschiedenen Ergebnissen führen. „Modernisiere das" gegen „analysiere, begründe, ändere noch nichts". Ich möchte beides mit Ihnen ausprobieren, denn der Kontrast wirkt in der Vorführung deutlich stärker als in jeder Erklärung. Und er verändert danach dauerhaft, wie man Aufträge formuliert — bei mir hat das damals genau eine Vorführung gebraucht.

4:12 Diese beiden Aufträge sind nicht zwei Formulierungen derselben Sache. Der erste liefert Code — fertig, umfangreich, und Sie beginnen mit dem Prüfen bei null. Der zweite liefert eine Entscheidungsgrundlage: eine Liste mit Begründungen, die Sie in zwei Minuten überfliegen und korrigieren können. Es ist der Unterschied zwischen einem Handwerker, der loslegt, und einem, der Ihnen erst zeigt, was er vorhat. Beim zweiten kostet eine Korrektur einen Satz.

4:39 Beim ersten kostet sie einen Rückbau. Lesen Sie diese Tabelle zeilenweise, dann wird das Prinzip sichtbar: Es geht immer darum, wann der Prüfaufwand anfällt. Links landet er am Ende und ist hoch. Rechts liegt er vorn und ist niedrig. Die dritte Zeile ist die entscheidende — Korrektur bedeutet links eine Neuimplementierung, rechts einen Satz.

5:01 Und die vierte ist die, die man am leichtesten übersieht: Beim direkten Auftrag wählt der Agent den Umfang. Er entscheidet, was alles dazugehört. Bei der Analyse entscheiden Sie das. Die Fußzeile fasst zusammen, warum der scheinbare Zeitgewinn keiner ist. Der erste Punkt ist die Kosten-Nutzen-Rechnung in einem Satz: Ein falscher Plan kostet eine Minute, eine falsche Umsetzung einen Nachmittag.

5:25 Der dritte ist der, der fachlich zählt: Begründungen lassen sich fachlich bewerten, Code nur technisch. Wenn im Plan steht, warum eine Stelle geändert werden soll, können Sie als Fachexperte widersprechen. Wenn nur der geänderte Code dasteht, müssen Sie die Begründung erst rekonstruieren. Das ist deutlich mühsamer — und deshalb macht es niemand, und deshalb rutschen fachliche Fehler durch.

5:49 Der zweite Punkt ist der, der die ganze Übung entwertet: Die Analyse anfordern und ungelesen zur Umsetzung übergehen. Das passiert erstaunlich oft, gerade wenn die Analyse lang und gut formuliert ist — man überfliegt sie, nickt und geht weiter. Damit haben Sie eine Zwischenstufe eingebaut, die nichts bringt. Der erste Punkt ist die technische Variante desselben Problems: „Ändere nichts" wegzulassen.

6:12 Ohne diesen Satz bekommen Sie eine Analyse mit bereits geändertem Code, und die Reihenfolge ist wieder dahin.

Betroffene Komponenten identifizieren

6:19 Im dritten Kapitel wird die Analyse konkret. Wir haben eine neue Anforderung an Lagerwerk — Buchungen sollen eine Priorität bekommen — und lassen ermitteln, was das eigentlich bedeutet. Immer noch ohne eine einzige Zeile Code. Das Ergebnis brauchen wir gleich zweimal: als Grundlage für die Aufwandsschätzung, und später als Prüfliste, wenn wir das fertige Ergebnis abnehmen. Zwei Fliegen, eine Frage.

6:44 Der Umfang einer Änderung ist die wichtigste Zahl, bevor Sie irgendetwas zusagen. In einem gewachsenen Java-Projekt ist er auch die am schwersten zu schätzende — ein neues Feld klingt nach fünf Minuten und berührt am Ende die Schnittstelle, die Persistenz, drei Tests und ein Migrationsskript. Genau das lassen wir jetzt ermitteln. Und dann kommt der lehrreiche Teil: Sie vergleichen die Liste mit Ihrer eigenen Einschätzung.

7:08 Beide werden Fehler enthalten, aber unterschiedliche — und daraus lernen Sie mehr als aus jeder richtigen Antwort. Beachten Sie, wie konkret die Anforderung formuliert ist: Nicht „Buchungen sollen priorisiert werden können", sondern mit den drei Ausprägungen in Klammern. Vage Anforderungen erzeugen vage Listen. Und wieder steht am Ende der wichtige Satz — keine Änderungen.

7:29 Die Fußzeile enthält den eigentlichen Lernauftrag: Vergleichen Sie das Ergebnis mit Ihrer eigenen Einschätzung. Schreiben Sie Ihre Schätzung vorher auf, sonst passiert das, was uns allen passiert: Man liest die Liste und findet im Nachhinein, man hätte es genauso gesehen. Der dritte Punkt ist der, der später Zeit spart: Die Liste ist zugleich die Prüfliste für das Ergebnis.

7:52 Wenn am Ende des Moduls das Feature umgesetzt ist, gehen Sie diese Liste durch und haken ab. Ohne sie prüfen Sie gegen Ihr Gedächtnis, und das ist nach zwei Stunden Arbeit kein guter Maßstab. Der vierte Punkt ist der didaktische, und er richtet sich an die Erfahrenen im Raum: Der Vergleich mit der eigenen Schätzung schult das Urteil. Auch nach zwanzig Jahren.

8:13 Die ersten beiden Punkte nennen die Stellen, die in Java-Projekten am häufigsten vergessen werden — von Menschen wie von Werkzeugen: Konfiguration und Datenbankschema. Ein neues Feld an einer Entität bedeutet fast immer auch ein Migrationsskript, und das steht in einem ganz anderen Verzeichnis, oft in einem anderen Format.

8:31 Der dritte Punkt betrifft die Außenwelt: Schnittstellen, die sich mitändern. Wenn Ihre API die Buchung ausliefert, hat sie ab jetzt ein Feld mehr — und irgendjemand da draußen verlässt sich auf die alte Form.

Den Plan menschlich prüfen

8:43 Und damit zum wichtigsten Kapitel dieses Moduls. Wenn ich Ihnen aus dem ganzen zweiten Tag eine einzige Sache mitgeben dürfte, wäre es diese: Der Plan ist die günstigste Eingriffsstelle im ganzen Ablauf. Wir lesen jetzt gemeinsam einen und korrigieren ihn live. Sie werden sehen, wie wenig Aufwand das ist — und wie viel es verändert.

9:04 Aus der Analyse entsteht ein Implementierungsplan: Reihenfolge, betroffene Dateien, vorgesehene Tests. Das ist ein Dokument von einer halben Seite, das Sie in zwei Minuten lesen. Und in diesen zwei Minuten entscheidet sich, ob der nächste Nachmittag gut wird. Denken Sie an einen Bauplan: Eine Wand an der falschen Stelle ist auf dem Papier ein Strich, den Sie verschieben. Im gemauerten Zustand ist sie ein Abriss.

9:28 Nur dass Softwarepläne den Vorteil haben, dass wirklich niemand zwei Minuten dafür entbehren kann. Fünf Fragen, und sie führen von außen nach innen. Zuerst die fachliche Reihenfolge — stimmt sie überhaupt? Dann der Abgleich mit der Liste aus dem letzten Kapitel: Fehlt eine Stelle? Frage drei ist verräterisch: Sind Tests vor oder nach der Änderung geplant?

9:50 Daran sehen Sie, ob der Agent Absicherung verstanden hat oder nur abarbeitet. Und Frage fünf ist die, die man aus Ungeduld überspringt: Ist der Umfang für einen Schritt zu groß? Bei Zweifel lieber teilen. Ein Schritt, den Sie nicht mehr am Stück prüfen können, ist ein Schritt zu groß. Der zweite Punkt ist der, der in der Praxis über den Nachmittag entscheidet: Die Reihenfolge entscheidet, ob Zwischenstände lauffähig sind.

10:16 Ein Plan, der erst alle Schnittstellen ändert und dann die Implementierung nachzieht, hat dazwischen einen Zustand, in dem nichts baut — und wenn Sie dort abbrechen müssen, stehen Sie mit einem kaputten Projekt da. Der letzte Punkt ist praktisch: Ein geteilter Plan ergibt prüfbare Zwischenergebnisse. Und prüfbare Zwischenergebnisse sind das, was Sie brauchen, wenn zwischendurch jemand ins Büro kommt.

10:38 Der erste Punkt ist der, den ich selbst am häufigsten begehe: den Plan überfliegen, weil er vernünftig klingt. Pläne von Sprachmodellen klingen fast immer vernünftig — sie sind gut strukturiert, vollständig formuliert und in sich schlüssig. Schlüssigkeit ist aber kein Beweis für Richtigkeit. Der letzte Punkt ist eine praktische Empfehlung: Bewahren Sie den Plan auf.

11:00 Am Ende des Moduls vergleichen wir das Ergebnis mit ihm, und ohne aufbewahrten Plan fehlt Ihnen dafür der Maßstab. Ein Textabschnitt in einer Datei reicht völlig.

Implementieren lassen und Tests ausführen

11:10 Jetzt darf endlich geändert werden. Wir haben erklären lassen, analysiert, den Umfang ermittelt und den Plan korrigiert — die Vorarbeit ist getan. Achten Sie in diesem Kapitel weniger auf die Umsetzung selbst, die wird vermutlich funktionieren. Achten Sie auf etwas anderes: wie der Agent reagiert, wenn ein Test rot wird.

11:29 Das ist der aufschlussreichste Moment des ganzen Nachmittags, und er dauert nur ein paar Sekunden. Erst nach dem geprüften Plan ändert der Agent Code, ergänzt Tests und führt das hinterlegte Kommando aus. Jetzt zahlt sich alles aus, was wir vorbereitet haben — die Modulgrenzen, die Ausschlüsse, vor allem das Testkommando aus dem fünften Modul.

11:50 Interessant ist dabei weniger, dass es funktioniert. Interessant ist das Verhalten bei Fehlschlägen. Ein Mensch, der einen roten Test sieht, fragt sich: Habe ich einen Fehler gemacht? Ein Agent fragt sich manchmal: Wie bekomme ich den Test grün? Das ist ein feiner, folgenreicher Unterschied. Vier Zeilen Auftrag, und jede hat eine Funktion. Der Verweis auf den geprüften Plan bindet an das, was wir gerade korrigiert haben.

12:16 Der Verweis auf die Anweisungsdatei bindet an die Konventionen von gestern. Das Testkommando steht ausdrücklich da, obwohl es auch in der Datei steht — doppelt hält hier tatsächlich besser. Und dann der letzte Halbsatz, auf den es mir ankommt: Fehlschläge berichten, statt sie zu umgehen. Denn die häufigste Ausweichreaktion ist nicht, den Fehler zu verstecken.

12:37 Sie ist, den Test anzupassen, bis er passt. Der letzte Punkt ist der, den ich Ihnen als Beobachtungsauftrag mitgebe: Das Verhalten bei Rot sagt mehr über den Agenten als jede Erfolgsmeldung. Wenn alles funktioniert, sehen alle Werkzeuge gut aus. Der Unterschied zeigt sich, wenn etwas schiefgeht — meldet er es, versucht er eine Umgehung, oder ändert er stillschweigend den Maßstab?

13:00 Der dritte Punkt ist die praktische Absicherung dagegen: Schrittweises Testen hält die Zuordnung von Fehler und Ursache intakt. Bei drei Schritten am Stück wissen Sie nachher nicht mehr, welcher es war. Der erste Punkt ist die klassische Umkehrung, und Sie werden sie erleben: Der Agent passt den Test an die Implementierung an statt umgekehrt.

13:20 Das ist aus seiner Sicht sogar konsequent — der Auftrag lautete, es zum Laufen zu bringen. Nur ist ein Test, der an die Implementierung angepasst wurde, kein Test mehr, sondern eine Beschreibung. Der letzte Punkt ist der subtilere: nebenbei aufgeräumt, ohne dass es im Plan stand. Das ist gut gemeint und macht Ihren Diff unlesbar — dann suchen Sie die fachliche Änderung zwischen achtzig Formatierungszeilen.

Ergebnisse prüfen

13:44 Zum Abschluss des Tages die Abnahme. Wir wenden dieselbe Prüfroutine an wie im vierten Modul, nur auf deutlich mehr Code. Und wir stellen eine zusätzliche Frage, die es bei einzelnen Vorschlägen nicht gab: Wo ist der Agent vom Plan abgewichen? Diese Frage ist der eigentliche Lernschritt des Moduls, denn ihre Antwort wandert direkt zurück in die Anweisungsdatei aus Modul 5.

14:06 Am Ende steht die Prüfung: fachliche Korrektheit, Einhaltung der Projektregeln, Nebenänderungen, neue Abhängigkeiten. Das ist dieselbe Routine wie bei einzelnen Vorschlägen — nur dass es jetzt nicht um zehn Zeilen geht, sondern um zweihundert. Das verändert nichts an den Kriterien, aber viel an der Disziplin. Bei zehn Zeilen prüft man automatisch mit. Bei zweihundert muss man sich hinsetzen.

14:30 Und genau deshalb ist eine feste Routine hier mehr wert als bei jedem Einzelvorschlag. Fünf Schritte, und der erste ist unbequem: Den Diff vollständig lesen, nicht überfliegen. Ich weiß, das klingt nach Zumutung bei zweihundert Zeilen. Es ist trotzdem die einzige vollständige Wahrheit über die Änderung — alles andere ist eine Erzählung darüber. Schritt zwei nutzt die Liste aus dem dritten Kapitel.

14:55 Schritt vier prüft Tests auf Aussagekraft, nicht auf Farbe. Und Schritt fünf ist der Lernschritt: Abweichungen vom Plan benennen. Nicht um zu tadeln — sondern um herauszufinden, warum. Meistens fehlte Kontext. Der zweite Punkt ist der wertvollste dieses ganzen Moduls: Abweichungen vom Plan zeigen Lücken im Kontext oder in den Regeln.

15:16 Jede Abweichung ist eine kostenlose Verbesserung Ihrer Anweisungsdatei. Der Agent ist an einer Stelle vom Plan abgewichen, weil ihm etwas fehlte oder etwas unklar war — und genau das schreiben Sie jetzt auf. Nach drei, vier solchen Runden haben Sie eine Datei, die tatsächlich zu Ihrem Projekt passt. Das ist der Weg. Nicht: alles vorher richtig aufschreiben.

15:38 Der zweite Punkt ist eine praktische Empfehlung für den Alltag: Formatierungsänderungen und fachliche Änderungen nicht vermischen. Wenn beides in einem Durchgang passiert, ist der Diff faktisch unprüfbar, und dann prüft niemand. Trennen Sie das, notfalls in zwei Durchläufen. Der letzte Punkt ist der, den man aus Zeitmangel weglässt und dann jedes Mal wieder erlebt: Die Abweichungen nicht zurück in die Anweisungsdatei spielen.

16:02 Dann korrigieren Sie beim nächsten Mal denselben Fehler noch einmal — und beim übernächsten wieder. Jetzt gehen Sie den ganzen Weg allein: Analyse, Plan, Prüfung, Umsetzung, Abnahme. Die Priorität an Buchungen ist die Anforderung. Das Erfolgskriterium ist bewusst nicht nur „läuft" — es lautet, dass Sie jede Abweichung vom Plan benennen und erklären können.

16:23 Und vergleichen Sie zum Schluss den tatsächlichen Umfang mit Ihrer Schätzung von vorhin. Diese beiden Zahlen nebeneinander sind lehrreicher als alles, was ich Ihnen heute erzählen kann. Damit endet der zweite Tag. Sie haben gesehen: Erklären lassen kommt vor Ändern, und die Erklärung wird geprüft. Analyse und Plan sind die günstigsten Eingriffsstellen — dort kostet eine Korrektur einen Satz.

16:47 Das hinterlegte Testkommando trägt die ganze Umsetzungsschleife, ohne dass jemand darüber nachdenken muss. Und Abweichungen vom Plan sind keine Ärgernisse, sondern Rückmeldung an Ihre Anweisungsdatei. Morgen wenden wir genau diesen Ablauf auf die Aufgabe an, die in Ihren Häusern tatsächlich ansteht: die Migration.