NeurIPS 2026: Wie testet man Code-Agenten, ohne nur bestandene Tests zu zählen?

Dieser Beitrag richtet sich an Entwicklungsteams und Forschende, die Code-Agenten verlässlich bewerten oder Software-Engineering-Agenten reproduzieren möchten. Er zeigt, wie Aufgaben, Ergebnisse, Ausführungsspuren und Umgebungsbedingungen zusammen ein belastbareres Prüfverfahren ergeben.

Ein Agent meldet „Tests bestanden“, aber niemand kann nachvollziehen, welche Änderungen und Prüfungen zu diesem Ergebnis geführt haben.

Schnellste Lösung: Bewerten Sie Ergebnis, Agent-Ausführungsspur und tatsächliches Prüfverhalten gemeinsam; wiederholen Sie die Aufgaben in einer festgelegten Zielumgebung. Die NeurIPS-2026-Forschung kann Anregungen liefern, ersetzt aber nicht die Prüfung auf Ihrem eigenen Aufgabensatz.

Für Entwicklungsteams, die Code-Generierungs- oder Reparatur-Agenten vergleichen, bietet dieser Ablauf eine belastbarere Regression. Für Verantwortliche von Evaluationsplattformen hilft er, Prozessfehler und Ursachen fehlgeschlagener Läufe sichtbar zu machen. Für Forschungsteams, die Arbeiten zu Software-Engineering-Agenten reproduzieren, beschreibt er, welche Umgebung und Nachweise dafür nötig sind.

Aussagekraft bestandener Tests

Ein bestandener Test ist ein Ergebnis unter bestimmten Bedingungen. Er belegt, dass ein bestimmter Programmzustand die ausgeführten Prüfungen bestanden hat. Er belegt nicht automatisch, dass der Agent den Fehler verstanden, die passende Stelle geändert oder alle relevanten Tests ausgeführt hat.

Darin liegt eine häufige Falle: Eine Aufgabenbeschreibung verlangt, einen Fehler zu beheben. Der Agent probiert Änderungen aus, startet einzelne Prüfungen und landet schließlich bei einer Variante, die den vorhandenen Testlauf besteht. Die Messzahl sieht gut aus. Trotzdem können andere Fälle ungetestet bleiben, eine Änderung kann unnötig breit ausfallen oder die Erfolgsmeldung kann sich auf einen veralteten Arbeitsstand beziehen.

Wir trennen deshalb zwei Fragen:

• Ist das gewünschte Ergebnis erreicht? Die Änderung erfüllt die fachliche Anforderung und besteht die vorgesehenen Akzeptanzprüfungen.
• Ist der Weg dorthin nachvollziehbar und hinreichend abgesichert? Werkzeuge, Änderungen, Testausgaben und Wiederherstellungsschritte ergeben eine prüfbare Abfolge.

Das ist keine Forderung, jeden internen Gedanken eines Modells auszuwerten. Entscheidend sind beobachtbare Ereignisse: Was wurde geändert? Welche Befehle liefen? Welche Ergebnisse lieferten sie? Wurde nach der letzten Änderung erneut geprüft? Eine ausführliche Spur ist dabei nicht automatisch eine gute Spur. Sie muss dem Team helfen, den Lauf zu rekonstruieren und Fehler zu diagnostizieren.

Auch ein bekanntes Benchmark-Ergebnis ersetzt diese Prüfung nicht. Der Beitrag zu SWE-bench beschreibt Aufgaben aus realen GitHub-Problemen in zwölf Python-Repositories und umfasst insgesamt 2.294 Aufgaben. Diese Angaben beschreiben den Benchmark, nicht die allgemeine Qualität eines beliebigen Agenten oder Ihrer eigenen Aufgabenmischung. Der SWE-bench-Artikel mit Aufgabenbeschreibung und Benchmark-Aufbau ist deshalb hilfreicher als eine isolierte Erfolgsquote: Er macht sichtbar, welche Art von Arbeit überhaupt bewertet wurde.

Grenzen einer reinen Erfolgsquote

Eine reine Bestehensquote verwischt mehrere unterschiedliche Fehlerbilder. Das erschwert sowohl die Auswahl eines Agenten als auch die Verbesserung des eigenen Systems.

Blindes Wiederholen: Ein Agent reagiert auf einen Fehler mit weiteren, wenig gezielten Änderungen. Wenn erst ein späterer Versuch besteht, zählt die Erfolgszahl möglicherweise nur den Endzustand. Die vorangegangenen Fehlversuche, Kosten und unnötigen Änderungen sind dann in der Kurzbewertung unsichtbar.

