38,8 Prozent beträgt die höchste Lösungsrate im neuen Real-SWE Benchmark von Specific Labs. Gemessen wurde nicht an Übungsaufgaben, sondern an privaten Produktionscodebasen, die das Team von echten Unternehmen lizenziert hat. Wer KI-Agenten für die Softwareentwicklung einsetzt, bekommt damit eine der ersten belastbaren Zahlen zu einer Frage, die im Alltag zählt: Wie viel von der Arbeit in einem gewachsenen System bleibt am Ende tatsächlich erledigt?
Die naheliegende Analogie ist der Umbau im bewohnten Haus. Auf der grünen Wiese lässt sich jedes Problem sauber lösen, weil niemand da ist, der etwas Bestehendes verteidigt. In einem Haus, in dem Menschen wohnen, musst du erst die Statik verstehen, dann die Leitungen, die vor zwanzig Jahren jemand anders verlegt hat, und du darfst dabei niemanden ausquartieren. Das unterscheidet einen synthetisch gebauten Coding-Benchmark von dem, was Specific Labs vorlegt. Der Real-SWE Benchmark für Enterprise-Codebasen verschiebt die Prüfung von der grünen Wiese in den Bestand.
Was der Real-SWE Benchmark tatsächlich misst
Jede Aufgabe stammt aus einer privaten Produktionscodebasis, die von einem realen Unternehmen lizenziert wurde. Es sind die Probleme, an denen die dort angestellten Entwickler tatsächlich arbeiten, mit dem gesamten Kontext und der ganzen Komplexität eines bestehenden Produkts. Damit unterscheidet sich das Setup deutlich von dem, was ein Modell aus öffentlichen Repositories kennt: Ein Agent muss sich in proprietären Systemen zurechtfinden, deren Code und Lösungen nirgends im Internet auffindbar sind.
Das zweite Merkmal sind die geschäftlichen Konsequenzen. Es geht um Rechnungsstellung, Steuerberechnung, die Migration von Kundenbeständen, also um Änderungen, die beeinflussen, wie ein Unternehmen operiert, häufig über mehrere Services hinweg. Ein Fehler ist hier kein roter Testfall, sondern eine falsch ausgestellte Rechnung. Und drittens zählt die unternehmensspezifische Komplexität: Jede Firma hat eigene Regeln und einen eigenen Schreibstil, den ein Agent erst verstehen und dann einhalten muss.
Specific Labs nennt drei Codebasen, aus denen die gezeigten Beispielaufgaben stammen: einen Wettbewerber zu Luma und Partiful mit über 200.000 Nutzern und einer Platzierung in den Top 100 des App Store, eine Consumer-Fintech-Plattform, die mehr als 100.000 Bankauszüge verarbeitet, und eine Enterprise-AI-Vertriebsplattform mit komplexen Geschäftsabläufen. Die Auswahl folgte einem Kriterium: Code, der einen echten Nutzerbedarf erfüllt, hat Vorrang vor Code, der nur für einen Benchmark geschrieben wurde. Nach Einschätzung des Teams sind rund 99 Prozent der Tokens in echten Unternehmen für Frontier-Modelle unsichtbar.
Die Rangliste: 38,8 Prozent an der Spitze
Bewertet wurden nicht Modelle isoliert, sondern Kombinationen aus Modell und nativem Harness, also aus Modell und der Werkzeugumgebung, mit der Entwickler in der Praxis arbeiten. Alle Läufe nutzten einen hohen Reasoning-Modus. Die Lösungsrate entspricht pass@1, gemittelt über acht unabhängige Durchläufe pro Aufgabe, mit angegebenen 95-Prozent-Konfidenzintervallen.
| Platz | Modell | Harness | Lösungsrate |
|---|---|---|---|
| 1 | Fable 5.1 | Claude Code | 38,8 % |
| 2 | GPT-6 Astra | Codex CLI | 33,8 % |
| 3 | Grok 4.6 | Grok Build | 32,5 % |
| 4 | Gemini 3.8 Flash | Gemini CLI | 31,2 % |
| 5 | GLM 5.3 | Claude Code | 28,8 % |
| 6 | Muse Spark 1.3 | Muse Code | 23,8 % |
| 7 | Kimi K3 | Kimi Code | 18,8 % |
| 8 | GPT-5.6 Sol | Codex CLI | 16,2 % |
Die Spanne zwischen dem besten und dem schwächsten Ergebnis ist groß. Aussagekräftiger ist etwas anderes: Selbst das führende Gespann löst nicht einmal vier von zehn Aufgaben vollständig. Die Autoren formulieren die Leitfrage offen: Kann ein Coding-Agent die Arbeit eines Software Engineers in der realen Welt übernehmen? Die Zahlen beantworten sie.
Kurze Anweisungen, große Änderungen
Ein wiederkehrendes Missverständnis über Coding-Benchmarks lautet, dass schwierige Aufgaben auch lange Anweisungen brauchen. Real-SWE widerlegt das. Eine typische Instruktion ist im Median 1.742 Zeichen lang. Zum Vergleich nennt das Team 2.056 Zeichen für FrontierCode, 1.975 für DeepSWE, 1.584 für Terminal-Bench 3 und 992 für FrontierSWE v2. Die Prompts sind damit eher knapp gehalten, leicht unterspezifiziert, etwa auf dem Niveau von DeepSWE und Terminal Bench, aber präzise genug, um keine Anforderung stillschweigend auszulassen.
Die eigentliche Arbeit steckt nicht in der Beschreibung, sondern in dem, was zwischen den Zeilen liegt. Jede Anforderung, die der Verifier prüft, muss entweder ausdrücklich genannt oder im Code und in den umgebenden Werkzeugen vernünftig auffindbar sein. Der Agent muss also selbst herausfinden, wo im System er ansetzen kann. Die Referenzlösungen zeigen, wie weit das reicht: Im Median werden elf Dateien geändert, gegenüber sechs bei FrontierCode und DeepSWE.
Zusätzliche Laufzeit verbessert die Bilanz kaum. Von den Durchläufen unter zehn Minuten scheiterten 71,4 Prozent, von den längeren 73,4 Prozent. Zeit ist hier offenbar nicht der begrenzende Faktor. Längere Laufzeiten helfen also nicht, um mehr Aufgaben zu lösen.
Sechs von zehn Beispielaufgaben bleiben unter 15 Prozent
Der Benchmark veröffentlicht eine Stichprobe von zehn Aufgaben mit den jeweiligen Einzelergebnissen über acht Durchläufe pro Modell. Das Bild ist deutlich zweigeteilt. Es gibt Aufgaben, die mehrere Modelle zuverlässig lösen, und es gibt Aufgaben, an denen praktisch alle scheitern.
| Aufgabe | Lösungsrate |
|---|---|
| API keys & environments | 71,9 % |
| Multi-region sweep | 68,8 % |
| Entitlement overage lines | 50,0 % |
| Customer identity migration | 37,5 % |
| Billing schedule migration | 14,1 % |
| API token metering | 12,5 % |
| S3 datastore measurement | 10,9 % |
| Linearizable scan | 10,9 % |
| Tax jurisdiction | 3,1 % |
| Analytics stream reducer | 0,0 % |
Sechs der zehn Aufgaben liegen unter 15 Prozent Lösungsrate, und die letzte wurde in keinem einzigen der achtzig Durchläufe gelöst. Die Steueraufgabe, die Specific Labs vollständig zeigt, macht das deutlich. Die Anweisung beschreibt einen Billing-Service, der ab Montag jede Rechnung ohne Steuer ausstellt. Jedes Unternehmen auf der Plattform regelt seine Steuer anders: Manche pflegen einen eigenen Satz, manche lassen jede Rechnung nach dem Zielort des Käufers durch einen Steuerdienstleister bepreisen, manche erheben gar nichts, und wer eine Freistellung hinterlegt hat, zahlt in jedem Fall nichts.
Die Aufgabe verlangt, dass ein Agent mit einer externen Steuerbehörde kommuniziert, dabei beide Adressen, die bepreisten Positionen und die Produktkategorie mitschickt und je nach Konto zwischen Sandbox und Produktivumgebung unterscheidet. Eine Adresse, die die Behörde ablehnt, muss gemeldet werden, ohne dass die Rechnung hängenbleibt. Satz, Steuer und Bruttobetrag gehören auf die ausgestellte Rechnung, und nach Begleichung wird der Verkauf unter der Rechnungsnummer zurückgemeldet, damit die Steuererklärungen zusammenpassen. Die Umgebung stellt dafür unter anderem TAX_JAR_URL, PROD_TAX_JAR_URL und INFLUX_URL bereit, verbaut sind ein NestJS-Service in TypeScript, TaxJar in Sandbox und Produktion sowie ein Ledger in InfluxDB. Solche Aufgaben lassen sich nicht als Programmierrätsel lösen, sondern verlangen Verständnis der Geschäftslogik.
Wie die KI-Modelle scheitern
Die häufigste Fehlerklasse ist die verpasste Anforderung. Daneben treten ungeprüfte Annahmen, Integrationsfehler, Regressionen und Änderungen in der falschen Datei auf. Die Taxonomie folgt derselben Systematik wie bei DeepSWE, sodass sich die Muster zwischen den Modellen vergleichen lassen. Die Anteile beziehen sich auf die jeweils fehlgeschlagenen Läufe eines Modells, nicht auf alle Läufe.
Verschiedene Modelle scheitern auf unterschiedliche Weise. Das eine bricht sich an fehlender Integration mit den umgebenden Diensten, das andere an stillschweigenden Annahmen über bestehende Geschäftslogik. Kein Modell löst jede Aufgabe, und die Punkteverteilung in der Übersicht zeigt kaum durchgehend grüne Reihen. Nach Einschätzung der Autoren liegt hier die eigentliche Schwäche heutiger Modelle: Sie verstehen unternehmenseigene Programmiermuster nur unzureichend und prüfen ihre Annahmen selten nach.
Was der Benchmark für den Alltag bedeutet
Auch die Kosten sind Teil der Auswertung. Ein einzelner Durchlauf kostet geschätzt zwischen 2,50 und 6,96 US-Dollar, wobei Gemini 3.8 Flash am günstigsten und Fable 5.1 am teuersten liegt. Der Tokenverbrauch pro Aufgabe reicht von rund 23.000 bei GPT-5.6 Sol bis zu 117.000 bei GLM 5.3 und 94.000 bei Gemini 3.8 Flash. Mehr Nachdenken und mehr Explorationsbudget führen also nicht automatisch zu besseren Ergebnissen, wie die Rangliste zeigt.
Methodisch läuft jede Aufgabe in einer isolierten Sandbox. Alle Aufgaben liegen im Harbor-Format vor, und die Verifier werden erst zum Bewertungszeitpunkt eingespielt, damit sie nicht während der Bearbeitung gelesen werden können. Sie orientieren sich an vorhandenen Testsuite-Strukturen der jeweiligen Codebasis oder übernehmen diese sogar unverändert. Der Aufbau ist solide: Bewertet wird, was in einem produktiven System als korrekt gilt, nicht was ein Benchmarkautor für plausibel hält.
Der Real-SWE Benchmark für private Produktionscodebasen liefert eine Größenordnung. Wenn ein Agent vier von zehn Aufgaben ohne Aufsicht löst, ist er ein Werkzeug für erfahrene Entwickler, nicht deren Ersatz. Du planst Prüfaufwand ein, budgetierst für Durchläufe und Nacharbeit und rechnest damit, dass die restlichen sechs Aufgaben jemandem mit Kontextverständnis vorgelegt werden müssen.
Quelle: withspecific.com
