Capstone: Ein kontrollierter agentischer Entwicklungsworkflow

Capstone: Der kontrollierte Workflow

0:00 Am Ende zählt nicht, wie viel Code entstanden ist, sondern ob jemand für ihn geradestehen kann. Mit diesem Maßstab schließen wir das Seminar. Im Capstone laufen alle drei Tage zusammen: der eigene MCP-Server aus Tag eins, die Arbeitsweise aus Tag zwei, die Absicherung aus Tag drei. Und zwar nicht als Wiederholung, sondern an einem Change Request, den Sie vollständig durchziehen — von der Anforderung bis zum Übergabepaket.

Capstone — Ein kontrollierter agentischer Entwicklungsworkflow

0:26 Vier Phasen: Anforderung klären, analysieren und planen, implementieren und prüfen, übergeben. Dazu am Schluss ein gegenseitiges Review nach einem gemeinsamen Raster. Nehmen Sie sich Zeit für die erste Phase — die Erfahrung aus vielen Durchläufen ist, dass Teams, die dort zwanzig Minuten mehr investieren, hinten eine Stunde sparen.

Anforderung klären und begrenzen

0:46 Beginnen wir mit dem Change Request. Und mit den Fragen, die er offenlässt. Die Aufgabe: Serviceanfragen im Anliegenbuch sollen künftig eine Frist tragen und nach deren Ablauf eskalieren. Ein Satz, zwei Substantive, und dahinter eine ganze Reihe von Entscheidungen, die niemand getroffen hat. Genau das ist der Normalfall.

1:06 Die Arbeit beginnt deshalb nicht mit Code, sondern mit der Frage, was davon entschieden ist und was nicht — und wer das entscheiden müsste. Fünf Schritte, und der fünfte enthält die eigentliche Disziplin: Erst danach den Agenten beauftragen. Nicht parallel, nicht probeweise. Die Fußzeile nennt den Schritt, der am häufigsten fehlt: Wer die Abbruchkriterien überspringt, merkt es an der dritten Korrekturschleife — und dann ist es zu spät, sie noch zu vereinbaren, weil man mittendrin steckt und weitermachen will.

1:36 Vier Fragen, die im Ticket garantiert nicht stehen. Ab wann läuft die Frist — ab Eingang oder ab erster Bearbeitung? Was passiert mit Anfragen, die heute keine Frist haben? An wen eskaliert eine abgelaufene Frist? Und zählen Wochenenden und Feiertage mit? Jede einzelne ist eine fachliche Entscheidung. Ein Agent wird alle vier treffen, wenn Sie sie offenlassen — schnell, plausibel und ohne Ihnen zu sagen, dass er es getan hat.

2:04 Der erste Punkt ist die Versuchung unter Zeitdruck: Der Auftrag startet, obwohl die erste Frage unbeantwortet ist. Der zweite zeigt, wie ein Auftrag wächst, wenn die Grenze fehlt — aus einer Fristenregel wird ein Benachrichtigungssystem mit Eskalationsstufen und Kalenderanbindung. Der dritte ist ein Organisationsfehler, den man vorher klären muss: Die Freigabestelle ist genannt, aber nicht verfügbar.

2:27 Und der vierte macht Abbruchkriterien wirkungslos: Sie sind so weit, dass sie nie greifen.

Analysieren, planen, freigeben

2:33 Phase zwei. Hier arbeitet der Agent zum ersten Mal — und zwar recherchierend, nicht schreibend. In dieser Phase ermittelt der Agent über anliegen-mcp, was die Änderung berührt, und legt einen Plan vor. Der Plan wird geprüft und freigegeben, bevor eine Zeile Code entsteht. Das ist die Stelle, die wir in Modul 11 als die letzte billige Korrekturmöglichkeit bezeichnet haben — und im Capstone wird sichtbar, wie viel sie wert ist.

3:00 Ein früh erkannter Denkfehler kostet fünf Minuten. Derselbe Fehler nach der Implementierung kostet den halben Nachmittag. Vier Artefakte mit klarer Zuständigkeit. Die Impact-Analyse verantwortet der Agent, über das Werkzeug zur Komponentenermittlung. Den Vorgehensplan samt Annahmen ebenfalls. Prüfung und Korrektur verantwortet das Team. Und die Freigabe mit Zeitpunkt und Person die benannte Freigabestelle.