Fehlende Verifikation: Der Agent ändert Dateien, meldet Erfolg und führt anschließend keine passende Prüfung aus. Wurde ein Testlauf vor der letzten Änderung gestartet, sagt sein Ergebnis nichts Verlässliches über den abschließenden Stand aus. Halten Sie deshalb fest, ob eine Prüfung nach der letzten relevanten Änderung lief.

Unklare Reihenfolge: Wenn Werkzeugaufrufe und Änderungen nicht zeitlich zusammengeführt werden, lässt sich oft nicht feststellen, welche Version getestet wurde. Eine spätere Fehlersuche wird zur Vermutung statt zur Rekonstruktion.

Zu enge Abdeckung: Ein Aufgabenbestand kann überwiegend kleine, gut abgegrenzte Änderungen enthalten. Dann zeigt eine gute Quote nicht, wie sich der Agent bei Abhängigkeiten, mehrdeutigen Anforderungen oder einem bestehenden Fehler im Testsystem verhält. Das ist kein Einwand gegen eine Quote; es ist ein Grund, sie zusammen mit der Aufgabenverteilung zu lesen.

Nicht vergleichbare Läufe: Unterschiedliche Abhängigkeiten, Berechtigungen, Startzustände oder Testbefehle können Ergebnisse verändern. Wenn diese Bedingungen nicht festgehalten werden, lässt sich ein Unterschied zwischen zwei Agentenversionen nicht sicher dem Agenten zuschreiben.

Als zusätzliche Orientierung gibt es SWE-bench Verified: Die dazugehörige Vorstellung beschreibt eine von Menschen geprüfte Auswahl mit 500 Aufgaben. Die Zahl bezeichnet den Umfang dieser Auswahl, nicht den Beweis, dass ein Agent in jedem Repository zuverlässig ist. Prüfen Sie die Erläuterung zu SWE-bench Verified und zur Auswahl der Aufgaben, bevor Sie Ergebnisse daraus mit Ihrem eigenen Aufgabensatz vergleichen.

Bewertungsoptionen für Code-Agenten

Die folgende Tabelle trennt Beobachtungen, die in einer kurzen Erfolgszahl häufig zusammenfallen. Nutzen Sie sie als Entscheidungshilfe: Ein Agent, der nur beim Ergebnis überzeugt, ist anders zu bewerten als ein System, dessen Prozess sich untersuchen und wiederholen lässt.

Ein Team kann die Prüfschritte zusätzlich bewerten, ohne dafür eine scheinpräzise Kennzahl zu erfinden. Verwenden Sie eine einfache interne Einstufung:

• Nicht ausreichend: Ergebnis nicht belegt oder Arbeitsstand nicht rekonstruierbar.
• Teilweise belegt: Prüfungen liefen, aber Änderungsumfang oder Verifikation nach der letzten Änderung bleiben unklar.
• Nachvollziehbar: Änderung, Befehle, Fehlerbehandlung und Abschlussprüfung sind prüfbar.
• Wiederholt bestätigt: Der Lauf lässt sich unter dokumentierten Bedingungen erneut ausführen und das Ergebnis wird bestätigt.

Diese Einstufung ist eine Teamkonvention, kein veröffentlichter Benchmarkwert. Legen Sie vor der Auswertung fest, welche Nachweise für eine Freigabe nötig sind. Sonst wird die Bewertung nachträglich an das gewünschte Ergebnis angepasst.

Aufbau eines aussagekräftigen Aufgabensatzes

Ein guter Aufgabensatz ist nicht einfach eine Sammlung von Fehlern, die sich leicht reproduzieren lassen. Er soll die Grenzen der späteren Nutzung abbilden. Beginnen Sie mit Kategorien, die im eigenen Repository tatsächlich vorkommen: Fehlerkorrekturen, Änderungen an vorhandener Funktionalität, Tests, Dokumentation oder Aufgaben mit mehreren betroffenen Komponenten. Streichen Sie Kategorien, die für Ihr Einsatzgebiet keine Rolle spielen, statt sie nur für eine umfangreiche Tabelle aufzunehmen.

Bewahren Sie für jede Aufgabe einen Ausgangsstand und eine klare Erwartung auf. Diese sollte enthalten:

