Auditable Acceptance of LLM-Generated Code:An Evidence-Based Testing Architecture and Multi-Source Evaluation

In der modernen Softwarewelt schreiben Computer zunehmend ihren eigenen Code. Große Sprachmodelle, die gleiche Art von künstlicher Intelligenz, die auch E-Mails entwerfen oder Nachrichten zusammenfassen kann, werden nun gebeten, die komplexen Anweisungen zu schreiben, die unsere Anwendungen steuern. Dieser Wandel bietet unglaubliche Geschwindigkeit, führt aber ein grundlegendes Problem ein: Wie wissen wir, ob der Code tatsächlich korrekt ist? Ein Computerprogramm kann eine bestimmte Gruppe von Tests bestehen und dennoch auf eine Weise versagen, die diese Tests nie vorgesehen hatten. Genau wie eine Brücke unter einer leichten Last halten kann, aber unter einem schweren Lkw zusammenbricht, kann Code, der eine einfache Prüfung besteht, dennoch verborgene Fehler enthalten. Die Herausforderung für Ingenieure besteht nicht nur darin, Tests durchzuführen, sondern zu verstehen, was diese Tests tatsächlich beweisen – um zwischen einem Stück Code, das wirklich sicher ist, und einem zu unterscheiden, das lediglich noch nicht erwischt wurde.

Diese Frage steht im Zentrum einer neuen Studie von Forschern der Southwest Jiaotong University, der University of Bristol und der Sichuan Agricultural University. Sie haben sich zum Ziel gesetzt, ein System zu entwickeln, das nicht einfach nur „bestanden“ oder „nicht bestanden“ sagt, sondern stattdessen eine detaillierte, prüfbare Aufzeichnung darüber erstellt, warum ein Stück Code akzeptiert, abgelehnt oder zur weiteren Überprüfung weitergeleitet wurde. Sie nennen dieses System die Intelligent Testing Infrastructure, oder ITI. Anstatt die Codegenerierung als eine magische Blackbox zu behandeln, konzentrierten sich die Forscher auf die unordentliche Realität der Verifizierung: Sie zeichnet genau auf, welche Tests durchgeführt wurden, was sie abdeckten und wie viel Vertrauen diese Tests tatsächlich rechtfertigen sollten. Ihre Arbeit zeigt, dass wir zwar das Testen strenger gestalten können, das bloße Hinzufügen von mehr Tests jedoch nicht automatisch unsere endgültige Auswahl an Code sicherer macht. Tatsächlich legen ihre Experimente nahe, dass strengere Regeln oft ebenso häufig guten Code ablehnen wie schlechten Code finden, wodurch das Gesamtrisiko, ein fehlerhaftes Programm zu akzeptieren, unverändert bleibt.

Die Forscher näherten sich diesem Problem durch den Entwurf eines Workflows, der wie ein sorgfältiger Torwächter fungiert. Wenn ein Stück Code eintrifft, wird es nicht nur einer schnellen Prüfung unterzogen; es wird einer Reihe von Verifizierungen unter kontrollierten Bedingungen unterzogen. Das System zeichnet jedes Detail auf: die spezifische Version des Codes, die verwendeten Werkzeuge zum Testen und die exakte Umgebung, in der er ausgeführt wurde. Entscheidend ist, dass das System zwischen drei Ergebnissen unterscheidet. Wenn ein Test einen klaren Fehler findet, wird der Code abgelehnt. Wenn die Tests nichts Falsches finden, aber die Beweislage sich unvollständig anfühlt oder die Tests nicht stark genug waren, wird der Code zur genaueren Untersuchung eskaliert. Nur wenn die Beweise sowohl vollständig als auch positiv sind, wird der Code akzeptiert. Dieser Prozess schafft einen „Decision Freeze“ (Entscheidungsstopp), einen Moment, in dem die Beweise festgeschrieben werden, bevor externes Wissen darüber, ob der Code wirklich korrekt ist, enthüllt wird. Dies stellt sicher, dass die Entscheidung ausschließlich auf dem basiert, was zu diesem Zeitpunkt bekannt war, was den gesamten Prozess transparent und später nachvollziehbar macht.

