„Wenn man einem KI-Agenten einen Weg gibt, seine Arbeit unabhängig zu überprüfen, kann das die Qualität der Ergebnisse deutlich verbessern.“ So beginnt ein Beitrag von Addy Osmani über das, was er agentische Verifikation nennt, und der Satz lenkt den Blick auf eine unscheinbare Stelle im Werkzeugkasten. Denn er handelt nicht von Modellen, sondern von Rückkopplung. Wer heute mit KI-Agenten Software baut, kennt den Effekt: Der Anfang sieht beeindruckend aus, doch je länger der erzeugte Code wird, desto weniger weiß jemand noch sicher, ob das Ganze wirklich tut, was es soll. Genau dort setzt der Gedanke an.
Man kann sich das wie einen Prüfstand in der Fertigung vorstellen. Solange ein Bauteil nur nach Augenmaß entsteht, fällt eine Abweichung erst auf, wenn das Teil schon eingebaut ist und der Kunde sich meldet. Ein Prüfstand dreht die Reihenfolge um: Erst messen, dann ausliefern. Ein KI-Agent ohne Prüfmöglichkeit arbeitet nach Augenmaß, und zwar in einem Tempo, bei dem niemand hinterherkommt. Die Instrumente, die er braucht, sind nicht exotisch. Es sind Tests, Vergleiche, Spezifikationen und echte Durchläufe am laufenden System. Osmani nennt dieses Bündel den Feedback-Loop und hält ihn für den wichtigsten Hebel.
Warum nicht das Schreiben von Code der Engpass ist
Osmani beschreibt die Lage so: Die heutigen Modelle sind gut genug, dass die eigentliche Bremse nicht mehr das Schreiben von Code ist, sondern die Fähigkeit zu prüfen, ob der geschriebene Code korrekt ist. Kann ein Agent seine Ausgabe nicht verifizieren, rät er im Grunde, und eine falsche Vermutung wird anschließend von der Testsuite bestätigt. Das klingt paradox, ist aber der Normalfall: Ein selbst erfundener Test, der auf derselben Fehlannahme beruht wie der Code, bestätigt beide. Deshalb hält Osmani fest, dass er einen deutlich besseren Feedback-Loop jederzeit einem etwas besseren Modell vorziehen würde.
Ohne eigenes Prüfwerkzeug entsteht ein Loop, in dem ein Mensch hin und her läuft: Diffs lesen, Tests starten, die Anwendung öffnen, Fehler finden, zurückmelden. Das ist laut Osmani der langsamste und teuerste Loop überhaupt, und er skaliert nicht über eine einzige Person hinaus. Sobald der Agent selbst testen kann, sieht die Schleife anders aus. Er schreibt eine Änderung, führt die Prüfung aus, liest die Ausgabe und wiederholt den Vorgang, bis die Prüfung besteht. All das passiert, bevor ein Mensch überhaupt etwas zu Gesicht bekommt. Zwischen einem selbstverifizierenden Agenten und einem Loop, den Menschen dominieren, liegt laut Osmani ein großer Unterschied.
Der Feedback-Loop als Qualitätsquelle
Aus dieser Verschiebung folgt eine andere Arbeitsteilung. Die Arbeit besteht weniger darin, jede Zeile zu reviewen, und mehr darin, Schleifen zu bauen, die der Agent selbst laufen lassen kann. Osmani beschreibt das als Übergang vom Zeilenprüfer zum Schleifenkonstrukteur. Der Mensch verantwortet weiterhin, was ausgeliefert wird, prüft aber Belege statt nur Diffs. Ein fehlgeschlagener Test mit Screenshot, Trace und einer klaren Aussage, welcher Schritt gebrochen ist, ist mehr wert als eine Handvoll geänderter Dateien, die plausibel aussehen.
Dazu kommt ein zweiter Gedanke, den Osmani als „Geschmack, der sich aufsummiert“ beschreibt. Wenn der Agent etwas falsch macht, wird es festgehalten: in einer gemeinsamen Konfiguration, einem Hook, einem Test. Beim nächsten Mal kann derselbe Fehler nicht mehr unbemerkt passieren. Über Wochen entsteht so eine Sammlung von Regeln, die nicht aus einem Styleguide stammt, sondern aus echten Fehlern. Bessere Code-Qualität wird damit zur Regel statt zum Zufall. Die Verantwortung bleibt beim Menschen, nur die Beweislast verschiebt sich zum Agenten.
End-to-End-Tests als Ground Truth für KI-Agenten
Osmani formuliert eine neue Definition von Tests. Jahrelang waren Tests das Werkzeug, mit dem Menschen Fehler finden und refaktorieren konnten. Diese Gründe gelten weiter, aber Tests sind zusätzlich die Art und Weise, wie ein Agent die Welt wahrnimmt und erkennt, wann er fertig ist. Nicht jeder Test ist dafür gleich wertvoll. Müsste man sich für einen einzigen Typ entscheiden, wäre es der End-to-End-Test, weil er beschreibt, was ein echter Nutzer tut: registrieren, etwas in den Warenkorb legen, bezahlen, eine Bestätigung sehen.
Der entscheidende Vorteil liegt darin, dass ein End-to-End-Test die interne Struktur ignoriert und nur sieht, was der Nutzer sehen kann. Er ist damit ein Orakel, das sich schwer täuschen lässt. Ein mock-basierter Unit-Test kann grün sein, während das Feature kaputt ist, weil Agent und Test dieselbe Fehlannahme teilen. Beim End-to-End-Test gilt entweder das Ganze funktioniert oder es funktioniert nicht. Als Ground Truth für automatisierte Tests von KI-Agenten ist das ein großer Unterschied, weil der Agent nicht über eine selbstgebaute Fiktion stolpert, sondern über die Realität.
Osmani nennt mehrere Gründe, warum sich End-to-End-Tests für Agenten besonders eignen. Sie decken nur wichtige Nutzerflüsse ab statt aller denkbaren Pfade. Sie sagen, was falsch ist, weil Screenshots, Traces und der fehlgeschlagene Schritt dem Agenten eine Spur legen, während eine Meldung wie „Timeout nach 30 Sekunden“ nichts erklärt. Sie laufen sowohl in der lokalen Umgebung des Agenten als auch in der Deployment-Umgebung. Und sie definieren „fertig“: „Implementiere dieses Feature“ ist zu vage, „Bring diesen End-to-End-Test zum Laufen“ ist ein Ziel, das der Agent allein verfolgen kann.
Osmani verschweigt die Nachteile nicht: End-to-End-Tests sind langsamer und anfälliger als Unit-Tests. Die Antwort darauf ist nicht, sie abzuschaffen, sondern sich auf einen kleinen Satz besonders wertvoller Tests zu konzentrieren. Ergänzend verweist er auf Lauren, die betont, dass der Agent Augen und Hände am wirklich laufenden System braucht: ein gepflegtes Werkzeug oder CLI, das die Anwendung startet, steuert und beobachtet, plus eine Feature-Map. Diese Map ist eine Bestandsaufnahme aus Nutzersicht, mit Wegen, Tastenkürzeln, Selektoren, erwarteten Ergebnissen und bekannten Fallstricken.
Property-based Testing für KI-Agenten: Regeln, die nie brechen dürfen
Viele Tests halten fest, was ein Mensch für möglich hält. Property-basierte Tests handeln von dem, woran ein Mensch nicht gedacht hat, und genau dort gehen Agenten schief. Beispieltests sagen, was passieren soll; Properties sagen, was niemals passieren darf. Ein Mensch kann nicht alle Eingaben erfinden, die einen Fehler auslösen. Eine Property dreht die Richtung um: Man formuliert eine Regel, die gelten muss, und ein Werkzeug erzeugt Hunderte oder Tausende Eingaben, um sie zu brechen.
Für JavaScript und TypeScript ist fast-check verbreitet, für Python Hypothesis, für Rust proptest. Findet das Werkzeug einen Verstoß, schrumpft es die Eingabe auf den kleinsten Fall, der die Regel bricht. Man bekommt also keinen zufälligen Datenhaufen, sondern ein minimales Gegenbeispiel. Osmani nennt einige Properties, die in fast jedem Projekt auftauchen: Hin- und Rückkodierung muss denselben Wert ergeben, Invarianten dürfen sich nicht verändern, etwa die Anzahl der Elemente beim Sortieren oder ein Kontostand, der nicht negativ werden darf. Dazu kommen Idempotenz, bei der ein zweiter Durchlauf dasselbe bewirkt wie der erste, und Äquivalenz, bei der eine optimierte Funktion dasselbe liefert wie die einfache, korrekte Version.
Für Agenten ist das deshalb wichtig, weil ein Agent sich seine Testbeispiele selbst ausdenkt und dabei nach seiner eigenen Logik erfolgreich ist. Eine Property zwingt ihn, mit jeder erzeugten Eingabe umzugehen, nicht nur mit den selbst gewählten. Osmani erwähnt ergänzend Boris Cherny von Claude Code, der für die haarigsten Zustandsmaschinen, Nebenläufigkeiten und Datenflüsse formale Modelle wie Lean und TLA+ einsetzt. Kurze Prompts können dort Race Conditions aufdecken, Gegenbeispiele finden, reproduzieren und beheben. Wer einsteigen will, beginnt mit einer kleinen, möglichst reinen Funktion, schreibt die Property erst in klarer Sprache und dann in Code, speichert jedes minimierte Gegenbeispiel als Regressionstest und bittet den Agenten bei neuem Code um Properties statt um Beispiele.
Differentialtesting bei Migrationen: das alte System als Orakel
Beim Ersetzen eines Systems schlägt Osmani vor, das alte als Orakel zu behandeln und die Ausgaben beider Versionen zu vergleichen. Ein klassischer Fehler bei einem Rewrite ist, dass die neue Version die neue Testsuite besteht und trotzdem in vielen kleinen, undokumentierten Details vom Alten abweicht. Das ist der Unterschied zwischen offizieller Spezifikation und tatsächlichem Verhalten, und Nutzer verlassen sich auf Letzteres. Differentialtesting überbrückt diese Lücke, indem beide Systeme mit denselben Eingaben nebeneinander laufen. Weicht die Ausgabe ab, ist entweder ein Fehler eingebaut oder eine bewusste Änderung, die als Breaking Change dokumentiert gehört.
Entscheidend ist die Wahl der Eingaben. Handverlesene Testfälle übersehen seltene Randfälle, deshalb werden Eingaben zufällig erzeugt, ein Ausschnitt echten Live-Verkehrs abgespielt oder beides kombiniert. Der Effekt entspricht Property-based Testing mit der Regel, dass die Ausgaben übereinstimmen müssen. Osmani beschreibt den Ablauf als Schleife: neue Version anpassen, Differentialtest laufen lassen, Abweichungen prüfen, korrigieren, von vorn. Weil das alte System das Orakel ist, muss niemand dem Agenten jeden Sonderfall erklären.
Zwei Details entscheiden über den Erfolg. Erstens sollte alles normalisiert werden, was keine Bedeutung trägt, etwa eine Reihenfolge ohne semantisches Gewicht, sonst entsteht ein endloser Strom falscher Abweichungen. Zweitens gehören beabsichtigte Änderungen in eine Liste genehmigter Abweichungen, jede mit Begründung, damit „anders“ nicht zu einem akzeptablen Zustand wird. Teams, die diesen Weg gegangen sind, berichten laut Osmani von einem Wechsel: Statt einen Bruch zu flicken und den nächsten zu erzeugen, arbeitet man sich methodisch durch den Vergleich. Das Ziel ist die Sicherheit, das alte System abschalten zu können. Beide parallel zu betreiben kostet doppelt so viel Verständnis und eröffnet zwei Wege, auf denen die Migration scheitern kann.
Warum Tests schnell und deterministisch sein müssen
Tests müssen schnell und verlässlich sein, sonst lernt der Agent die falsche Lektion. Das ist keine reine Zeitfrage, sondern eine Trainingsfrage. Sind Tests langsam oder instabil, merkt sich der Agent, dass ein Neustart des Tests manchmal schneller zum Erfolg führt als eine echte Korrektur. Menschen sind gegenüber schlechter Testinfrastruktur deutlich nachsichtiger. Wir wissen, welche Tests gelegentlich flackern, wir starten die Pipeline im Zweifel neu, und wir warten auch zwanzig Minuten auf einen Build. Der Agent kennt diese Nachsicht nicht, er liest nur die Anreize der Schleife.
Lässt sich ein fehlschlagender Test gelegentlich durch bloßes Wiederholen zum Laufen bringen, wird der Agent das Wiederholen zu seiner bevorzugten Strategie machen. Dauert der Testlauf fünfzehn Minuten, wird er ihn seltener starten, mehr Änderungen zwischen zwei Läufen bündeln und damit die Fähigkeit verlieren, den einen auslösenden Change zu identifizieren. Beide Fehlmuster verschlechtern das Ergebnis, ohne dass irgendwo ein sichtbares Warnsignal auftaucht. Am Ende bekommt der Mensch weniger gute Arbeit zum Review, ohne zu wissen, warum.
Was hier hilft, ist wenig spektakulär: Laufzeiten im Sekundenbereich, deterministische Tests ohne Zufallsabhängigkeiten, klare Fehlermeldungen, die den gebrochenen Schritt benennen, und ein Prüfwerkzeug, das der Agent lokal genauso starten kann wie die Pipeline. Automatisierte Tests für KI-Agenten sind damit kein Anhängsel der Entwicklung, sondern ihre Sensorik. Wer diese Sensorik nicht pflegt, bekommt einen Agenten, der blind fliegt und trotzdem schnell fliegt.
Was agentische Verifikation konkret bedeutet
Die praktische Konsequenz ist unspektakulär und dennoch eine Umstellung. Wer KI-Agenten selbst verifizieren lassen will, investiert weniger in den nächsten Modellwechsel und mehr in die Schleife: eine Handvoll End-to-End-Tests für die wirklich wichtigen Nutzerflüsse, Properties für die Regeln, die nie brechen dürfen, ein Differentialvergleich bei jeder Migration und eine Testsuite, die in Sekunden antwortet. Alles davon lässt sich von einem Agenten erzeugen und pflegen, sobald man ihn darum bittet. Der Engpass ist selten das Werkzeug, sondern die Bereitschaft, dem Agenten das Prüfen zuzutrauen und ihm die nötigen Instrumente zu geben.
Das ändert auch die Rolle des Menschen. Man prüft nicht mehr jede Zeile, sondern entscheidet, was ausgeliefert wird, und liest dabei Belege statt Diffs. Man sammelt Fehler in Konfigurationen, Hooks und Tests, damit sie sich nicht wiederholen. Und man akzeptiert, dass Qualität nicht in einem einzelnen Durchlauf entsteht, sondern in einer Schleife, die der Agent selbst drehen kann. Osmanis Kernsatz lautet „Write the check before the code“: Bevor der Agent etwas baut, muss der Mensch festlegen, woran Erfolg gemessen wird – ein End-to-End-Ablauf, eine Property oder der Vergleich mit dem Altsystem. Und die vom Agenten erzeugten Tests gehören selbst geprüft, am besten von einem separaten Prüf-Agenten, denn ein Test, der dieselbe Fehlannahme teilt, segnet den Fehler nur ab. Dahinter steckt eine einfache Beobachtung: Nicht das Modell schreibt besseren Code, sondern das Prüfwerkzeug ringsum macht den Code besser, den das Modell schreibt.
Quelle: addyo.substack.com
