SWE-bench-Werte: Die Lücke zwischen bestandenen Tests und fertiger Software

Titelbild: KI-generierte redaktionelle Illustration einer kleinen Prüfvorrichtung neben einem größeren Produktionssystem. Das Motiv veranschaulicht einen Vergleich und ist kein Nachweis für die Korrektheit eines Patches.

Kurzfassung: SWE-bench begann mit 2.294 Aufgaben aus zwölf Python-Repositorien; Verified wählte später 500 menschlich geprüfte Aufgaben aus.^[1][2] OpenAIs Prüfung vom 23. Februar 2026 fand wesentliche Probleme in 59,4% von 138 gezielt ausgewählten, häufig misslungenen Aufgaben, nicht in 59,4% des gesamten Benchmarks.^[3] Ein Programmierwert belegt Leistung für eine Aufgabensammlung, einen Prüfer und eine Agentenkonfiguration, nicht den direkt automatisierbaren Anteil einer Softwareabteilung.

Die Programmierrangliste ist ein Vertriebskanal. Ein einzelner Prozentwert lässt sich leicht in einer Produkteinführung, einer Beschaffungspräsentation und einem Entwicklergespräch verbreiten. Der zugrunde liegende Vertrag reist weniger bequem mit: Welche Aufgaben, welche Umgebung, wie viele Versuche und was akzeptieren die Tests tatsächlich?

Diese Analyse greift das ursprüngliche SWE-bench vom Oktober 2023, die Verified-Veröffentlichung vom August 2024 und spätere Bewertungsarbeiten auf. Sie ordnet keine aktuellen Programmiermodelle vom November 2026 ein. Wirtschaftlich geht es darum, Benchmarkbelege in eine Kaufentscheidung zu übersetzen, ohne stillschweigend die Bedeutung der Zahl zu verändern.

Der Nenner: Fünfhundert Aufgaben sind eine definierte Population

SWE-bench verbindet Fehlerbeschreibungen mit Repository-Zuständen und bewertet vorgeschlagene Änderungen anhand von Tests. Die ursprüngliche Population umfasste 2.294 Probleme aus zwölf Python-Repositorien.^[1] Das war ein erheblicher Fortschritt gegenüber der Erzeugung einer isolierten Funktion. Es bleibt eine bestimmte Population, nicht die Gesamtheit des Softwareberufs.

Die Verified-Teilmenge mit 500 Aufgaben erschien am 13. August 2024 nach menschlicher Prüfung, die Aufgabenbeschreibungen und Testgültigkeit verbessern sollte.^[2] Filtern verändert den Nenner und die Arbeitsmischung. Ein Prozentwert auf Full, Lite oder Verified ist deshalb eine andere Messung, auch wenn der Modellname gleich bleibt.

Bei einer beispielhaften Bewertung mit 500 Aufgaben bewegt eine zusätzlich gelöste Aufgabe den Wert um 0,2 Prozentpunkte. Die Rechnung ist exakt; ihre Bedeutung braucht weitere Informationen. Ein Zuwachs von zwei Punkten kann zehn zusätzliche Erfolge in einer einzigen Bibliothek oder Verbesserungen über viele Repositorien hinweg bedeuten. Käufer mit anderen Sprachen und Aufgaben sollten nicht annehmen, dass eines dieser Muster übertragbar ist.

Praktisch sollten sie Ergebnisse auf Aufgabenebene, Fehlerkategorien und ein stabiles Auswertungsmanifest verlangen. Ein Vergleich wird deutlich nützlicher, wenn erkennbar ist, welche Probleme sich verändert haben. Der Gesamtwert ist keine dauerhaft am Modell haftende Eigenschaft.

Der Prüfer: Bestandene Tests belegen eine bestimmte Eigenschaft

Die Verified-Veröffentlichung erläutert zwei Prüfungen: Tests, die zunächst fehlschlagen und nach der Korrektur bestehen sollen, sowie Tests, die weiterhin bestehen müssen.^[2] Gemeinsam prüfen sie das gewünschte Verhalten und einen Teil möglicher Regressionen. Sie belegen nicht jede Eigenschaft, die einer Entwicklungsorganisation wichtig ist, etwa Wartbarkeit oder Kompatibilität außerhalb der getesteten Umgebung.

OpenAIs Prüfung vom Februar 2026 untersuchte 138 Aufgaben, die das Modell o3 in 64 Durchläufen nicht durchgehend löste. Das Unternehmen meldete fehlerhafte Tests oder Beschreibungen bei 59,4% dieser nach Misserfolgen ausgewählten Gruppe. OpenAI ist zugleich berichtender Anbieter und Teilnehmer am Modellwettbewerb. Das ist seine Prüfung, keine unabhängig reproduzierte Vollerhebung.^[3]

Vom Anbieter gemeldete Prüfung

Problemkategorien in OpenAIs ausgewählter Prüfung von 138 Aufgaben

Von OpenAI am 23. Februar 2026 gemeldete Anteile. Ausgewählt wurden Aufgaben, die o3 nicht durchgehend löste, keine Zufallsstichprobe aus allen 500 Verified-Aufgaben.

Tests erzwingen nicht spezifizierte Implementierungsdetails

35,5%

Tests verlangen zusätzliche, nicht spezifizierte Funktionen

18,8%

Andere wesentliche Probleme

5,1%

0%Anteil der 138 geprüften Aufgaben100%

Quelle: OpenAIs eigene Prüfung, hier nicht unabhängig repliziert. Die gemeldeten gerundeten Kategorien summieren sich auf 59,4%. Die Auswahl nach wiederholten Modellfehlern erlaubt keine Hochrechnung auf den vollständigen Benchmark oder andere Modelle.