• den Ausgangscommit oder eine anderweitig eindeutig identifizierte Repository-Version;
• eine Aufgabenbeschreibung, die nicht schon den vollständigen Patch verrät;
• die erwartete Wirkung und die Akzeptanzbedingungen;
• relevante Testbefehle und bekannte Voraussetzungen;
• Hinweise auf eingeschränkte Berechtigungen oder nicht verfügbare externe Dienste;
• eine Regel, nach der die Änderung geprüft wird, auch wenn der Agent einen anderen Lösungsweg wählt.

Ein Teil der Aufgaben sollte schwierige oder mehrdeutige Bedingungen enthalten, sofern solche Fälle im Zielbetrieb vorkommen. Dazu gehören beispielsweise bestehende Tests, die erst angepasst werden müssen, eine Abhängigkeit, die nicht verfügbar ist, oder eine Anforderung, bei der eine zu weit gefasste Änderung unerwünscht wäre. Kennzeichnen Sie solche Fälle ausdrücklich. Ein Fehlschlag wegen einer nicht erreichbaren externen Abhängigkeit sollte nicht stillschweigend wie ein Fehler des Agenten gezählt werden.

SWE-bench bietet dafür einen nützlichen Bezugspunkt, nicht eine fertige Vorlage für jedes Team. Die Projektbeschreibung und Aufgabeninformationen von SWE-bench helfen zu verstehen, welche Metadaten ein öffentlicher Aufgabenbestand bereitstellt. Übernehmen Sie die Grundidee, Aufgaben und Ausgangszustände zu dokumentieren, aber prüfen Sie, ob Repository-Sprache, Tests und Abhängigkeiten zu Ihrem Einsatz passen.

Ereignisse für eine prüfbare Ausführungsspur

Eine Agent-Ausführungsspur soll den Lauf rekonstruierbar machen. Sie muss nicht jedes technische Detail in einer unlesbaren Textwand sammeln. Entscheidend ist, dass ein Reviewer die Verbindung zwischen Aufgabe, Werkzeugaktionen, Änderung und Verifikation erkennen kann.

Halten Sie mindestens diese Ereignisgruppen fest:

• Startzustand: Repository-Revision, Arbeitsverzeichnis und für den Lauf gesetzte Umgebungswerte.
• Werkzeugaktionen: Aufgerufene Werkzeuge, Befehle oder externe Schnittstellen sowie deren Rückgaben.
• Änderungen: Welche Dateien verändert wurden und wie sich der Arbeitsstand entwickelte.
• Prüfungen: Gestartete Tests oder statische Prüfungen, ihre Befehle, Ausgaben und Rückgabestatus.
• Fehlerbehandlung: Fehlermeldungen, darauf folgende Änderungen und erneute Prüfungen.
• Abschluss: Der endgültige Arbeitsstand und der Nachweis, welche Prüfung nach der letzten relevanten Änderung erfolgte.

Das öffentliche Dokument zur Protokollierung von SWE-agent-Ausführungsspuren beschreibt eine konkrete Form, Werkzeuginteraktionen für eine spätere Betrachtung festzuhalten. Das ist ein Beispiel für nachvollziehbare Ereignisdokumentation, keine allgemeingültige Qualitätsnorm. Vergleichen Sie Ihre Spur nicht anhand der Anzahl aufgezeichneter Ereignisse. Ein knappes Protokoll kann aussagekräftiger sein als ein umfangreiches, wenn es die entscheidenden Übergänge zwischen Änderung und Prüfung sichtbar macht.

Wichtig: Speichern Sie nur Daten, die für Diagnose und Reproduktion erforderlich sind. Geheimnisse aus Umgebungsvariablen, Zugangsdaten und personenbezogene Informationen gehören nicht ungeschützt in ein Agentenprotokoll.

Prüfen Sie vor der Einführung, wie Protokolle gespeichert, zugänglich gemacht und gelöscht werden. Für den Umgang mit personenbezogenen Informationen können Sie die Datenschutzhinweise von ZekVPS als Ausgangspunkt für Ihre Fragen an den Dienst heranziehen. Maßgeblich bleiben Ihre eigene Datenklassifizierung und die tatsächlich eingesetzten Prozesse.

Übertragung von NeurIPS-Forschung in den Teamablauf

Die offizielle NeurIPS-2026-Downloadseite führt nach dem im Aufgabenbriefing genannten Prüfstand vom 03.10.2026 Einträge mit Bezug zu Software-Engineering-Agenten. Das ist ein Anlass, die zugehörigen Arbeiten zu untersuchen, aber kein allgemeiner Nachweis, dass eine dort beschriebene Methode in jedem Entwicklungsteam zuverlässig funktioniert. Vergleichen Sie vor einer Übernahme den Eintrag mit der offiziellen NeurIPS-2026-Downloadseite, dem verknüpften Preprint und den öffentlich verfügbaren Materialien der Autorinnen und Autoren. Prüfen Sie Version und Inhalt, bevor Sie ein Ergebnis oder eine Methode zitieren.