Um zu sehen, ob dieser Ansatz funktionierte, führte das Team zwei unterschiedliche Arten von Experimenten durch. Die erste war eine streng kontrollierte Studie mit 80 Code-Stücken, die die Forscher selbst konstruiert hatten, um spezifische, bekannte Fehler zu enthalten. Diese wurden gegen einen Basissatz von Prüfungen und dann gegen einen zweiten, gründlicheren Satz von Prüfungen getestet. Die Ergebnisse waren aufschlussreich. Der zweite Testsatz erfasste 16 fehlerhafte Code-Stücke, die der erste Satz übersehen hatte, was bewies, dass stärkere Tests tatsächlich mehr Fehler finden können. Als die Forscher jedoch ihre strengen „Akzeptieren-Eskalieren-Ablehnen“-Regeln anwandten, war das Ergebnis weniger optimistisch. Die strengeren Regeln reduzierten erfolgreich die Anzahl der schlechten Code-Stücke, die akzeptiert wurden, lehnten aber auch eine proportionale Anzahl an guten Code-Stücken ab. Das Ergebnis war, dass die finale Gruppe des akzeptierten Codes immer noch die Fehlerquote der vorangegangenen Gruppe aufwies: 50 Prozent. Mit anderen Worten: Durch die erhöhte Sorgfalt machten sie die endgültige Charge an Code nicht sicherer, sondern machten die Charge lediglich kleiner.

Die Forscher testeten dieses System dann in einem größeren, realistischeren Maßstab mit 200 Code-Stücken, die von zwei verschiedenen Modellen der künstlichen Intelligenz, Qwen und DeepSeek, über 50 verschiedene Programmieraufgaben hinweg generiert wurden. Hier zeigte das System eine andere Art von Wert. Durch die Verwendung einer intelligenten Eskalationsstrategie war das System in der Lage, dieselben endgültigen Entscheidungen zu treffen, als hätte es seine teuersten und leistungsfähigsten Tests für jedes einzelne der 200 Kandidaten durchgeführt, tat dies jedoch, indem es diese schweren Tests nur für 132 der 200 Kandidaten ausführte. Dies sparte erhebliche Rechenzeit und Ressourcen. Als sie jedoch die Qualität des akzeptierten Codes betrachteten, schnitt das System nicht besser ab als eine Zufallsauswahl derselben Größe. Das „intelligente“ System schaffte es nicht, besseren Code auszuwählen als der Zufall; es sparte schlichtweg Geld, indem es unnötige Prüfungen bei Code vermied, der eindeutig schlecht oder eindeutig gut war.

Die Studie untersuchte auch die Struktur der Tests selbst und prüfte, ob unterschiedliche Tests tatsächlich unterschiedliche Arten von Fehlern fanden oder lediglich dieselben Prüfungen wiederholten. Sie fanden heraus, dass in vielen großen Testsammlungen ein erheblicher Teil redundant war, was bedeutet, dass sie nach exakt denselben Fehlern suchten. Andere waren „Zero-Detection“-Tests, die in dem bekannten schlechten Code, den sie eigentlich erfassen sollten, keine Fehler fanden. Darüber hinaus entdeckten sie, dass viele Fehler nur von einem einzigen Test erfasst wurden. Sollte dieser eine Test fehlschlagen oder entfernt werden, würde der Fehler unbemerkt bleiben. Diese Fragilität deutet darauf an, dass eine große Anzahl von Tests keine Sicherheit garantiert, wenn die Tests nicht vielfältig und robust sind.

Letztlich kommt das Paper zu dem Schluss, dass die Intelligent Testing Infrastructure zwar erfolgreich eine klare, prüfbare Aufzeichnung darüber erstellt, wie Entscheidungen getroffen werden, aber das Problem der Auswahl des besten Codes noch nicht löst. Das System funktioniert gut dabei, den Prozess zu dokumentieren und Ressourcen zu sparen, indem es unnötige Prüfungen überspringt, aber es hat noch nicht bewiesen, dass es zuverlässig besser zwischen gutem und schlechtem Code unterscheiden kann als der Zufall. Die Forscher betonen, dass ihre Ergebnisse auf spezifischen, kontrollierten Experimenten basieren und dass die „Korrektheit“ des Codes oft von anderen Modellen der künstlichen Intelligenz statt von unabhängigen menschlichen Experten beurteilt wurde. Sie argumentieren, dass der nächste Schritt darin besteht, dieses System mit einer echten, unabhängigen Verifizierung und Aufgaben zu testen, die das System noch nie gesehen hat. Bis dahin ist das Wertvollste, was das System bietet, nicht eine Garantie für Sicherheit, sondern eine klare, ehrliche Aufzeichnung dessen, was zu jedem Zeitpunkt der Reise bekannt war und was entschieden wurde.