Prüfbare Vorgaben für KI-Agenten

Akzeptanzkriterien wurden für Menschen erfunden. Eine Produktmanagerin schrieb sie, ein Entwickler interpretierte sie, eine Testerin prüfte das Ergebnis – und den Spielraum zwischen vager Formulierung und richtigem Verhalten haben Menschen absorbiert, die Rückfragen stellen konnten. Ein KI-Agent absorbiert keinen Spielraum: er baut ihn – wörtlich, selbstbewusst und ohne die Reibung einer Nachfrage.

Das zweite Problem ist die Haltbarkeit. Der Prompt, der die Absicht trug, ist zur Review-Zeit verschwunden – weshalb Reviewer von KI-Änderungen die Anforderungen aus dem Diff rekonstruieren. Die Forschung zu Delegation Contracts für Coding-Agenten fasst Nachprüfbarkeit in genau vier Fragen: Was war beauftragt, was durfte der Agent, was kam zurück, welche Belege stützen es. Die Vorgabe ist das Artefakt, das die ersten beiden Fragen vor dem Run beantwortet – und danach den Soll-Ist-Abgleich füttert.

1. Ziel – ein Satz. Was nach dem Run wahr sein muss, das vorher nicht wahr war. Braucht das Ziel drei Sätze, sind es vermutlich zwei Aufgaben.
2. Grenzen – der Berechtigungsrahmen. Welche Dateien sich ändern dürfen, welche nicht, welches Verhalten tabu ist. Grenzen machen aus Scope Creep eine Feststellung statt einer Diskussion.
3. Akzeptanzkriterien – 3 bis 7 Ja/Nein-Fragen. Jede ohne Diskussion entscheidbar. Diesen Teil geht die Verifikation später Zeile für Zeile durch.
4. Validierungsplan – welche Checks zählen. Tests (idealerweise vor dem Run geschrieben), Typen, Lint, Build und jeder manuelle Check, der sich nicht automatisieren lässt – vorab benannt, damit „hat bestanden“ eine definierte Bedeutung hat.

Einen gesprächigen Prompt in diese Form zu kompilieren dauert Minuten und sieht so aus:

PROMPT (was man natürlich tippen würde)
"Die Rate-Limiting-Antworten verwirren die Clients, kannst du die
429er hilfreicher machen?"

KOMPILIERTE VORGABE (wogegen der Run verifiziert wird)
Ziel:      429-Antworten tragen einen korrekten Retry-After-Header
Grenzen:   nur api/middleware/* · Rate-Limit-Schwellen unverändert
Kriterien: [1] Retry-After bei jeder 429-Antwort vorhanden
           [2] Wert = Rest des Fensters in Sekunden (±1 s)
           [3] leere/fehlerhafte Client-IDs bekommen 429, nicht 500
           [4] 2xx- und übrige 4xx-Pfade byte-identisch zu vorher
Validierung: Unit-Tests (vorab geschrieben) · Typen · Lint · Build
             manuell: Header hinter dem CDN sichtbar (Staging)

• Adjektive durch Zahlen ersetzen. „Schnell“ wird zu „p95 unter 200 ms“; „hilfreiche Fehlermeldung“ wird zu „Meldung nennt Feld und Limit“. Ein Adjektiv ist eine Einladung an das Modell, selbst zu entscheiden, was gemeint war.
• Unglückspfade benennen. Leere Eingaben, Duplikate, fehlende Berechtigungen, Timeouts. Bleiben sie ungenannt, erfindet der Agent seine eigene Policy – und seine selbstgeschriebenen Tests bestätigen genau diese Erfindung.
• Kriterien an Verhalten binden, nicht an Implementierung. „Nutzt einen Token Bucket“ altert schlecht und verbietet bessere Lösungen; „erlaubt 100 Requests pro Minute pro Client“ ist die eigentliche Anforderung.
• Das leichteste Format wählen, das entscheidbar bleibt. Given-When-Then bildet direkt auf Tests ab und passt zu verhaltenslastiger Arbeit; eine schlichte Checkliste ist schneller und genauso prüfbar. Format ist Geschmack – Entscheidbarkeit ist die Anforderung.

• Kleine Aufgaben überspezifizieren. Die Form skaliert auf drei Zeilen herunter. Eine Vorgabe, die länger ist als ihr Diff, ist ein Warnsignal – Aufgabe teilen oder Vorgabe kürzen.
• Spezifizieren ohne Abgleichen. Eine Vorgabe, gegen die niemand prüft, ist Dokumentations-Theater. Der Abgleich danach ist der Grund, sie zu schreiben.
• Vollständigkeit erwarten. Die Vorgabe verifiziert, woran gedacht wurde. Absicht vollständig zu formalisieren bleibt ein offenes Forschungsproblem – die Methode verkleinert die Lücke, sie schließt sie nicht.
• Das Modell seine eigenen Kriterien schreiben lassen – ungelesen. Mit KI entwerfen ist fein; den Entwurf ungeprüft übernehmen stellt genau die Zirkularität wieder her, die die Vorgabe brechen soll.

Bei Reality Graph ist diese Kompilierung die Eingangstür jedes Runs: Aufträge entstehen mit Ziel, Grenzen, Kriterien und Validierungsplan, der Run wird danach im Verifikations-Loop dagegen geprüft, und das Ergebnis landet in einem Prüfbericht. Die Methode funktioniert auch mit einer Textdatei – das Tool nimmt die Disziplin-Steuer heraus.