Wir gehen bei einer internen Übertragung in dieser Reihenfolge vor:

Zuerst die Methode prüfen. Lesen Sie die Arbeit selbst und klären Sie, welche Aufgaben, Agenten, Werkzeuge und Erfolgskriterien untersucht wurden. Eine Aussage aus einem Abstract oder Konferenzverzeichnis allein reicht für eine Reproduktion nicht. Vergleichen Sie den beschriebenen Versuchsaufbau mit dem, was im öffentlichen Code tatsächlich vorhanden ist.

Dann Aufgaben festschreiben. Wählen Sie einen abgegrenzten Bestand eigener Repository-Aufgaben. Halten Sie Ausgangsrevision, Erwartung und Akzeptanzbedingungen fest. Bewahren Sie Aufgaben auf, die nicht erfolgreich waren; ohne sie kann eine spätere Auswertung die Schwierigkeiten systematisch unterschätzen.

Danach die Umgebung isolieren. Sorgen Sie dafür, dass jeder Lauf mit einem bekannten Arbeitsstand beginnt. Begrenzen Sie Netzwerkzugriff und Berechtigungen auf das, was für die Aufgabe erforderlich ist. Container können dabei helfen, Abhängigkeiten und Ausführungsgrenzen zu organisieren. Die Dokumentation zum Ausführen von Containern erläutert die verfügbaren Laufoptionen; sie bestätigt nicht automatisch, dass Ihre konkrete Konfiguration sicher oder reproduzierbar ist. Prüfen Sie diese Bedingungen selbst.

Anschließend Läufe wiederholen. Starten Sie dieselbe Aufgabe mit derselben festgehaltenen Umgebung erneut. Sichern Sie jedes Ergebnis getrennt, statt einen späteren Erfolg über einen vorherigen Fehlschlag zu schreiben. Bei Abweichungen untersuchen Sie zuerst Umgebung, Zufallsquellen und Ausgangszustand, bevor Sie einen Agentenunterschied annehmen.

Zum Schluss Ergebnisse von Spuren trennen und gemeinsam lesen. Erfassen Sie, ob die Akzeptanzbedingung erfüllt wurde, und prüfen Sie unabhängig, wie der Agent dorthin gelangte. Unterscheiden Sie Fehler des Agenten von Fehlern der Aufgabe, der Testinfrastruktur oder der Abhängigkeiten. Diese Trennung macht aus einer bloßen Erfolgszahl eine brauchbare Diagnose.

Eine aufgelistete Forschungsarbeit ist dabei nicht automatisch eine vollständig reproduzierbare Veröffentlichung. Prüfen Sie, ob ein öffentliches Repository die relevante Methode tatsächlich enthält und ob die Version zur Arbeit passt. Dokumentieren Sie Abweichungen, statt sie als nebensächliche Implementierungsdetails zu behandeln.

Reproduktionsbedingungen vor dem Vergleich

Vor einer größeren Auswertung sollten Sie vier Gruppen von Bedingungen abgleichen:

• Abhängigkeiten: Versionen, Installationsquellen und nicht verfügbare Dienste. Ein anderer Paketstand kann das Testergebnis ändern.
• Berechtigungen: Schreibrechte, Netzwerkzugriff und verfügbare Werkzeuge. Ein Agent mit weitergehenden Rechten löst nicht dieselbe Aufgabe unter denselben Bedingungen.
• Zufälligkeit: Zufallsstarts oder andere nicht deterministische Komponenten. Dokumentieren Sie, was Sie kontrollieren können, und kennzeichnen Sie, was sich nicht festsetzen lässt.
• Umgebungszustand: Ausgangsrevision, Arbeitsverzeichnis, Cache-Zustand und vorhandene Dateien. Ein bereits verändertes Verzeichnis ist kein neutraler Startpunkt.

Containerisierung löst diese Fragen nicht von selbst. Sie hilft dabei, die Laufzeitumgebung zu strukturieren; die tatsächlichen Abhängigkeiten, Berechtigungen und Netzwerkregeln müssen trotzdem festgelegt werden. Ebenso beweist ein sauberer Container nicht, dass ein Benchmark-Lauf mit einer wissenschaftlichen Veröffentlichung übereinstimmt. Halten Sie deshalb die Konfiguration und die Abweichungen zur beschriebenen Methode fest.