3:25 Die Fußzeile sagt, warum die letzte Zeile zählt: Sie ist das, was im Zweifel nachweist, dass jemand entschieden hat — und nicht, dass etwas einfach passiert ist. Vier Fragen an den Plan. Warum dieser Schritt zuerst, und was hängt daran? Welche Komponenten sind betroffen — und, mindestens so wichtig, welche ausdrücklich nicht?

3:46 Wo wird eine sicherheitsrelevante Stelle berührt? Und an welcher Stelle ist ein Rückbau noch möglich? Die letzte Frage ist die, die man im Alltag nie stellt und im Ernstfall dringend bräuchte: Bis wohin komme ich zurück, ohne Daten zu verlieren? Der erste Punkt ist der, auf den Sie im Protokoll achten sollten: Die Impact-Analyse wird erzählt statt über Werkzeuge ermittelt.

4:09 Ein überzeugender Absatz ohne einen einzigen Werkzeugaufruf dahinter ist eine Vermutung. Der dritte ist ein Nachweisproblem: Die Freigabe ist mündlich und damit später nicht auffindbar. Und der vierte hebt den Sinn der Phase auf: Der Agent beginnt mit der Umsetzung, während der Plan noch geprüft wird.

Implementieren, prüfen, nachweisen

4:27 Phase drei. Jetzt entsteht Code — in kleinen Schritten und gegen harte Schranken. Die Umsetzung läuft in einem isolierten Zweig, in Schritten, die einzeln prüfbar sind. Jeder Schritt durchläuft die Quality Gates aus Modul 13. Das Diff-Review liest die tatsächliche Änderung und nicht die Zusammenfassung — Modul 12. Und sicherheitsrelevante Stellen bekommen ein unabhängiges zweites Review.

4:52 Sie merken: In dieser Phase erfinden wir nichts Neues. Wir wenden an, was an den ersten beiden Tagen entstanden ist. Vier Stationen, und die Kette wiederholt sich je Schritt — nicht einmal am Ende. Schritt, Gates, Review, Nachweis. Der letzte ist der, der im Alltag ausfällt: Der Nachweis wird nicht festgehalten, weil ja alles grün war. Dann existiert später kein Beleg dafür, dass geprüft wurde.

5:18 Und ein Nachweis, den niemand aufgeschrieben hat, ist im Zweifel keiner. Vier Verbote, und sie sind für das ganze Seminar verbindlich. Keine produktive Bereitstellung. Kein automatisches Merge. Keine irreversible Änderung an Daten. Keine externe Kommunikation ohne Freigabe. Das sind keine Vorsichtsmaßnahmen für Anfänger — das ist die Linie, die auch in einem eingespielten Team bestehen bleiben sollte.

5:45 Alles vier ist umkehrbar, solange es nicht passiert ist, und unumkehrbar, sobald es passiert ist. Der erste Punkt ist die Bequemlichkeit, die den Schnitt entwertet: Die Schritte werden zusammengefasst, weil einzeln zu mühsam. Der zweite ist eine Fehlinterpretation des zweiten Reviews: Es entfällt, weil der erste Reviewer schon geprüft hat — dabei ist Unabhängigkeit der ganze Punkt.

6:08 Der dritte ist der, der die Nachweise wertlos macht: Sie entstehen nachträglich aus dem fertigen Ergebnis. Und der vierte ist der gefährlichste: Eine Datenmigration wird als umkehrbarer Schritt behandelt.

Übergabe und Transfer

6:20 Phase vier. Und die Frage, was am Ende eigentlich übergeben wird. Das Übergabepaket bündelt alles, was ein Dritter braucht, um die Änderung zu beurteilen: Spezifikation, freigegebener Plan, Diff, Testergebnisse, Analyseergebnisse, Threat Model und Review-Protokoll. Dazu die Team-Policy, die festhält, wie künftig gearbeitet wird. Der Prüfstein für das Paket ist einfach: Kann jemand, der nicht dabei war, damit eine Freigabeentscheidung treffen?

