Agentische Implementierung mit bmad-build

Agentische Implementierung mit bmad-build

0:00 Bis hierher haben wir vorbereitet: Kontext, Spezifikation, Entscheidungen, Schnitte. Jetzt wird gebaut — und zwar zum ersten Mal mit dem Agenten am Steuer. Das ist der Moment, in dem sich zeigt, ob die Vorbereitung etwas taugt. Die gute Nachricht vorweg: Wenn die Vorarbeit stimmt, ist dieser Teil erstaunlich unspektakulär.

0:19 Die schlechte: Wenn sie fehlt, merken Sie es genau hier, und zwar in Form von Rückfragen mittendrin oder von Entscheidungen, die jemand für Sie getroffen hat.

Agentische Implementierung

0:29 Vier Kapitel. Zuerst der Ablauf einer Build-Sitzung, von der frischen Sitzung bis zum Ergebnis. Dann die Frage, wie man einen Agenten wirksam steuert — mit einem klaren Rat, den viele zunächst überraschend finden. Danach der Sonderfall bestehender Code, der bei uns allen der Normalfall ist. Und zum Schluss die Auswertung: fünf Dinge nebeneinanderlegen, bevor irgendetwas freigegeben wird.

Ablauf einer Build-Session

0:53 Beginnen wir mit dem Ablauf. Er ist bewusst schlicht gehalten und hat trotzdem zwei Stellen, die den Unterschied machen: der Start in einem frischen Kontext und die Frage, wann ein Plan zur Freigabe vorgelegt wird. Beides klingt nach Formalität und ist es nicht. Sechs Phasen, und die erste ist die, die man am liebsten überspringt: frischer Kontext.

1:14 Es ist verlockend, im Fenster weiterzuarbeiten, in dem man gerade diskutiert hat — schließlich weiß der Agent dort schon so viel. Genau das ist das Problem. Er weiß dort auch alles, was verworfen wurde, und kann beides nicht sauber trennen. Danach folgt Vertrautes: Intent nennen, an der Codebasis klären, bei Bedarf einen Plan vorlegen, umsetzen, sich selbst reviewen, zusammenfassen.

1:37 Der Auftrag darf dabei ausdrücklich unstrukturiert sein — die Artefakte tragen die Struktur. Der dritte Schritt ist der, den ich hervorheben möchte: den Intent an Belegen klären. Der Agent liest also nicht nur Ihren Auftrag, sondern schaut nach, was das Repository dazu sagt und was in den vorgelagerten Artefakten steht. Das ist der Unterschied zwischen Vermutung und Evidenz. Die Fußzeile beschreibt, wann es ohne Plan geht: wenn Intent, Umkehrbarkeit und Fußabdruck unauffällig sind.

2:06 Alle drei müssen unauffällig sein — eines reicht nicht. Und wenn eines auffällig ist, kostet der Plan zehn Minuten und erspart Ihnen möglicherweise eine unangenehme Überraschung. Die ersten vier Zeilen erwarten Sie: geänderte Dateien, ein Testlauf, ein Commit, ein Protokoll der Sitzung. Die interessanteste ist die fünfte, und die Fußzeile sagt auch warum.

2:28 Dort steht, was der Agent nicht getan hat — bewusst offen Gelassenes, entdeckte Nebenbaustellen, aufgeschobene Verbesserungen. Diese Liste ist deshalb so wertvoll, weil sie sonst nirgends existiert. Ohne sie verschwindet das Wissen im Chatverlauf, und drei Wochen später fragt jemand, warum eigentlich niemand den fehlenden Index bemerkt hat. Bemerkt hatte ihn jemand.

2:50 Es stand nur nirgends. Drei Kriterien entscheiden, ob ein schriftlicher Plan nötig ist. Erstens: Hat der Intent Lücken, die sonst jemand füllt? Zweitens: Ist die Änderung umkehrbar — Migrationen, Löschungen und Veröffentlichungen sind es nicht. Drittens: Wie groß ist der Fußabdruck? Sind alle drei unauffällig, kostet die Freigabe nur Zeit, und dann sollte man sie sich sparen.

3:14 Diese Ehrlichkeit gefällt mir an dem Modell: Es verlangt nicht überall dasselbe Ritual, sondern koppelt den Aufwand an das tatsächliche Risiko. Wer das umdreht, bekommt Freigaben, die reflexhaft erteilt werden.

Den Agenten wirksam steuern