Wenn die Ergebnisse auseinanderlaufen, fragen Sie nicht nur, ob der Agent „bestanden“ hat. Prüfen Sie, ob derselbe Testbefehl im selben Ausgangszustand lief, ob die letzte Änderung bereits enthalten war und ob ein Fehler der Infrastruktur als Agentenfehler gezählt wurde. Diese Diagnose verhindert, dass Teams Änderungen am Modell vornehmen, obwohl die eigentliche Ursache eine veränderte Abhängigkeit oder ein ungeeigneter Testlauf war.

Häufige Fragen zur Code-Agent-Evaluation

Warum reicht eine hohe Testbestehensquote bei Code-Agenten nicht aus?

Ein Testlauf zeigt zunächst nur, ob ein bestimmter Zustand die ausgeführten Prüfungen bestanden hat. Er sagt nicht automatisch, ob der Agent die passende Änderung vorgenommen, relevante Prüfungen überhaupt gestartet oder durch wiederholte Versuche zufällig einen akzeptierten Zustand erreicht hat. Bewerten Sie deshalb zusätzlich die Änderung, die ausgeführten Werkzeuge, die Fehlerbehandlung und eine unabhängige Abschlussprüfung.

Woran lässt sich eine zuverlässige Reparatur statt eines Zufallstreffers erkennen?

Prüfen Sie, ob die Änderung zum Fehlerbild passt, den betroffenen Bereich nicht unnötig erweitert und die vorgesehenen Prüfungen nachvollziehbar besteht. Wiederholen Sie die Aufgabe mit derselben festgelegten Umgebung und bewahren Sie sowohl erfolgreiche als auch fehlgeschlagene Läufe auf. Ein bestandener Test ohne passende Änderung oder ohne dokumentierte Verifikation ist kein ausreichender Beleg.

Welche Ereignisse gehören in die Ausführungsspur eines Agenten?

Halten Sie Werkzeugaufrufe und deren Ergebnisse, Dateiänderungen, gestartete Tests, Fehlermeldungen, Wiederherstellungsversuche und die abschließende Prüfung fest. Ergänzen Sie Zeitpunkte und den Zustand des Arbeitsverzeichnisses, soweit Ihre Protokollierung das zuverlässig erfasst. Die Spur soll einen Lauf rekonstruierbar machen; eine größere Ereignismenge allein beweist keine bessere Qualität.

Wie lässt sich eine Agenten-Evaluation im eigenen Repository reproduzieren?

Fixieren Sie zunächst konkrete Aufgaben samt Akzeptanzbedingungen und Ausgangsrevision. Dokumentieren Sie Abhängigkeiten, Berechtigungen, Testbefehle und Umgebungsvariablen; starten Sie jeden Lauf mit einem kontrollierten Arbeitsverzeichnis. Bewahren Sie Protokolle und Änderungen auf und wiederholen Sie ausgewählte Aufgaben unter denselben Bedingungen. Vergleichen Sie die Ergebnisse erst, wenn Unterschiede in Umgebung und Startzustand ausgeschlossen sind.

Wann eine gemietete Mac-Umgebung eine sinnvolle Ergänzung ist

Eine vorhandene Entwicklungsmaschine ist bequem, kann aber durch ihren wechselnden Zustand, lokale Abhängigkeiten und gemeinsam genutzte Ressourcen Vergleiche erschweren. Eine allgemeine Cloud-Umgebung kann andere Betriebssystem- oder Hardwarebedingungen als ein lokaler Mac bieten. Gleichzeitig ist ein gemieteter Mac keine automatische Lösung für Linux-spezifische Tests, langfristig gleichbleibende Hochlast oder benötigte physische Schnittstellen. Für diese Fälle sollten Sie die vorhandene Infrastruktur passend zum Zielsystem wählen.

Wenn Ihre Agenten-Auswertung zeitweise eine Apple-Umgebung benötigt, etwa für plattformspezifische Prüfungen, vergleichen Sie zunächst die Anforderungen mit den tatsächlich verfügbaren Angeboten. Auf der ZekVPS-Übersichtsseite können Sie die verfügbaren Umgebungen prüfen und klären, ob sie zu Ihrem isolierten Testablauf passen. Für eine dauerhafte, stark ausgelastete Ausführung oder Tests, die zwingend eine bestimmte physische Ausstattung brauchen, ist eine langfristig kontrollierte eigene Umgebung möglicherweise die passendere Wahl.