Der Spickzettel zum Seminar MCP & Agentic Software Engineering, zweiter Teil: was man festlegt, bevor ein Agent arbeitet, und woran man prüft, was er abgeliefert hat. Protokoll, Server und Autorisierung stehen auf dem ersten Blatt, MCP-Server und Protokoll. Das Blatt hält Entscheidungsraster fest — die Methode bringt es nicht bei.
Wer entscheidet, wer führt aus
| Ausprägung | Mensch tut | Werkzeug tut |
|---|---|---|
| Chat-Assistent | fragt, überträgt selbst | antwortet |
| Inline-Vorschlag | nimmt an oder verwirft | schlägt vor |
| IDE-Agent | bestätigt je Schritt | liest, schreibt, testet |
| Asynchroner Agent | beauftragt, prüft am Ende | arbeitet den Auftrag ab |
Von oben nach unten wächst der Nutzen und im gleichen Maß der Prüfaufwand. Die Ausprägung wird nach der nötigen Kontrolle gewählt, nicht nach dem Produktnamen.
Modul: Vom Coding-Assistenten zum handelnden Entwicklungsagenten
Eignet sich der Auftrag zur Delegation
| Auftrag | Eignung | Ausschlag |
|---|---|---|
| Validierungsregel ergänzen | hoch | Tests vorhanden, umkehrbar |
| Fachlichen Schnitt neu ziehen | gering | kein Testorakel |
| Abhängigkeiten aktualisieren | mittel | prüfbar, aber breite Wirkung |
Drei Fragen entscheiden: Prüfbarkeit (gibt es ein Testorakel?), Umkehrbarkeit (lässt sich der Schritt zurücknehmen?), Wirkungsbreite. Wer bei „wie prüfe ich das?” ins Stocken gerät, hat die Antwort schon gefunden. Generierter Code ist schnell erzeugt und langsam verantwortet — ohne Test bleibt nur das Lesen des Diffs, und das skaliert nicht.
Modul: Vom Coding-Assistenten zum handelnden Entwicklungsagenten
Projektanweisungen: was hineingehört
| Gehört hinein | Gehört woanders hin |
|---|---|
| Wie ein Modul aufgebaut wird | Warum diese Architektur gewählt wurde |
| Welche Tests Pflicht sind | Die Testfälle selbst |
| Wie Fehler behandelt werden | Die Fehlerklassen im Code |
| Was ausdrücklich verboten ist | Die Historie des Verbots |
Begründungen gehören in Architekturentscheidungen; die Anweisung verlinkt sie nur. Widersprüche kosten mehr als Lücken: Eine veraltete Regel wird so ernst genommen wie eine gültige, und der Agent meldet den Widerspruch nicht — er wählt einfach. Regeln ohne Prüfung in der Pipeline verfallen unbemerkt.
Modul: Kontext und Arbeitsregeln für Coding Agents
Startklar und fertig
| Startklar, wenn | Fertig, wenn |
|---|---|
| Ziel und zwei Nicht-Ziele stehen | Akzeptanzkriterien durch Tests belegt |
| Akzeptanzkriterien prüfbar sind | Diff gelesen und gegengezeichnet |
| Der Werkzeugsatz benannt ist | Statische Analyse ohne neue Funde |
| Die Freigabestelle benannt ist | Änderungsprotokoll vollständig |
Beide Listen gelten unabhängig davon, ob ein Mensch oder ein Agent die Änderung geschrieben hat. Die Freigabe bindet sich an die konkrete Aktion — mit Akteur, Werkzeug, Ziel, Parametern und Gültigkeitsdauer; eine pauschale Zustimmung erfüllt das nicht.
Modul: Kontext und Arbeitsregeln für Coding Agents
Vom Ticket zur Spezifikation
| Im Ticket steht | In der Spezifikation steht |
|---|---|
| Kostenstelle soll Pflicht werden | Anfragen ohne Kostenstelle werden abgelehnt |
| Bitte im Formular prüfen | Prüfung serverseitig, Formular zeigt sie an |
| — | Nicht-Ziel: Altbestand bleibt unberührt |
| — | Nicht-Ziel: keine Änderung am Nachbarsystem |
Die beiden unteren Zeilen verhindern mehr Arbeit als die beiden oberen erzeugen: Ein Agent erweitert den Auftrag, wenn die Grenze fehlt, und ohne Grenze ist auch nicht entscheidbar, wann etwas fertig ist.
Akzeptanzkriterien beschreiben beobachtbares Verhalten, nicht Formularfelder — und die Ablehnungsfälle gehören dazu:
| Fall | Erwartetes Verhalten |
|---|---|
| Gültige Kostenstelle | Anfrage wird angenommen |
| Fehlende Kostenstelle | Ablehnung mit Feldhinweis |
| Unbekannte Kostenstelle | Ablehnung, Zielsystem hat nicht bestätigt |
| Bestandsanfrage ohne | bleibt unverändert bestehen |
| Zielsystem nicht erreichbar | Ablehnung, keine stille Annahme |
Die letzten beiden Zeilen stehen im Ticket nie und fallen im Betrieb immer auf. Die Spezifikation liegt im Repository, nicht im Ticketsystem — sonst ist sie für den Agenten unerreichbar.
Modul: Vom Ticket zur ausführbaren Spezifikation
Plan, Impact-Analyse und Abbruch
| Frage | Quelle |
|---|---|
| Wo wird heute validiert? | Suchwerkzeug, Code |
| Wer ruft das auf? | Werkzeug zur Komponentenermittlung |
| Welche Tests decken das ab? | Testverzeichnis, Konventionen |
| Was hat der Fachbereich entschieden? | Architekturhandbuch als Resource |
Alle vier Antworten gehören in den Plan, nicht erst in den Pull Request. Bestandstests zuerst sichten: Sie zeigen, welches Verhalten als zugesichert gilt; bei Bestandscode ohne Tests helfen Characterization Tests.
| Signal | Konsequenz |
|---|---|
| Dritte Korrekturschleife am selben Test | Abbruch, Neuplanung |
| Fachliche Frage ohne Antwort im Kontext | Eskalation an den Fachbereich |
| Sicherheitsrelevante Stelle berührt | Eskalation, unabhängiges Review |
Wiederholtes Nachbessern am selben Punkt ist fast immer ein Planungsfehler, kein Codefehler. Jede weitere Runde vergrößert den Diff, nicht den Erkenntnisgewinn; ein Abbruch mit klarem Befund ist ein brauchbares Ergebnis.
Modul: Planen, schneiden und kontrolliert implementieren
Was welcher Test belegt
| Testart | Belegt | Blinder Fleck |
|---|---|---|
| Unit | Regel greift bei fehlendem Feld | Aufruf im echten Ablauf |
| Integration | Formular und Server passen zusammen | Verhalten des Fremdsystems |
| Contract | Zusage an das Fremdsystem gilt | Fachliche Richtigkeit |
| Regression | Altbestand bleibt unberührt | Neue Fälle |
Der Erfolgsfall gelingt fast immer, auch mit falscher Logik — erst der Negativtest trennt Können von Glück. Die Regressionszeile deckt genau das Nicht-Ziel aus der Spezifikation ab.
Modul: Qualität nicht an den Agenten delegieren
Diff-Review: vier Stellen zuerst
| Stelle | Frage |
|---|---|
| Bestehende Tests | Wurde eine Erwartung abgeschwächt? |
| Konfiguration | Wurde eine Schranke stillschweigend gesetzt? |
| Fehlerbehandlung | Wird ein Fehler jetzt verschluckt? |
| Nicht-Ziele | Wurde etwas berührt, was unberührt bleiben sollte? |
Alle vier sind im Diff sichtbar und in der Zusammenfassung des Agenten üblicherweise nicht. Gelesen wird gegen vier Maßstäbe: die Spezifikation (ist jedes Kriterium abgedeckt), den Plan (wurde abgewichen, und warum), die Nicht-Ziele und den umgebenden Bestand.
Modul: Qualität nicht an den Agenten delegieren
Reproduzierbarkeit und Kennzahlen
| Angabe | Wofür sie gebraucht wird |
|---|---|
| Auftrag und Spezifikationsstand | Vergleichbarkeit zweier Läufe |
| Werkzeugsatz und Version | Erklärung unterschiedlicher Wege |
| Folge der Aufrufe mit Ergebnis | Fehlersuche und Review |
| Modell und Konfiguration | Einordnung von Streuung |
Ohne die zweite Zeile ist jeder Vergleich wertlos — ein Werkzeug mehr ändert alles. Reproduzierbarkeit ist dabei nicht Determinismus.
| Kennzahl | Was ein schlechter Wert bedeutet |
|---|---|
| Erfolgsquote je Auftragsart | Diese Art eignet sich nicht zur Delegation |
| Korrekturschleifen bis Abnahme | Spezifikation oder Kontext sind unscharf |
| Kosten je abgeschlossenem Auftrag | Der Zuschnitt ist zu groß |
| Laufzeit bis zur Abnahme | Der Prüfengpass liegt beim Menschen |
Je Auftragsart auswerten — der Durchschnitt verdeckt genau das Interessante. Zeilen, Token und Testabdeckung sagen wenig: Sie messen Aufwand statt Nutzen und lassen sich vom Agenten leicht optimieren.
Modul: Quality Gates, Reproduzierbarkeit und Kennzahlen
Bedrohungsmodell
| Station | Angriffspunkt | Folge |
|---|---|---|
| Host | Zustimmung im Stapel | Wirkung ohne Prüfung |
| Client | fehlende Isolation | Server sieht fremden Kontext |
| Server | ungeprüfte Eingabe | Injektion ins Zielsystem |
| Zielsystem | zu weite Rechte | Zugriff über den Auftrag hinaus |
Dieselben Verantwortungsgrenzen wie im Architekturbild, nur von der anderen Seite gelesen. Lokale Server sind das unterschätzte Risiko: Sie laufen mit den Rechten des Clients, ein Startbefehl in einer Konfiguration führt beliebigen Code aus, und über DNS-Rebinding erreicht sie im schlechten Fall eine Webseite.
| Kennung | Risiko (OWASP, agentische Anwendungen) |
|---|---|
| ASI01 | Agent Goal Hijack |
| ASI02 | Tool Misuse und Exploitation |
| ASI03 | Agent Identity und Privilege Abuse |
| ASI06 | Memory und Context Poisoning |
| ASI08 | Cascading Agent Failures |
Die Liste hat zehn Einträge; diese fünf treffen einen Entwicklungsworkflow am unmittelbarsten. Ketten sind gefährlicher als Einzelaufrufe: Jedes Werkzeug für sich ist geprüft, die Verkettung erzeugt eine Wirkung, die keines allein hat.
Modul: Bedrohungsmodell für MCP und Agenten
Freigaben, die etwas wert sind
Eine Bestätigung zeigt Werkzeug und Argumente, gilt für eine Aktion und wird im Server erzwungen, nicht im Prompt erbeten. Der Eskalationsweg steht vorher fest: Im Vorfall zählt, wer abschalten darf, nicht wer zuständig wäre — ein Kill Switch ohne benannte Person ist ein Knopf ohne Hand. Zur selben Festlegung gehören die Wiederanlaufbedingungen.
Freigabepflichtig bleiben in jedem Fall: Merge, Deployment, Datenlöschung und externe Kommunikation. KI-Ausgaben gelten zunächst als Vorschlag, nicht als Ergebnis; Anforderungen und Testorakel verantworten Menschen.
Module: Least Privilege, Isolation und Freigaben · Capstone: Ein kontrollierter agentischer Entwicklungsworkflow
Nachweise am Ende eines Laufs
| Kriterium | Nachweis im Paket |
|---|---|
| Problemverständnis | Ziele, Nicht-Ziele, offene Fragen |
| Schnittstellendesign | Tool-Katalog mit Schemas |
| Kontrollierbarkeit | Plan, Schritte, Freigaben |
| Sicherheit | Threat Model, Berechtigungen |
| Qualität | Tests und Gate-Ergebnisse |
| Nachvollziehbarkeit | Aufruffolge, Diff, Review |
| Transfer | Team-Policy |
Bewertet wird nicht Menge oder Geschwindigkeit des generierten Codes, sondern diese sieben Punkte. Die Freigabe mit Zeitpunkt und Person ist das, was im Zweifel nachweist, dass jemand entschieden hat.
Modul: Capstone: Ein kontrollierter agentischer Entwicklungsworkflow
Typische Fallen
- Grüne Pipeline gilt als Nachweis fachlicher Richtigkeit. Sie belegt, dass nichts Bekanntes brach — nicht, dass das Neue stimmt.
- Der Agent schreibt Implementierung und Test in einem Zug. Dann prüft der Test, was der Code tut, statt was er tun soll.
- Der Reviewer ist derselbe, der den Auftrag formuliert hat — und das Review hinterlässt keine Spur.
- Der Agent darf die Pipelinekonfiguration ändern oder Regeln unterdrücken, um grün zu werden. Schranken laufen vor dem Merge, nicht danach.
- Bestätigungen häufen sich, bis sie reflexhaft weggeklickt werden. Eine Zustimmung im Stapel ist keine Prüfung.
- Der Freitext einer Anfrage gilt als vertrauenswürdiger Kontext. Anweisungen und Daten gehören im Prompt getrennt.
- Die Gegenmaßnahme ist eine Anweisung im Prompt statt einer Prüfung im Server — Berechtigungen lassen sich nicht formulieren, nur erzwingen.
- Alle Werkzeuge nutzen denselben Generalschlüssel, und das Zielsystem sieht nur eine Dienstidentität.
- Der Lauf hat kein Abbruchkriterium und endet erst am Budget.
- Die Team-Policy formuliert Absichten statt überprüfbarer Regeln — und wird im Team nie verabschiedet.