3:28 Das zweite Kapitel behandelt eine Fähigkeit, die man tatsächlich üben muss: steuern. Nicht im Sinne von möglichst genauen Anweisungen — eher im Gegenteil. Wer zu genau vorgibt, bekommt weniger, nicht mehr. Sehen wir uns an, woran das liegt. Und wie man einen Auftrag formuliert, der ein Ergebnis beschreibt statt eines Weges.

3:49 Steuern heißt hier drei Dinge: das Ziel und die Freiheitsgrade festlegen, Rückfragen zügig beantworten und früh korrigieren, statt hinterher einen zweiten Auftrag über den ersten zu legen. Der Vergleich, der mir dazu einfällt, ist das Taxi vom Anfang: Sie sagen das Ziel und nennen die Bedingungen — keine Autobahn, bitte über die Brücke.

4:08 Sie diktieren nicht jede Abbiegung. Und wenn Sie merken, dass es in die falsche Richtung geht, sagen Sie das sofort und nicht erst am Zielort. Der erste Punkt ist der zentrale: Ein beauftragtes Ergebnis lässt Lösungswege offen, eine diktierte Zeile nicht. Wer das Wie vorgibt, hat die Verantwortung für das Wie übernommen — und dafür brauchte es keinen Agenten.

4:30 Der zweite Punkt ergänzt das: Freiheitsgrade explizit setzen, also sagen, was er wählen darf und was nicht. Der dritte klingt banal und ist es nicht: Eine Rückfrage kostet dreißig Sekunden, eine falsche Annahme zieht sich durch drei Dateien. Und ein Abbruchkriterium verhindert das endlose Reparieren am selben Fehler. Die zweite Zeile ist die lehrreichste. „Mach die Tests grün" ist ein Auftrag, den man wörtlich erfüllen kann — indem man die Tests ändert.

4:58 Das ist keine Böswilligkeit, das ist Wörtlichkeit. „Kriterium X muss geprüft sein" lässt sich nicht auf diesem Weg erfüllen. Ähnlich die dritte Zeile: „Räum das mal auf" ist eine Einladung zum Scope Drift, weil Aufräumen kein Ende hat. Die Fußzeile fasst das Prinzip: Wer das Wie diktiert, übernimmt die Verantwortung für das Wie. Und zwar auch dann, wenn er das gar nicht wollte.

5:22 Scope Drift kennen Sie schon vom ersten Modul — hier ist der Ort, an dem er entsteht. Prompt-Kaskaden sind der zweite Punkt: Wenn Sie Korrektur auf Korrektur legen, weiß am Ende niemand mehr, was der ursprüngliche Auftrag war, der Agent eingeschlossen. Der dritte Punkt ist der, den ich am ernstesten nehme: Der Diff wird überflogen statt gelesen. Genau dort steckt aber die eigentliche Arbeit des Prüfens.

5:45 Und der vierte betrifft die zurückgestellte Arbeit — wenn sie nie wieder angesehen wird, gilt sie faktisch als erledigt, ohne es zu sein.

Brownfield und Legacy

5:53 Jetzt zu dem Fall, der für die meisten von uns der Normalfall ist: bestehender Code. Greenfield-Anleitungen führen hier zuverlässig in die Irre, und zwar aus einem Grund, der sich in einem Satz zusammenfassen lässt — das Vorhandene ist Evidenz, nicht Altlast. In bestehendem Code zählt zuerst, was da ist. Moderne Agenten lesen Wissen sehr gut aus Code — deutlich besser als aus Prosa über Code.

6:17 Das hat eine praktische Konsequenz: Sie müssen weniger erklären, als Sie denken, aber Sie müssen etwas anderes tun, nämlich sagen, wenn Sie eine Abweichung wollen. Denn ohne ausdrücklichen Auftrag übernimmt der Agent die vorhandenen Muster. Das klingt konservativ und ist genau richtig. Ein Modul mit zwei Stilen ist schlechter als ein Modul mit einem alten Stil.

6:39 Vier Gründe für Zurückhaltung. Der erste ist Konsistenz: Ein modernisiertes Muster erzeugt zwei Stile im selben Modul, und der nächste Leser weiß nicht, welcher gilt. Der zweite ist der Charakterisierungstest — er hält das heutige Verhalten fest, bevor man es ändert, und ist damit die Versicherung gegen unbemerkte Änderungen.

