# osmani-agentic-verification-2026-10-14

## Veille

Beitrag von **Addy Osmani** auf seinem Substack *Elevate*, veröffentlicht am **14. Oktober 2026**; ca. 1.900 Wörter. These: Bei den aktuellen Modellen liegt der Engpass nicht mehr im Schreiben von Code, sondern in dessen **Verifizierung**; die menschliche Arbeit verschiebt sich von *„jede Zeile prüfen“* zu *„Loops bauen, die der Agent selbst ausführen kann.“*

## Titre Article

Agentic Verification — The bottleneck has moved from writing code to knowing it's correct.

## Date

2026-10-14

## URL

https://addyo.substack.com/p/agentic-verification

## Keywords

agentische Verifizierung, Feedback-Loop, selbstverifizierender Agent, End-to-End-Tests, E2E, Property-based Tests, Property-based Testing, Differentialtests, Orakel, Migration, Invarianten, Idempotenz, Determinismus, Flaky Tests, Flaky Tests, Feature-Map, formale Methoden, TLA+, Lean, Erfolgskriterium, Review von Belegen

## Authors

Addy Osmani — ingénieur (Anthropic, cf. fiches antérieures) ; billet sur son Substack *Elevate*.

## Ton

Profil: ein Praxisleitfaden für Ingenieure, die mit Coding-Agenten arbeiten, in selbstbewusstem, didaktischem Ton. Der Beitrag beginnt mit einer These (die Verifizierung ist der Engpass), definiert die Rolle von Tests neu und geht dann drei Familien von Prüfungen durch, jeweils mit ihren Vorteilen, Grenzen und Einstiegsempfehlungen, bevor eine Liste „So sieht es gut aus“ und eine abschließende Handlungsanweisung folgen. „Note“-Kästen verweisen auf angrenzende Praktiken (Feature-Maps, formale Methoden, Reviewer-Agenten). Die Argumentation stützt sich auf die eigene Erfahrung des Autors und Rückmeldungen ungenannter Teams, ohne Zahlen oder Studien. Kommentare erweitern die Diskussion: IronBee (auch die API hinter der UI prüfen) und ein Leser, der vorschlägt, die Abnahmekriterien vor dem bauenden Agenten zu verbergen.

## Pense-betes

- **These**: Der Engpass verschiebt sich vom Schreiben zur Verifizierung; der Mensch definiert Erfolg und prüft Belege, nicht Diffs.
- **Loop**: Schreiben → Prüfen → Lesen → Wiederholen, bevor ein Mensch überhaupt hinschaut; ein deutlich besserer Loop schlägt ein etwas besseres Modell.
- **Geschmack kapitalisieren**: Jeder Fehler des Agenten wird zu einer gemeinsamen Konfiguration, einem Hook oder einem Test.
- **E2E**: ein dem Nutzer treues Orakel; muss sagen, *was* fehlgeschlagen ist (Screenshots, Traces); wenige, aber hochwertige, da sie langsam und flaky sind.
- **Properties**: *„Beispieltests sagen, was passieren soll; Properties sagen, was nicht passieren darf“*; zuerst an einer reinen Funktion beginnen, die Property erst in einfachem Englisch formulieren, den minimierten Fall als Regressionstest behalten.
- **Differential**: altes System = Orakel; zufällige Eingaben oder wiedergegebener echter Traffic; Unwesentliches normalisieren; eine begründete Liste genehmigter Änderungen.
- **Gesunder Loop**: Kern-Loop unter einer Sekunde, geseedeter Zufall, eingefrorene Uhr, kontrolliertes Netzwerk; flaky Tests aus der Suite entfernt; kurze Ausgabe; E2E- und Diff-Tests vor der Integration.
- **Angrenzende Gewohnheiten**: Erfolgskriterien vor dem Coden erneut formulieren, ein Reviewer-Agent in frischem Kontext, generierte Tests überprüfen.
- Verwandt mit [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] und [[osmani-three-joys-engineering-agents-2026-10-09]].

## RésuméDe400mots

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.

## GrapheDeConnaissance

- Addy Osmani —publie→ article Agentic Verification (DOCUMENT, 0.98)
- Addy Osmani —affirme_que→ le goulot des agents de codage est la vérification, non l'écriture du code (AFFIRMATION, 0.95)
- Addy Osmani —affirme_que→ une bien meilleure boucle de rétroaction vaut mieux qu'un modèle un peu meilleur (AFFIRMATION, 0.92)
- Agentic verification —améliore→ Agents de codage (TECHNOLOGIE, 0.9)
- Agentic verification —utilise→ Tests E2E (METHODOLOGIE, 0.93)
- Agentic verification —utilise→ Property-based testing (METHODOLOGIE, 0.93)
- Agentic verification —utilise→ Differential testing (METHODOLOGIE, 0.93)
- Property-based testing —utilise→ fast-check (TECHNOLOGIE, 0.9)
- Property-based testing —utilise→ Hypothesis (TECHNOLOGIE, 0.9)
- Property-based testing —utilise→ proptest (TECHNOLOGIE, 0.9)
- Differential testing —s_applique_à→ migration logicielle (CONCEPT, 0.9)
- Tests instables —réduit→ Agentic verification (METHODOLOGIE, 0.85)
- Addy Osmani —recommande→ écrire le contrôle avant le code (AFFIRMATION, 0.95)
- Addy Osmani —recommande→ une boucle de tests rapide et déterministe, sous la seconde pour la boucle cœur (AFFIRMATION, 0.9)
- Addy Osmani —référence→ Lauren (@poteto) (PERSONNE, 0.85)
- Lauren (@poteto) —recommande→ Feature map (CONCEPT, 0.85)
- Boris Cherny —utilise→ TLA+ (TECHNOLOGIE, 0.85)
- Boris Cherny —utilise→ Lean (TECHNOLOGIE, 0.85)
- Boris Cherny —a_créé→ Claude Code (TECHNOLOGIE, 0.85)

---
Canonical: https://www.thekb.eu/de/fiches/osmani-agentic-verification-2026-10-14/