Die eigentliche Geschichte lautet nicht, dass sämtliche Tests unbrauchbar sind. Ein Prüfer besitzt eine Spezifikation, und diese muss gepflegt werden. Ein eng formulierter Test kann eine zulässige Implementierung ablehnen. Eine großzügige Testsammlung kann einen Fehler übersehen. Beides rechtfertigt nicht, Tests durch subjektive Eindrücke zu ersetzen. Es verlangt unabhängige Prüfungen folgenreicher Behauptungen.

Die Ausführungsumgebung: Ein Wert gehört zum Gesamtsystem

Die SWE-agent-Forschung vom Mai 2024 machte Schnittstellengestaltung zum Teil des Untersuchungsgegenstands. Werkzeuge für Navigation, Bearbeitung und Ausführung beeinflussen, wie wirksam ein Sprachmodell in einem Repository arbeiten kann.^[4] Das Modell ist eine wichtige Komponente. Der Wert eines Agentensystems misst aber nicht allein dessen Gewichte.

Ein reproduzierbarer Vergleich braucht dieselbe Datensatzrevision, Aufgabenkennungen, Basis-Commits, Container-Abbilder, Agentenversion, Werkzeugberechtigungen, Versuchspolitik und Ressourcenbudgets. Er sollte ausgeschlossene Aufgaben, leere Patches und Infrastrukturfehler offenlegen sowie angeben, ob ein Einzelversuch oder eine Auswahl aus mehreren Kandidaten gemeldet wird. Dieser Artikel vergleicht keine Inferenzgeschwindigkeit, weil diese Bedingungen hier nicht vereinheitlicht sind.

Die FAQ der Verantwortlichen unterscheiden eingereichte, abgeschlossene und gelöste Aufgaben sowie Fehlerzahlen. Sie warnen außerdem, dass wiederverwendete Durchlaufkennungen zwischengespeicherte Ergebnisse liefern können, obwohl sich ein vorgeschlagener Patch verändert hat.^[8] Dieses Betriebsdetail verdeutlicht das größere Problem: Ein Bewertungsergebnis hängt neben Modellverhalten auch von sauberer Ausführungsverwaltung ab. Käufer brauchen den Prüfpfad, nicht nur einen Screenshot.

Aktualität: Expositionsrisiken senken, ohne Vergleichbarkeit zu erfinden

SWE-rebench, erstmals im Mai 2025 eingereicht, beschreibt die fortlaufende Sammlung neuer Repository-Aufgaben gegen das Expositionsrisiko statischer öffentlicher Benchmarks.^[5] Das ist sinnvoll, weil eine öffentliche Fehlermeldung und ihre spätere menschliche Korrektur in Trainingsdaten gelangen können. Aktualität senkt eine Unsicherheit. Sie macht Aufgaben nicht automatisch eindeutig oder Prüfer vollständig.

LiveCodeBench vom März 2024 verwendet neu gesammelte Wettbewerbsaufgaben und bewertet mehrere Programmierfähigkeiten.^[6] Das schafft einen weiteren Zugang zur Untersuchung von Vorwissen. Wettbewerbsprogrammierung und Repository-Wartung sind jedoch verschiedene Tätigkeiten. Ein niedrigerer Wert auf einem frischeren Test ist für sich genommen kein gemessener Kontaminationseffekt. Auch Schwierigkeit und Abdeckung können sich verändert haben.

Die ursprüngliche SWE-Bench-Pro-Arbeit vom September 2025 erweitert Repository- und Aufgabenabdeckung, einschließlich zurückgehaltener und kommerzieller Umgebungen.^[7] Sie bestärkt ein sinnvolles Bewertungsportfolio: mehrere relevante Populationen testen, ihre jeweiligen Grenzen bewahren und keine universelle Rangliste aus unvereinbaren Aufgabensammlungen ableiten. Ein Benchmarkname ohne Revision reicht für einen ernsthaften Vergleich nicht aus.

Beschaffung: Überprüfte Arbeit zu bekannten Prüfkosten kaufen

Ein nützlicher lokaler Pilot beginnt mit aktuellen, repräsentativen Aufgaben, gegen die der Anbieter möglichst weder trainiert noch optimiert hat. Die Abnahmekriterien müssen unabhängig vom erzeugten Patch bleiben. Erfasst werden Bearbeitungszeit, Prüfzeit, Aufgabenabschluss, Regressionen und Kosten erfolgloser Versuche. Dazu gehören schwierige Fälle, die ein Team sonst aus einer attraktiveren Demonstration weglassen könnte.

Entwickler sollten auch prüfen, wie der Agent mit Unsicherheit umgeht. Erkennt er fehlende Anforderungen, bewahrt er unabhängiges Verhalten und meldet er einen nicht ausführbaren Test? Das sind betriebliche Ergebnisse. Sie gehören neben die Lösungsquote, weil sie bestimmen, ob Prüfung schneller wird oder sich nur in eine andere Phase verlagert.

Klar ist: Softwarebenchmarks haben Programmierfortschritt messbarer gemacht. Ihr strategischer Wert steigt, wenn Anbieter die Entstehungsbedingungen offenlegen und Käufer den Zusammenhang mit der eigenen Arbeit testen. Das bezahlenswerte Produkt ist eine Änderung, die die Prüfung zu vorhersehbaren Kosten besteht.

Quellen: Studien und Methodik

Zuletzt aktualisiert: 9. November 2026