6:58 Der dritte: Kleine, umkehrbare Schritte lassen sich einzeln zurücknehmen. Und der vierte betrifft technische Schulden. Sie gehören notiert, nicht nebenbei mitrepariert — sonst wächst der Diff und mit ihm das Risiko, dass niemand ihn mehr gründlich liest. Der erste Schritt ist der entscheidende und wird trotzdem oft ausgelassen: Das Verhalten mit einem Test festhalten, bevor irgendetwas geändert wird.

7:22 Ein solcher Test beschreibt nicht, was sein sollte, sondern was ist — auch wenn es seltsam aussieht. Danach dem vorhandenen Muster folgen, die Änderung klein halten, beobachtete Schulden getrennt aufschreiben. Und erst dann über Modernisierung sprechen. Die Fußzeile bringt es auf den Punkt: Wer modernisieren will, beauftragt das ausdrücklich. Sonst geschieht es nebenbei, und niemand hat es entschieden.

7:46 Der erste Punkt ist ein Klassiker aus Bestandsprojekten: Veraltete Dokumentation wird für bare Münze genommen — vom Agenten wie vom Menschen. Der zweite ist der Grund für den Charakterisierungstest: Ohne ihn ändert sich Verhalten unbemerkt. Der dritte ist das ungefragte Aufräumen, das immer gut gemeint ist. Und der vierte ist der leiseste: Schulden werden im Chat erwähnt und landen in keiner Liste.

8:09 Damit sind sie faktisch nicht erwähnt worden, weil niemand den Chatverlauf von vor drei Wochen durchsucht.

Ergebnisse auswerten

8:15 Zum Abschluss des Moduls die Auswertung. Sie ist der Moment, in dem sich entscheidet, ob der ganze Prozess etwas wert war — denn hier legen wir zum ersten Mal nebeneinander, was vereinbart war und was tatsächlich passiert ist. Fünf Dinge kommen dabei auf den Tisch, und eines davon wird regelmäßig vergessen. Fünf Dinge kommen nebeneinander: Spezifikation, Plan, Diff, Testlauf und die Liste dessen, was zurückgestellt wurde. Erst dieser Vergleich trägt eine Freigabe.

8:43 Der Punkt dabei ist nicht Misstrauen gegenüber der Maschine. Der Punkt ist, dass Abweichungen normal sind und trotzdem sichtbar werden müssen. In unserem Beispiel gab es eine: Die Positionsvergabe zählt aktive statt aller Einträge. Das war richtig — der Plan hatte dazu nur nichts gesagt. Solche Abweichungen sind gutes Material, wenn man sie bemerkt, und ein Risiko, wenn nicht.

9:07 Jetzt sind Sie dran, und diesmal wird tatsächlich gebaut. Lassen Sie eine Story umsetzen und prüfen Sie anschließend das Ergebnis gegen Ihre eigene Vereinbarung. Legen Sie die fünf Dinge nebeneinander und bewerten Sie jede Abweichung. Der Hinweis auf der Folie ist mir wichtig: Notieren Sie auch die begründeten Abweichungen.

9:26 Sie sind kein Fehler, aber sie sind Material — für die Retrospektive und für die Frage, ob Ihre Spezifikation an dieser Stelle vielleicht zu grob war. Der erste Punkt ist der gefährlichste im ganzen Seminar: Der Testlauf ist grün, prüft aber die Annahme statt der Anforderung. Dagegen hilft nur der Bezug zur Spezifikation.

9:45 Der zweite ist Bequemlichkeit: Die Zusammenfassung des Agenten liest sich gut, der Diff ist mühsam — und trotzdem steht die Wahrheit im Diff. Der dritte ist menschlich verständlich: Abweichungen werden akzeptiert, weil das Ergebnis funktioniert. Und der vierte: Ohne Notiz bleibt die Erfahrung in einer Sitzung, die niemand wiederfindet.

10:05 Vier Punkte gehen mit. Frischer Kontext, geklärter Intent, ein Plan nur dort, wo er nötig ist. Ein Ergebnis beauftragen statt Zeilen zu diktieren — das ist die Fähigkeit, die man üben muss. In bestehendem Code gilt das vorhandene Muster als Beleg, nicht als Altlast. Und die Freigabe kommt erst nach dem Vergleich von Spezifikation, Diff, Tests und Offengebliebenem.

10:28 Wobei genau hier eine Frage offen bleibt: Wer prüft eigentlich, wenn derselbe Kontext gebaut und bewertet hat? Darum geht es im nächsten Modul.