Coding-Agenten scheitern an Test- und Verifikationstechniken – selbst mit expliziten Anweisungen
How well do agents use test/verification techniques?
Dan Luu untersuchte, ob Coding-Agenten bessere Software schreiben, wenn man ihnen explizit Test- oder Verifikationstechniken wie TDD, Property-based Testing oder formale Methoden (Lean 4, TLA+, Verus) vorgibt. In 26 Prompt-Bedingungen mit insgesamt über 80 Läufen pro Bedingung implementierten Agenten den Zstd-Kompressionsalgorithmus in Rust. Ergebnis: Keine Technik verbesserte die Korrektheit signifikant; die Standardbedingung ohne Zusatzanweisungen schnitt überdurchschnittlich ab. Agenten neigen dazu, Techniken oberflächlich anzuwenden – etwa irrelevante Eigenschaften zu beweisen oder triviale Random-Tests zu schreiben – und verfehlen so den eigentlichen Nutzen. Auch von Codex empfohlene Test-Skills (z. B. ECC mit 250k GitHub-Sternen) halfen nicht. Luu schlägt vor, dass KI-Labore Reinforcement-Learning-Umgebungen für effektives Testen schaffen sollten, ähnlich wie bei Optimierungsproblemen.
Wenn man Agenten bittet, eine bestimmte Testtechnik oder Testbibliothek zu verwenden, ändert sich dieser Ansatz nicht so sehr, wie man hoffen würde.
- andai
Ich entwickle Indie-Spiele, bin mir also nicht sicher, wie gut sich meine Erfahrung übertragen lässt, aber ich arbeite an einem Browserspiel, und das Spiel ist irgendwie schlecht, aber es gibt eine riesige Menge an Tests (nach meinen Maßstäben). Man kann also Schrottsoftware mit vielen Tests haben. (Man kann auch großartige Software mit sehr wenigen Tests haben!)
Außerdem hatte ich eine lustige Erfahrung, bei der KI eine architektonische Änderung komplett rückwärts implementiert hat. Die Implementierung war sinnlos und machte die Dinge schlechter statt besser. Aber ich hatte trotzdem "alle Tests grün" lol, weil es nur bewies, dass das Falsche ordnungsgemäß funktionierte.
Mit einiger Belustigung stellte ich fest, dass formale Verifikation dort auch nicht geholfen hätte, sie wäre nur ein noch stärkerer Beweis für die "Korrektheit" des Dinges gewesen, das es von vornherein nicht hätte geben dürfen.
- ivanzhaowy123
Meiner Erfahrung nach denken Agenten beim Schreiben von Unit-Tests oft an mehr Randfälle als Menschen. Aber unter der Anleitung bestimmter Fähigkeiten können sie mechanisch werden und die Geschäftslogik aus den Augen verlieren.
Wenn ich zum Beispiel das Superpowers-Fähigkeitsset verwende, übernimmt der Agent proaktiv TDD für jede neue Funktion. Aber sein Verständnis von Tests bleibt oft oberflächlich: Wenn der Benutzer einen Bildschirm mit einem "Senden"-Button anfordert, schreibt er zuerst einen Test, der prüft, ob der Button existiert. Der Test schlägt fehl, also fügt er den Button hinzu, um ihn zu bestehen.
Infolgedessen füllt sich die Testsuite mit minderwertigen Fällen, die prüfen, ob eine Eigenschaft existiert oder ob ein String exakt übereinstimmt. Der Agent folgt dem Arbeitsablauf "einen fehlschlagenden Test schreiben, dann die Funktion implementieren", testet aber nie wirklich das Geschäftsverhalten: Wann sollte das Senden erlaubt sein? Was sollte nach Erfolg oder Misserfolg passieren? Wie sollten doppelte Übermittlungen behandelt werden?
Das Problem ist nicht, dass Agenten keine Tests schreiben können. Es ist, dass sie dazu neigen, TDD auf eine starre Abfolge von Schritten zu reduzieren und Schwierigkeiten haben, eigenständig aussagekräftige Testfälle aus Geschäftsanforderungen abzuleiten und sie zur Steuerung der Entwicklung zu nutzen.
- siscia
Es ist noch früh, aber ich finde, dass dieses Experiment wenig bis keinen Sinn ergibt und kaum nützlich ist.
Die Art und Weise, wie man Code testet, kann (und sollte) nicht von der Art und Weise entkoppelt werden, wie man den Code selbst architekturiert.
Über 80 % des effektiven Testens liegt nicht im Testframework, sondern in der Code-Architektur.
Der Autor erwähnt nicht, wie der Code architekturiert und verwaltet wird.
Was es wert ist: Ich habe festgestellt, dass das Zwingen von Agenten auf DI/hexagonale Architektur und das Erzwingen einer trivialen Abdeckungsprüfung ziemlich nützlich ist und insgesamt gute genug Code mit relativ wenig Aufwand produziert.
- movpasd
Das ist deutlich gründlicher als alles Testen, das ich je gemacht habe, und in einer völlig anderen Domäne, aber meine anekdotische Erfahrung, Agenten zur Verwendung von Hypothesis zu bringen, war ziemlich schlecht.
Der Agent hatte wirklich große Schwierigkeiten, die Lücke zwischen dem Code und den tatsächlichen Geschäftsregeln, die er modellieren sollte, zu überbrücken. Er hatte auch Schwierigkeiten herauszufinden, für welche Funktionen auf welcher Ebene es angemessen war, Tests zu schreiben. Daher waren seine Tests tendenziell sehr anfällig für Änderungen an der Domänenlogik.
Im Wesentlichen schienen Agenten immer mit Modularität und Problemzerlegung zu kämpfen. Gutes Testen bedeutet, die richtigen Dinge zu testen, was bedeutet, herauszufinden, wie man den Eingabezustand in einen geeigneten Produktzustand unterteilt und jedes Verhalten unabhängig überprüft. IMO ist das das Schwierigste und Komplizierteste am Programmieren, also werde ich nicht sagen, dass es _mehr_ gekämpft hat als ein Mensch --- aber Menschen haben den Vorteil, darüber schlafen zu können?
Eine kleine Sache, die ich beobachtet habe, war, dass es dazu neigte, sich wirklich an Gleitkomma-Randfällen (NaNs, Unendlichkeiten) aufzuhängen. Vielleicht sind Gleitkomma-Randfälle in den Trainingsdaten für Property-basiertes Testen überrepräsentiert, aber es ist für meinen Anwendungsfall im Wesentlichen irrelevant, zumindest was die Geschäftsregeln betrifft.
- anitil
Du weißt, wie alle denken, dass Agenten schlecht in dem sind, worin sie gut sind, und gut in dem, worin sie schlecht sind? Es stellt sich heraus, dass ich wohl schlecht im Testen bin, denn ich dachte, sie machen einen vernünftigen Job.