
OpenAI stellt öffentlich einen der am meisten beachteten Coding-Benchmarks der KI-Branche infrage und argumentiert, dass ein erheblicher Teil der Aufgaben in SWE-Bench Pro so fehlerhaft sein könnte, dass Modellvergleiche verzerrt werden. In einer neuen, von OpenAI veröffentlichten Analyse erklärte das Unternehmen, seine Prüfung habe Hinweise darauf gefunden, dass rund 30 % der Aufgaben im Benchmark fehlerhaft sind.
Die Erkenntnis ist über einen einzelnen Datensatz hinaus relevant. Coding-Benchmarks wie SWE-Bench Pro sind zu einer Kurzformel für die Bewertung des Fortschritts in agentischer Softwareentwicklung geworden und prägen Forschungsprioritäten, Launch-Botschaften und in manchen Fällen die Wahrnehmung von Unternehmen, welches Modell sich am besten für Coding-Aufgaben eignet. Der Kernpunkt von OpenAI ist: Wenn die zugrunde liegenden Aufgaben unzuverlässig sind, sagen die Schlagzeilenergebnisse womöglich weniger über die tatsächliche Software-Engineering-Fähigkeit aus, als viele Modellanbieter und Käufer annehmen.
Laut OpenAI begann das Unternehmen mit der Überprüfung von SWE-Bench Pro, nachdem es zuvor zu dem Schluss gekommen war, dass SWE-bench Verified erhebliche Design- und Kontaminationsprobleme aufweist. Damals habe OpenAI die breitere Community dazu ermutigt, zu SWE-Bench Pro als besserem Test für längerfristige, realistischere Coding-Aufgaben überzugehen.
Dieser neuere Benchmark war unter anderem deshalb einflussreich, weil er einen schnellen Fortschritt zu zeigen schien. OpenAI schrieb, dass sich auf dem öffentlichen 731-Aufgaben-Split die Erfolgsquote von Frontier-Modellen innerhalb von acht Monaten von 23,3 % auf 80,3 % verbessert habe. Ein solcher Sprung würde normalerweise auf deutliche Zugewinne bei praktischen Coding-Fähigkeiten hindeuten.
OpenAI argumentiert nun, dass diese Ergebnisse mit mehr Vorsicht zu betrachten seien. In seiner jüngsten Prüfung sagte das Unternehmen, seine interne Datenpunkt-Analyse-Pipeline habe 200 Aufgaben, also 27,4 % des Datensatzes, als fehlerhaft markiert. Eine separate Kampagne zur menschlichen Annotation identifizierte 249 Aufgaben, also 34,1 %, als fehlerhaft. Auf Grundlage dieser Überprüfungen schätzt OpenAI, dass etwa 30 % der SWE-Bench-Pro-Aufgaben fehlerhaft sind.
Die Position des Unternehmens ist nicht, dass jede Aufgabe unbrauchbar sei oder kein Signal mehr übrig bleibe. Stattdessen warnt OpenAI, dass Benchmark-Ergebnisse sorgfältig interpretiert werden sollten, weil ein erheblicher Teil des Tests korrektes Verhalten bestrafen oder unvollständige Korrekturen belohnen könnte.
OpenAIs Analyse unterteilt die Probleme in mehrere Kategorien, die jedem vertraut vorkommen dürften, der mit Evaluierungen gearbeitet hat, insbesondere bei Software-Aufgaben, bei denen versteckte Tests an die Stelle menschlicher Beurteilung treten.
Eine Kategorie sind übermäßig strenge Tests. Laut OpenAI erfordern manche Aufgaben ein sehr spezifisches Implementierungsdetail, das in der Eingabeaufforderung nicht genannt wird. Das bedeutet, ein Modell kann eine funktional richtige Lösung erzeugen und trotzdem durchfallen.
Eine zweite Kategorie sind unzureichend spezifizierte Prompts. In diesen Fällen, so OpenAI, erzwingen versteckte Tests Anforderungen, die sich aus der Aufgabenbeschreibung nicht vernünftig ableiten lassen. Dadurch entsteht eine Diskrepanz zwischen dem, was das Modell tun soll, und dem, wofür es bewertet wird.
Ein drittes Problem sind Tests mit geringer Abdeckung. OpenAI sagte, manche Tests prüften nicht ausreichend, ob die gewünschte Funktion tatsächlich implementiert wurde, sodass teilweise oder unvollständige Korrekturen bestehen könnten. Für Käufer, die KI-Coding-Systeme bewerten, ist das die umgekehrte Fehlerart zu übermäßig strengen Tests: Der Benchmark kann Fähigkeiten überhöhen und nicht nur unterschätzen.
OpenAI verwies außerdem auf irreführende Prompts, die Modelle zu Verhaltensweisen lenken, die später mit den Erwartungen der Tests kollidieren. Das Unternehmen nannte als Beispiel eine Markdown-Formatierung eines Inhaltsverzeichnisses, bei der sich sichtbarer Prompt und versteckte Testfälle durch ein führendes Leerzeichen unterschieden. In einem solchen Szenario könnte ein Modell, das dem Prompt wortgetreu folgt, dennoch als falsch bewertet werden.
Dieses Beispiel trifft den Kern der breiteren Kritik. Viele Softwareprobleme und Pull Requests stammen aus echten Repositories für die Zusammenarbeit von Menschen und nicht als saubere Evaluierungsaufgaben. OpenAI argumentiert, dass beim Umwandeln solcher Artefakte in einen Benchmark Prompt, Referenzpatch und Tests nicht immer gut genug zusammenpassen, um ein verlässliches Scoring zu ermöglichen.
Die stärksten Fakten in dieser Geschichte stammen aus der von OpenAI selbst veröffentlichten Methodik, sind aber dennoch vom Anbieter berichtete Ergebnisse und keine unabhängige Prüfung durch Dritte.
OpenAI sagte, es habe eine Qualitätssicherungspipeline aufgebaut, die Aufgabenanweisungen, Modellversuche, Metadaten und Fehlerprotokolle prüfte, um wahrscheinliche Problemfälle zu identifizieren. Das Unternehmen erklärte, ein erster automatisierter Filter habe 286 potenziell fehlerhafte Aufgaben für eine vertiefte Prüfung markiert.
Von dort aus nutzte OpenAI zwei parallele Prüfpfade. Einer umfasste auf Codex basierende Ermittler-Agenten mit Zugriff auf das Repository und die Laufzeitumgebung, sodass sie Dateien untersuchen, Tests ausführen und Modellfehler analysieren konnten. Der andere war eine Kampagne menschlicher Annotation mit erfahrenen Softwareingenieuren. OpenAI sagte, jede in diesem Prüfprozess markierte Aufgabe sei von fünf Ingenieuren begutachtet worden, wobei Meinungsverschiedenheiten eskaliert wurden.
OpenAI berichtete, dass menschliche Gutachter im Allgemeinen eher als die Agenten-Pipeline dazu neigten, Aufgaben als fehlerhaft einzustufen. Das Unternehmen sagte außerdem, die Übereinstimmung der Kategorien zwischen den Urteilen der Gutachter und der Agenten-Pipeline habe bei den markierten Aufgaben 74 % betragen, und dass bei keiner markierten Aufgabe „nicht fehlerhaft“ das häufigste menschliche Label gewesen sei.
Diese Details stärken das Argument des Unternehmens, dass die Probleme nicht auf vereinzelte Grenzfälle beschränkt sind. Es gibt aber auch Grenzen dessen, was sich aus dem veröffentlichten Material ableiten lässt. Die verfügbaren Quellen enthalten keine externe Stellungnahme der Maintainer von SWE-Bench Pro und auch keinen direkten Neu-Score-Vergleich wichtiger Modelle auf einer reparierten Version des Datensatzes. Daher macht OpenAI zwar einen substantiellen Fall dafür, dass der Benchmark verrauscht ist, doch die genaue Auswirkung auf Modellranglisten bleibt anhand der vorliegenden Belege unklar.
Für KI-Labore besteht die unmittelbare Konsequenz darin, dass Benchmark-Siege beim Coding weniger belastbar sein könnten, als sie aussehen. Wenn fast ein Drittel der Aufgaben Mängel enthält, könnten Lücken auf der Rangliste eher Prompt-Test-Fehlanpassungen, Annahmen bei der Implementierung oder schwache Testabdeckung widerspiegeln als echte Unterschiede in der Modellfähigkeit.
Das ist besonders relevant für Teams, die KI-Agenten für Softwarearbeit entwickeln. SWE-Bench Pro wurde als aussagekräftiger Test für längerfristiges Coding-Verhalten positioniert, näher an dem, was Agentensysteme in der Produktion tun. Wenn seine Aufgaben materiell fehlerhaft sind, brauchen Entwickler breitere Evaluations-Stacks mit repositoriespezifischen Tests, menschlicher Bewertung, Regressionsanalysen und echten Bereitstellungsmetriken statt nur eines öffentlichen Scores.
Für Käufer von Enterprise-KI ist OpenAIs Warnung eine Erinnerung daran, Passraten in Benchmarks nicht mit Produktionsreife gleichzusetzen. Ein Modell, das auf SWE-Bench Pro gut abschneidet, kann in einer echten Codebasis dennoch mit Zuverlässigkeit, Mehrdeutigkeit oder unvollständigen Tests kämpfen. Umgekehrt kann ein Modell, das im Benchmark schwächer erscheint, durch Defekte in den Aufgaben selbst benachteiligt werden.
Auch aus Governance-Sicht ist das relevant. OpenAI verknüpfte die Benchmark-Qualität ausdrücklich mit Sicherheits- und Einsatzentscheidungen im Rahmen seines Preparedness Framework. Das Argument ist einfach: Wenn Evaluierungen Fähigkeiten über- oder unterschätzen, können sie sowohl Produktstartentscheidungen als auch Risikobewertungen verzerren. Das gilt nicht nur für OpenAI und nicht nur für Coding-Benchmarks. Da Modelle zunehmend auf agentisches Verhalten bewertet werden, wird mangelhafte Benchmark-Pflege zu einem strategischen Problem, nicht nur zu einem akademischen.
Bemerkenswert ist auch, wie stark OpenAI auf agentengestützte Audits setzt. Das Unternehmen argumentiert im Grunde, dass dieselbe Klasse von Systemen, die getestet wird, auch dabei helfen kann, die Tests zu debuggen. Ob dieser Ansatz zum Standard wird, hängt davon ab, ob externe Forscher akzeptieren, dass agentenbasierte Prüfungen die Datensatzqualität verbessern können, ohne eine weitere Schicht modellabhängiger Verzerrung einzuführen.
Die zentrale Behauptung in dieser Geschichte ist eine vom Anbieter berichtete: OpenAI sagt, dass etwa 30 % der SWE-Bench-Pro-Aufgaben fehlerhaft sind, basierend auf seinem internen Prüfprozess und einer von ihm organisierten menschlichen Review-Kampagne.
OpenAI berichtet außerdem, dass Frontier-Modelle auf dem öffentlichen 731-Aufgaben-Split des Benchmarks in acht Monaten von 23,3 % auf 80,3 % gestiegen seien. In diesem Artikel sollte diese Zahl als ein von OpenAI zitierter Benchmark-Trend gelesen werden, nicht als unabhängig verifizierte Marktkennzahl.
Die methodischen Details sind konkreter. OpenAI sagt, sein automatischer Filter habe 286 Aufgaben markiert, seine Datenpunkt-Analyse-Pipeline habe 200 Aufgaben als fehlerhaft bewertet, und seine menschliche Annotation-Kampagne habe 249 als fehlerhaft beurteilt. Außerdem heißt es, fünf erfahrene Ingenieure hätten jede markierte Aufgabe geprüft und die Urteile der Gutachter hätten in 74 % der markierten Fälle mit der Agenten-Pipeline übereingestimmt.
Unverifiziert bleibt auf Basis der verfügbaren Belege, wie die Maintainer des Benchmarks oder andere Labore dieselben Aufgaben einstufen würden, ob reparierte Aufgaben die Modellranglisten deutlich neu ordnen würden und ob bei benachbarten Coding-Benchmarks neben SWE-bench Verified und SWE-Bench Pro ähnliche Fehlerraten auftreten.
Das erste Signal, auf das man achten sollte, ist, ob die Maintainer von SWE-Bench Pro eine Antwort, einen überarbeiteten Datensatz oder eine formelle Gegenargumentation veröffentlichen. Falls sie einem erheblichen Teil von OpenAIs Befunden zustimmen, könnte der Benchmark rasch aktualisiert werden. Falls sie die Schlussfolgerungen bestreiten, könnte die Branche ein unabhängiges Schiedsverfahren benötigen.
Zweitens sollte beobachtet werden, ob große Labore ändern, wie sie Coding-Performance berichten. Wenn künftige Modellstarts SWE-Bench Pro weniger betonen und mehr auf private Evaluations-Suiten, Tests auf Repository-Ebene oder Studien zur Aufgabenerledigung setzen, würde das auf sinkendes Vertrauen in öffentliche Coding-Ranglisten hindeuten.
Drittens ist zu beobachten, ob OpenAI mehr Werkzeuge oder Methodik zum Benchmark-Audit mit Codex oder ähnlichen Ermittler-Agenten veröffentlicht. Eine reproduzierbare Audit-Pipeline könnte beeinflussen, wie die Branche nicht nur Coding-Datensätze, sondern auch Evaluierungen für KI-Agenten insgesamt validiert.
Schließlich stellt sich die größere Frage, ob Benchmark-Inflation inzwischen ein wiederkehrendes Muster in schnelllebigen Modellkategorien ist. OpenAI hat zuvor SWE-bench Verified kritisiert und wirft nun Probleme mit SWE-Bench Pro auf. Wenn die nächste Generation von Coding-Evaluierungen auf ähnliche Schwierigkeiten stößt, könnte sich der Markt in Richtung gemischter Belege verschieben: öffentliche Benchmarks, Kundentelemetrie und kontrollierte Tests realer Arbeitsabläufe statt einzelner Zahlenrankings.
OpenAIs Analyse ist weniger deshalb wichtig, weil sie einen einzelnen Benchmark angreift, sondern weil sie ein strukturelles Problem der KI-Messung offenlegt. Die Branche will saubere, vergleichbare Zahlen für Coding-Modelle, aber Softwareaufgaben sind chaotisch. Wenn Prompts, versteckte Tests und Referenz-Patches aus echten Repositories stammen, können kleine Inkonsistenzen die Bewertung still und leise in Rauschen verwandeln. Das ist ein Problem für Entwickler, die Modelle optimieren wollen, und für Unternehmen, die mit Vertrauen kaufen möchten.
Die praktische Lehre ist nicht, SWE-Bench Pro, SWE-bench Verified oder andere öffentliche Benchmarks nicht mehr zu nutzen. Vielmehr sollten sie von endgültigen Urteilen zu Richtungsindikatoren herabgestuft werden. Für Teams, die KI-Agenten ausliefern, gehört Benchmark-Kompetenz inzwischen zur Produktarbeit: verstehen, was ein Score tatsächlich misst, was er verfehlt und wie fragil er sein kann. Die Labore, die im Coding Vertrauen gewinnen, werden diejenigen sein, die starke öffentliche Ergebnisse mit transparenter Evaluierungsplanung, realen Arbeitsablaufnachweisen und der Bereitschaft verbinden, ihre eigenen Messlatten zu überprüfen.