Addy Osmani geht von einer Beobachtung aus: Gibt man einem Agenten die Möglichkeit, seine eigene Arbeit zu verifizieren, verbessert sich die Qualität des Ergebnisses deutlich. Was „guten Code“ bisher teuer machte – Tests, Benchmarks, Spezifikationen, echte End-to-End-Pfade – lässt sich nun an den Agenten delegieren. Die menschliche Arbeit verschiebt sich daher von der zeilenweisen Durchsicht zum Aufbau von Loops, die der Agent eigenständig durchläuft, und Geschmack wird kapitalisiert: Jeder Fehler wird zu einer gemeinsamen Konfiguration, einem Hook oder einem Test. Ein Mensch bleibt verantwortlich für das, was ausgeliefert wird, prüft dabei aber Belege statt Diffs.
Seiner Ansicht nach sind die Modelle inzwischen gut genug, dass die Verifizierung zum Engpass wird. Ein Agent, der sich nicht selbst prüfen kann, rät, und die Korrektur erfordert dann einen langsamen, teuren, nicht skalierbaren menschlichen Rückkanal. Ein Agent, der sich selbst testet, schreibt, prüft, liest das Ergebnis und versucht es erneut, bevor ein Mensch überhaupt eingreift. Tests ändern ihre Rolle: Sie werden zu dem Mittel, mit dem der Agent die Welt wahrnimmt und erkennt, dass er fertig ist.
End-to-End-Tests sind das Orakel der Wahl: Sie beschreiben, was der Nutzer tut, und lassen sich schwer täuschen – anders als ein mock-basierter Unit-Test, der das Missverständnis des Agenten selbst teilen kann. Sie müssen auf den fehlgeschlagenen Schritt verweisen und machen so aus einer vagen Anweisung ein Ziel. Da sie langsam und flaky sind, sollten sie in geringer Zahl bleiben.
Property-based Tests legen fest, was niemals passieren darf; Tools wie fast-check, Hypothesis oder proptest erzeugen Tausende von Eingaben und reduzieren Fehlschläge („shrinking“) auf einen minimalen Fall. Gängige Eigenschaften: Round-Trips, Invarianten, Idempotenz, Äquivalenz mit einer einfachen Version. Sie verhindern, dass der Agent Beispiele auswählt, die lediglich seine eigene Logik bestätigen, und dienen als Spezifikation.
Bei einem Rewrite machen Differentialtests das alte System zum Orakel: identische Eingaben, zufällig oder aus echtem Traffic gewonnen, Vergleich der Ausgaben, Normalisierung unwesentlicher Unterschiede und eine begründete Liste der beabsichtigten Änderungen – bis das alte System abgeschaltet werden kann.
Der Loop muss schnell und deterministisch sein: Ein Agent, der auf langsame oder flaky Tests trifft, lernt, es erneut zu versuchen statt zu beheben, oder streckt seine Durchläufe und verliert den Überblick über die Ursachen. Osmani empfiehlt einen Kern-Loop unter einer Sekunde, kontrollierten Zufall, den sofortigen Ausschluss flakyer Tests, knappe Ausgaben und aufwendigere Tests vor der Integration. Sein Fazit: Erst die Prüfung schreiben, dann den Code.