KI generierten Code testen, welche Tests Agents wirklich brauchen

Wie viel Code KI bei Anthropic schreibt

Wer KI generierten Code testen will, sollte zuerst die Größenordnung kennen. Über alle Projekte von Anthropic schreibt Claude inzwischen rund 80 Prozent des Codes. Bei Claude Code selbst liegt der Anteil sogar bei rund 90 Prozent, wie wir im Artikel zum Code Review des Claude Code Teams beschrieben haben. Engineers liefern pro Quartal etwa 8x so viel Code wie in den Jahren 2021 bis 2025. Das hat Addy Osmani auf X geteilt, verlinkt auf einen Bericht von Sachin Malhotra im Claude Blog. Die Nebenwirkung steht gleich dabei: Die Zahl der Tests ist um das 10fache gewachsen, die CI Jobs sind in sechs Monaten um das 25fache gestiegen.

Addy Osmani arbeitet seit September im Claude Code Team. In den letzten Wochen hat er immer wieder dasselbe Thema aufgegriffen: Wie weiß man, dass Code von einem Agent wirklich funktioniert? Seine Antwort ist in jedem Post gleich. Man gibt dem Agent einen Weg, seine Arbeit selbst zu prüfen.

Warum Code Review bei KI Code nicht mehr reicht

Ein Agent ist eine KI, die eine Aufgabe selbstständig abarbeitet: Sie liest Code, schreibt Änderungen und führt Befehle aus. Das geht schnell, oft schneller, als ein Mensch die Änderungen lesen kann. Mitte Oktober hat Addy Osmani das so beschrieben:

When generating software at a faster rate than you can review it, the bottleneck shifts to proving that it works.

Wenn Software schneller entsteht, als man sie prüfen kann, verschiebt sich der Engpass also zum Nachweis, dass sie funktioniert. Ein Mensch, der jede Zeile liest, reicht als Kontrolle nicht mehr. Laut Addy braucht es stattdessen ein System aus mehreren Prüfschichten mit schnellen, deterministischen Rückmeldungen für den Agent.

In einem weiteren Post dreht er den Gedanken weiter. Was guten Code früher teuer gemacht hat, also Tests, Benchmarks, Spezifikationen und echte End to End Läufe, kann man heute günstig bei einem Agent bestellen. Die Arbeit verschiebt sich damit:

less “review every line” and more “build loops the agent can run itself”

Weniger jede Zeile reviewen, mehr Schleifen bauen, die der Agent selbst ausführen kann. Diese Schleife ist laut Addy die Quelle der Qualität.

Welche Tests für KI Agents sinnvoll sind

Anfang Oktober hat Addy Osmani konkret aufgezählt, in welche Tests er investieren würde:

Testart	Was sie leistet
End to End Tests	Simulieren echte Nutzerwege und dienen als Wahrheit, an der sich der Agent messen muss
Property Based Tests	Legen fest, was nie passieren darf, und erzeugen tausende Testfälle, die diese Regeln zu brechen versuchen
Vergleich alt gegen neu	Wird ein System ersetzt, laufen beide Versionen mit zufällig gewählten Eingaben und werden verglichen
Schnelle, deterministische Tests	Liefern bei gleichem Code immer dasselbe Ergebnis, ohne lange Wartezeit

Der letzte Punkt klingt nach Handwerk, ist aber für Agents entscheidend. Ist die Testschleife langsam oder unzuverlässig, lernt der Agent laut Addy, den Test einfach neu zu starten, statt das Problem zu beheben. Ein roter Test muss also wirklich einen Fehler bedeuten.

Den Unterschied zwischen Beispieltests und Property Based Tests fasst er in einem Satz zusammen:

Example tests say what should happen; properties say what must not.

Beispieltests sagen, was passieren soll. Properties sagen, was nicht passieren darf.

Wann ist KI Code fertig

Ein Problem kennt jeder, der einen Agent Code reviewen lässt. Lucas (@lucas_builds) hat es auf X als Spielautomaten beschrieben: Jedes Review findet neue Fehler, auch beim zehnten Durchgang. Wann ist der Code also fertig?

Addy Osmanis Antwort: Vor dem Review klar festlegen, was “fertig” heißt. Ein Reviewer, ob Mensch oder Agent, findet ohne diese Definition immer noch etwas, das man verbessern könnte. Deshalb bekommt Claude Prüfungen, die es selbst ausführen kann, und muss sie bestehen, bevor es sich als fertig meldet:

• Bash Befehle
• Tests
• Durchklicken der App im Browser

Wenn danach nichts das Mergen blockiert, wird übernommen und ausgeliefert.

Screenshots und Videos als Testbeleg

Am 22. Oktober zeigte Addy Osmani, wie das in seinem eigenen Ablauf aussieht. Zusätzlich zu End to End Tests liefert Claude ihm aufgezeichnete Videos und Screenshots als Beleg, dass eine Arbeit erledigt ist. Er verweist dabei auf Warp, wo jeder Agent einen eigenen Rechner bekommt und ein Video seiner Arbeit zurückbringt.

Seine Einschätzung dazu: Verifikation wird eines der wichtigsten Probleme, an denen man dieses Jahr arbeiten kann.

Ein weiterer Punkt aus seinem Post zum Prüfen: Wenn der Agent etwas falsch macht, wird das festgehalten, in einer gemeinsamen Konfiguration, einem Hook oder einem Test. So passiert derselbe Fehler kein zweites Mal. Der Mensch bleibt für das Ausgelieferte verantwortlich, prüft aber Belege statt nur Diffs.

Test Impact Analysis bei wachsender CI Last

Mehr Tests heißen mehr Last in der CI, also der Pipeline, die bei jeder Änderung automatisch baut und testet. Wie Anthropic damit umgeht, beschreibt Sachin Malhotra im Claude Blog.

Anthropic nutzt Test Impact Analysis. Ein Dienst entscheidet bei jedem Pull Request, welche Tests laufen müssen, anhand früherer Testergebnisse und der betroffenen Pakete. Er besteht aus zwei Teilen: Ein Listener speichert die Ergebnisse jedes CI Laufs, ein Selector wählt daraus die Tests für offene Pull Requests.

Mit dem Wachstum geriet der Dienst immer wieder an seine Grenzen. Drei schnelle Reparaturen hielten 70 Tage, 29 Tage und schließlich weniger als einen Tag. Hing der Listener 20 Minuten hinterher, konnten Zehntausende Testergebnisse noch nicht beim Selector angekommen sein.

Die Lösung war ein Neubau:

• Die Listener speichern keinen Zustand mehr und schreiben Ergebnisse nur noch in ein Journal in einem In-Memory Datenspeicher außerhalb des Prozesses.
• Ein eigener Prozess fasst das Journal alle paar Sekunden zur Testhistorie zusammen.
• Der Selector liest diese Historie schnell aus.

Ein Engineer brauchte dafür drei Wochen. Ein Jahr früher hätte es laut Autor etwa ein Quartal gedauert. Die Feinabstimmung, etwa Journalgröße und Zahl der Worker, hat Claude weitgehend selbst erledigt. Seitdem bleibt der Rückstau unverarbeiteter Ergebnisse flach.

Seine Empfehlungen für andere Teams:

1. Wachstum einplanen: davon ausgehen, dass die eigene Architektur innerhalb von zwei Quartalen 25fache Last trägt.
2. Die erste Version, wenn das Budget es erlaubt, für das 10 bis 20fache der erwarteten Last auslegen.
3. Zustand von Anfang an aus den Prozessen heraushalten, damit Worker horizontal skalieren.
4. Kritische Dienste nicht als einzelne Instanz betreiben, außer man kann sie und jede Canary Änderung messen.
5. Dienste so ausstatten, dass Claude sie beobachten kann, als “Augen und Ohren” für die Fehlersuche.

Fazit

Die Posts aus dem Claude Code Team zeigen ein klares Muster. Je mehr Code Agents schreiben, desto mehr hängt die Qualität an den Prüfungen, die der Agent selbst ausführen kann. End to End Tests als Wahrheit, Property Based Tests für das, was nie passieren darf, und schnelle, stabile Testläufe sind dafür die Grundlage. Die Kehrseite ist mehr Last in der CI, und die muss man von Anfang an mitplanen.

Für uns sind solche Einblicke der Grund, warum wir die Neuigkeiten rund um Agentic Coding laufend verfolgen. Was wir dabei lernen, testen wir zuerst praktisch in eigenen Side Projects. Was sich dort bewährt, bringen wir in Kundenprojekte und in unsere Workshops. Wenn ihr Tests und Agents in eurem Team zusammenbringen wollt, schaut euch gern den NCA KI Workshop für Developer an.