Workflow
Was Agenten beim Testen wirklich tun
Dan Luu hat 30 Varianten mit je 80 Läufen gemessen. Test-Anweisungen im Prompt ändern weniger als gedacht, große Skills kosten und bringen nichts.
Wenn ein Agent schlecht testet, ist der naheliegende Griff eine Anweisung im Prompt. "Nutze property-based testing", "Arbeite nach TDD", "Verwende Lean 4". Das kostet nichts und fühlt sich nach Steuerung an.
Dan Luu hat gemessen, was dabei herauskommt. Das Ergebnis ist unbequem, und zwar in eine Richtung, die man so nicht erwartet: Die Anweisung ändert oft weniger als gar keine Anweisung.
Wie gemessen wurde
Implementiert werden sollte Zstd-Kompression in Rust, geprüft an einer harten Metrik: Anteil der Läufe, die 100 Prozent der versteckten Tests bestehen. Getestet wurden 26 Prompt-Bedingungen und zusätzlich vier Skills, jeweils 80 Läufe pro Bedingung und Effort-Stufe, mit Codex auf GPT-5.6 Sol in den Stufen medium und xhigh.
Die Bedingungen decken das übliche Feld ab: Default ohne Zusatz, TDD, Property-based Testing, Proptest, QuickCheck, Fuzzing, Mutation Testing, Metamorphic Testing, Differential Testing, dazu formale Werkzeuge wie Verus, Alloy, Lean 4, TLA+, Kani, Creusot, ACL2, Spin und SMT-Solver. Als Kontrollbedingung lief "Make no mistakes" mit, der alte Witz.
Luu hat seine Erwartungen vorher notiert, mit Konfidenzangaben. TDD werde schlechter abschneiden (55 Prozent), formale Methoden nicht besser (52 Prozent), "Make no mistakes" nichts bringen (95 Prozent). Diese Vorab-Festlegung ist der Grund, warum die Ergebnisse mehr wert sind als die übliche Erfahrungsanekdote.
Der Kernbefund
Agenten wenden die genannte Technik nicht wirklich an. Sie schreiben entweder die Tests, die sie ohnehin geschrieben hätten, nur im Rahmen eines fremden Frameworks. Oder sie benutzen die Technik oberflächlich und verfehlen genau das, was ihren Wert ausmacht.
Drei Beobachtungen machen das greifbar:
Verus. Statt die Implementierung zu verifizieren, bewiesen die Agenten abstrakte Nebeneigenschaften. Häufig auch schlicht Zirkelschlüsse. Luu zitiert einen echten Beweis aus dem Lauf, der in requires dieselben drei Bedingungen fordert, die er in ensures garantiert. Für die Korrektheit sorgten am Ende gewöhnliche Rust-Unittests.
TLA+ auf der IMAP-Aufgabe. Fünf von 80 Agenten benutzten TLA+, bevor sie Code schrieben. 75 implementierten erst und holten das Werkzeug danach hervor. Modelliert wurde dann ausgerechnet der Teil, den die Default-Bedingung zu über 99,6 Prozent richtig hatte, während die fehleranfälligen Stellen unangetastet blieben.
Differential Testing. Kein einziger Agent baute zwei unabhängige Implementierungen, um sie zu vergleichen. 135 von 160 Läufen taten etwas, das man so nennen könnte, aber wo ein Fehler hätte auffallen können, schrieben die Agenten zweimal dasselbe und damit denselben Fehler zweimal hinein.
Die Default-Bedingung ohne jede Zusatzanweisung landete deutlich über dem Durchschnitt.
Skills sind nicht neutral
Für Teams, die mit Skill-Sammlungen arbeiten, ist der Skill-Teil der interessanteste. Luu hat drei fremde Skills getestet, die Codex selbst als passend vorschlug, dazu einen eigenen, schnell geschriebenen.
Beim Hegel-Skill lässt sich der Schaden beziffern. Auf 34.000 Zeichen Skill kommen 45.000 Zeichen nachgeladene Rust-Referenz, zusammen über 20.000 Token. Das Material wird zu Beginn geladen und bei vielen Folgeaktionen erneut gelesen. Die Cache-Trefferquote lag bei 99,85 Prozent, und trotzdem blieb ein spürbarer Kostenanteil: 16 Prozent höhere Dollarkosten auf medium, 18 Prozent auf xhigh, allein für das Nachladen. Weil der Skill zusätzlich einen strukturierten Ablauf vorschreibt, lagen die Gesamtkosten 26 Prozent (medium) und 41 Prozent (xhigh) über der Vergleichsbedingung. Besser wurde die Korrektheit davon nicht, eher etwas schlechter.
Beim ECC-Skill aus einer Sammlung mit 250.000 GitHub-Sternen liegt der Befund noch schräger. Der Rohwert sah passabel aus, aber er kam von den sieben Agenten, die den Skill gar nicht gelesen hatten, und von neun weiteren, die ihn so spät ansahen, dass er kaum wirkte. Der Score wurde von denen getragen, die die Anweisung ignorierten.
Luus eigener Skill schnitt ordentlich ab. Er benennt den Unterschied selbst: Sein Skill schiebt die Agenten von ihrem Standardverhalten weg, die anderen lesen sich wie Tutorials. Ein Skill, der erklärt, was eine Technik ist, ändert wenig. Einer, der sagt, was der Agent anders machen soll als sonst, wirkt.
Was die Messung nicht hergibt
Der Zuschnitt ist eng, und das gehört dazu.
Gemessen wurde ein Modell in zwei Effort-Stufen, eine Sprache, und als Aufgaben Implementierungen nach RFC: Zstd, IMAP, ein paar weitere in Einzelläufen. Das ist kein breites Aufgabenspektrum. Ob dieselben Muster bei einer Webanwendung, einer Datenpipeline oder einem Refactoring in gewachsenem Code auftreten, sagt die Untersuchung nicht. Luu warnt außerdem selbst davor, aus der Rangfolge der Bedingungen starke Schlüsse zu ziehen, und berichtet, dass einige auffällige Ergebnisse sich nach Korrektur eines Aufsetzfehlers in Luft auflösten. Übrig blieb der Skill-Befund.
Eine Einschränkung dreht allerdings in die andere Richtung als erwartet. RFC-Implementierungen sind unrealistisch, aber sie sind es zugunsten der Agenten: Die Spezifikation ist klarer, detaillierter und eindeutiger als das, was Entwickler ihren Agenten üblicherweise geben. Luus Erwartung für echte Projekte lautet deshalb, dass dieselben Fehlermuster dort gleich stark oder stärker auftreten. Wer die Ergebnisse für zu pessimistisch hält, sollte diesen Punkt mitnehmen.
Was wir daraus mitnehmen
Der Befund berührt unsere eigenen Empfehlungen. In Bewährte Skills für Entwickler:innen empfehlen wir Skill-Sammlungen, darunter einen Skill von Trail of Bits, deren Property-Test-Skill hier ebenfalls im Testfeld lag. Diese Empfehlungen mit der Messung im Rücken zu prüfen, statt sie stehen zu lassen, ist die ehrlichere Reaktion.
Drei Dinge sind daraus praktisch verwertbar.
Erstens: Der Name einer Technik im Prompt ist keine Steuerung. Wer property-based testing will, muss sagen, welche Eigenschaft geprüft werden soll, sonst kommen zufällige Eingaben heraus, die überwiegend in Ablehnungspfaden landen.
Zweitens: Große Tutorial-Skills aus fremden Repos sind nicht gratis. Sie liegen im Kontext, werden nachgeladen, kosten messbar und verbessern die Korrektheit im Testfeld nicht. Der Sternestand des Repos sagt darüber nichts.
Drittens: Ein Skill sollte beschreiben, was anders laufen soll als im Standardverhalten, nicht was ein Verfahren ist. Das Modell kennt die Verfahren. Was fehlt, ist der Anstoß, sie an der Stelle einzusetzen, an der die Fehler tatsächlich sitzen.
Für QA heißt das vor allem eins: Der Prüfblick auf agentengeschriebene Tests bleibt nötig. Ob die Tests den fehleranfälligen Teil überhaupt berühren, verrät ein grüner Lauf in diesem Feld nicht. Was das für die Rolle bedeutet, steht in Agentic QA: Testen mit und gegen KI-Agenten.