6:50 Wenn nicht, fehlt etwas. Sieben Kriterien, und zu jedem ein Nachweis im Paket. Problemverständnis über Ziele, Nicht-Ziele und offene Fragen. Schnittstellendesign über den Tool-Katalog. Kontrollierbarkeit über Plan, Schritte und Freigaben. Sicherheit über Threat Model und Berechtigungen. Qualität über Tests und Gate-Ergebnisse.

7:12 Nachvollziehbarkeit über Aufruffolge, Diff und Review. Und Transfer über die Team-Policy. Die Fußzeile wiederholt den Maßstab: Nicht Menge, nicht Geschwindigkeit — diese sieben Punkte. Vier Sätze, die in jeder Team-Policy stehen sollten, und sie fassen das Seminar zusammen. Anforderungen und Testorakel verantworten Menschen.

7:34 KI-Ausgaben gelten zunächst als Vorschlag, nicht als Ergebnis. Autorisierung wird im Server erzwungen, nicht im Prompt formuliert. Und Merge, Deployment, Datenlöschung und externe Kommunikation bleiben freigabepflichtig. Vier Sätze, die man auswendig können sollte — und die man notfalls auf eine Seite drucken kann. Der erste Punkt ist der Unterschied zwischen einer Policy und einem Leitbild: Sie formuliert Absichten statt überprüfbarer Regeln.

8:02 Der zweite ist das häufigste Schicksal solcher Dokumente: Sie entsteht im Seminar und wird im Team nie verabschiedet. Der dritte ist der Grund, warum Policies umgangen werden: Sie verbietet vieles und benennt keinen gangbaren Weg. Und der vierte ist die Frage, die am Ende jedes Seminars offenbleibt, wenn man sie nicht ausdrücklich stellt: Was ist der nächste Schritt im eigenen Bestand?

Übung

8:24 Jetzt sind Sie dran — mit allem auf einmal. Die Teams durchlaufen den vollständigen Workflow an der Fristen-Eskalation und bewerten anschließend gegenseitig ihre Lösungen anhand desselben Rasters aus sieben Kriterien. Das gegenseitige Review ist dabei nicht die Kür, sondern der Teil, aus dem man am meisten mitnimmt: Eine fremde Lösung zu beurteilen schärft den Blick für die eigene.

8:46 Das Übergabepaket enthält neun Bestandteile: Spezifikation, freigegebenen Plan, lauffähigen Server, getestete Änderung, Test- und Analyseergebnisse, Threat Model, Review-Protokoll, Architekturentscheidung und Team-Policy. Das klingt nach viel und ist es nicht — acht davon sind in den vergangenen drei Tagen bereits entstanden.

9:06 Und der Hinweis gilt weiterhin: keine produktive Bereitstellung, kein automatisches Merge, keine irreversible Änderung. Nehmen Sie die Lösung eines anderen Teams und gehen Sie die sieben Kriterien durch. Benennen Sie den schwächsten Nachweis — nicht den schwächsten Teil der Lösung, sondern den schwächsten Nachweis. Das ist ein Unterschied, auf den es ankommt.

9:28 Und hinterlassen Sie einen konkreten Verbesserungsvorschlag. Der Hinweis ist ernst gemeint: Wer nur lobt, hat das Raster nicht benutzt. Der erste Punkt ist der, der am häufigsten auffällt: Das Paket ist vollständig, aber die Nachweise sind nicht prüfbar. Der zweite ist die Abkürzung, die den Transfer verhindert — die Team-Policy wird kopiert statt auf den eigenen Bestand bezogen.

9:50 Der dritte ist der Rückfall in die Gewohnheit: Im Review wird der Code diskutiert und nicht der Nachweis. Und der vierte ist der, den ich Ihnen zum Abschluss mitgeben möchte: Der nächste Schritt für den eigenen Bestand bleibt offen. Beantworten Sie diese Frage, bevor Sie hier hinausgehen — sie entscheidet darüber, was von drei Tagen übrig bleibt.