24 Prozent und trotzdem gescheitert: Was Opus 5 im SlopCodeBench wirklich zeigt

Die üblichen Benchmarks für Coding-Modelle folgen einem recht übersichtlichen Muster: Das Modell bekommt einen Fehlerbericht, einen Ausschnitt aus einem Repository und soll daraus einen Patch erzeugen. Am Ende zählt, ob die Tests grün sind.

Das ist nützlich, bildet aber nur einen kleinen Ausschnitt von Softwareentwicklung ab. In realen Projekten endet die Arbeit nicht nach dem ersten erfolgreichen Patch. Anforderungen ändern sich, weitere Funktionen kommen hinzu und frühere Entscheidungen müssen weitergetragen werden. Der Code, den man heute schreibt, ist morgen der Legacy-Code, mit dem man leben muss.

Genau an dieser Stelle setzt SlopCodeBench an. Der Benchmark prüft nicht nur, ob ein Coding-Agent eine einzelne Aufgabe lösen kann. Er prüft, wie sich eine Codebasis über mehrere aufeinanderfolgende Änderungen entwickelt. Neue Anforderungen bauen auf dem zuvor erzeugten Stand auf. Fehler, unnötige Abstraktionen und schlechte Architektur verschwinden nicht beim nächsten Prompt, sondern werden Teil des Problems.

Kurz nach der Veröffentlichung von Claude Opus 5 wurde ein erster unabhängiger Lauf mit SlopCodeBench veröffentlicht. Das Ergebnis klingt zunächst beeindruckend: Opus 5 erreichte eine Strict-Pass-Rate von rund 24 Prozent. Opus 4.8 und Sonnet 5 kamen jeweils nur auf etwa 6 Prozent. (Anthropic)

Die Zahl ist interessant. Sie ist aber deutlich weniger eindeutig, als es die Prozentwerte vermuten lassen.

Ein Benchmark für den zweiten, dritten und achten Prompt

Die aktuelle Version von SlopCodeBench besteht aus 36 Problemen mit insgesamt 196 Checkpoints. Jedes Problem beschreibt eine Software, die schrittweise weiterentwickelt wird. Ein Problem kann beispielsweise mit einem einfachen Parser, einer Datenbankmigration oder einer kleinen Auswertungsengine beginnen. In späteren Checkpoints kommen neue Anforderungen, Sonderfälle und Änderungen am bestehenden Verhalten hinzu.

Der Agent bekommt an jedem Checkpoint eine frische Aufgabenbeschreibung und die Codebasis, die er am vorherigen Checkpoint hinterlassen hat. Den bisherigen Chatverlauf bekommt er dagegen nicht. Architekturentscheidungen bleiben also im Repository erhalten, ihre Begründung jedoch nicht. Das entspricht ziemlich genau der Situation, in der ein Coding-Agent eine neue Session startet und ein bestehendes Ticket übernimmt. (arXiv)

Die Tests sind verborgen. Der Agent kennt die Spezifikation, aber weder die erwartete interne Architektur noch die Testfälle. Dadurch kann er die Implementierung selbst wählen. Gleichzeitig lässt sich das Ergebnis nicht einfach auf sichtbare Tests optimieren.

SlopCodeBench unterscheidet mehrere Erfolgsmaße:

Core Pass prüft, ob das ausdrücklich beschriebene Kernverhalten funktioniert.

Isolated Pass prüft alle Tests des aktuellen Checkpoints, ignoriert aber Regressionen aus früheren Checkpoints.

Strict Pass verlangt, dass sowohl die aktuelle Änderung als auch alle bisherigen Anforderungen weiterhin funktionieren.

Diese Unterscheidung ist entscheidend. Ein Agent kann eine neue Funktion korrekt implementieren und trotzdem einen Strict Pass verlieren, weil er dabei etwas aus einem früheren Schritt beschädigt hat. Der Strict-Wert misst deshalb nicht nur die Fähigkeit, Code zu erzeugen. Er misst, ob der Agent eine wachsende Codebasis kontrolliert weiterentwickeln kann. (arXiv)

Jeder Checkpoint läuft in einem frischen Docker-Container unter einem nicht privilegierten Benutzer. Die Agenten dürfen bis zu zwei Stunden arbeiten. Es gibt keine künstliche Begrenzung der Zahl von Tool-Aufrufen oder der Kosten. Als Prompt wird bewusst eine schlichte Aufforderung verwendet, die Aufgabe zu lösen. Der Benchmark testet damit eher einen autonom arbeitenden Agenten als eine sorgfältig moderierte Pair-Programming-Session. (arXiv)

Der Opus-5-Lauf

Der bisher veröffentlichte Opus-5-Lauf umfasst nicht den vollständigen Benchmark. Getestet wurden drei ausgewählte Probleme mit insgesamt 17 Checkpoints. Die Auswahl enthielt ein leichtes, ein mittleres und ein schwieriges Problem. Verglichen wurden Opus 5, Opus 4.8 und Sonnet 5. Alle Modelle liefen mit denselben Prompts und demselben Claude-Code-Harness. Für jedes Modell und jedes Problem gab es einen vollständigen Lauf. (selinyilmaz.dev)

Modell	Strict bestandene Checkpoints	Strict-Pass-Rate	Vollständig gelöste Probleme
Claude Opus 5	4 von 17	23,5 %	0 von 3
Claude Opus 4.8	1 von 17	5,9 %	0 von 3
Claude Sonnet 5	1 von 17	5,9 %	0 von 3

Opus 5 liegt in diesem Lauf klar vorne. Es besteht viermal so viele Checkpoints wie die beiden anderen Modelle. Gleichzeitig ist die aussagekräftigste Zahl in der Tabelle nicht 23,5 Prozent, sondern null: Keines der drei Modelle bringt auch nur eines der Probleme ohne zwischenzeitliche Fehler und Regressionen vollständig bis zum Ende. (selinyilmaz.dev)

Drei der vier erfolgreichen Opus-5-Checkpoints stammen aus den ersten drei Schritten desselben Problems. Der vierte Erfolg ist der erste Checkpoint einer Datenbankmigration. Sobald die Aufgaben länger werden und die Auswirkungen früherer Entscheidungen zunehmen, bricht auch bei Opus 5 die Strict-Serie ab.

Bei nur 17 Checkpoints verändert ein einziger bestandener Checkpoint das Ergebnis um 5,9 Prozentpunkte. Der Unterschied zwischen 24 und 6 Prozent besteht somit aus genau drei zusätzlichen erfolgreichen Checkpoints. Hinzu kommt, dass die Checkpoints nicht statistisch unabhängig sind. Wer in einem frühen Schritt eine ungünstige Architektur wählt oder einen Defekt einbaut, startet beim nächsten Schritt bereits mit einem Nachteil.

Der Lauf ist deshalb ein starkes Indiz dafür, dass Opus 5 in diesem Szenario besser mit einer wachsenden Codebasis umgehen kann als Opus 4.8 und Sonnet 5. Für die Aussage, Opus 5 erreiche generell eine SlopCodeBench-Leistung von 24 Prozent, ist die Stichprobe jedoch zu klein.

Die 24 Prozent sind kein neuer offizieller Spitzenwert

In der Diskussion um den Opus-5-Lauf taucht häufig ein Vergleich mit einem bisherigen Spitzenwert von ungefähr 17 Prozent auf. Dieser Wert stammt aus der ersten Version des SlopCodeBench-Papers. Damals umfasste der Benchmark 20 Probleme mit 93 Checkpoints. Opus 4.6 erreichte darin 17,2 Prozent Strict Pass.

Die im Mai 2026 überarbeitete Version wurde auf 36 Probleme und 196 Checkpoints erweitert. Damit wurden auch die veröffentlichten Modellwerte neu berechnet. Opus 4.6 erreicht in der aktuellen Version nicht mehr 17,2, sondern 9,7 Prozent. Der beste offizielle Wert stammt derzeit von GPT-5.5 mit 14,8 Prozent. (arXiv)

Das ist kein Widerspruch, sondern ein Beispiel dafür, wie stark ein Benchmark-Ergebnis von der verwendeten Version und der Auswahl der Aufgaben abhängt.

Der Opus-5-Wert von 23,5 Prozent stammt aus einem unabhängigen Lauf über 17 Checkpoints. Die offiziellen Werte stammen aus 196 Checkpoints. Man kann die Ergebnisse nebeneinanderstellen, aber nicht als gemeinsame Rangliste behandeln.

Die offiziellen Ergebnisse anderer Modelle

Die folgende Tabelle zeigt eine Auswahl der Ergebnisse aus der aktuellen zweiten Version des Papers. Opus 5, Opus 4.8 und Sonnet 5 sind dort noch nicht enthalten.

Modell	Strict	Isolated	Core	Kosten pro Checkpoint	Erosion	Verbosity
GPT-5.5	14,8 %	28,1 %	66,8 %	1,51 US-Dollar	0,49	0,32
GPT-5.3 Codex	11,2 %	26,0 %	60,7 %	0,66 US-Dollar	0,64	0,46
GPT-5.4	10,7 %	23,5 %	62,8 %	0,72 US-Dollar	0,51	0,33
Kimi K2.6	10,7 %	18,9 %	51,0 %	0,74 US-Dollar	0,76	0,51
GPT-5.2 Codex	9,7 %	21,9 %	56,1 %	0,85 US-Dollar	0,73	0,50
Claude Opus 4.6	9,7 %	20,9 %	67,3 %	3,17 US-Dollar	0,75	0,44
Claude Opus 4.7	8,2 %	20,9 %	65,8 %	2,17 US-Dollar	0,76	0,48
Claude Sonnet 4.6	7,1 %	16,8 %	57,7 %	1,96 US-Dollar	0,75	0,44
Composer 2	6,1 %	16,3 %	52,6 %	0,44 US-Dollar	0,72	0,45
MiniMax M2.7	2,0 %	4,1 %	28,1 %	0,34 US-Dollar	0,73	0,47

Bei Erosion und Verbosity sind niedrigere Werte besser. Die Kosten beziehen sich auf den veröffentlichten durchschnittlichen Modellverbrauch pro Checkpoint. Die Modelle wurden über ihre jeweiligen nativen Agenten-Harnesses ausgeführt. (arXiv)

Auch beim besten Modell wird kein einziges der 36 Probleme vollständig gelöst. GPT-5.5 erreicht zwar 14,8 Prozent Strict Pass, kommt beim Core-Wert aber auf 66,8 Prozent. Das Modell kann also einen großen Teil des unmittelbar beschriebenen Verhaltens umsetzen. Es scheitert wesentlich häufiger, sobald Fehlerfälle, versteckte Anforderungen und Regressionen hinzukommen. (arXiv)

Dieser Abstand ist für mich eine der interessantesten Aussagen des gesamten Benchmarks. Coding-Agenten sind inzwischen ziemlich gut darin, eine Funktion so aussehen zu lassen, als sei sie fertig. Sie sind deutlich schlechter darin, dafür zu sorgen, dass die gesamte Anwendung anschließend noch stimmt.

Warum der Strict-Wert so niedrig ist

Ein Strict Pass ist absichtlich schwer zu erreichen. Ein Fehler aus Checkpoint zwei kann dazu führen, dass auch die Checkpoints drei bis acht nicht mehr vollständig bestehen, obwohl die später hinzugekommenen Funktionen für sich genommen funktionieren.

Das kann man als unfair empfinden. Für autonome Softwarewartung ist es aber genau die richtige Härte. In einem echten Repository verschwindet eine Regression ebenfalls nicht, nur weil der Agent später andere Funktionen korrekt implementiert.

Der Isolated-Wert hilft dabei, beide Effekte auseinanderzuhalten. GPT-5.5 erreicht beispielsweise 28,1 Prozent Isolated Pass, aber nur 14,8 Prozent Strict Pass. GPT-5.3 Codex kommt auf 26,0 beziehungsweise 11,2 Prozent. Ein erheblicher Teil der aktuellen Änderungen funktioniert also isoliert, scheitert jedoch im Gesamtverlauf.

Damit misst SlopCodeBench zwei unterschiedliche Dinge:

Zum einen die unmittelbare Implementierungsleistung des Modells. Dafür sind Core und Isolated hilfreich.

Zum anderen die Stabilität einer Entwicklungstrajektorie. Dafür ist Strict entscheidend.

Wer wissen möchte, ob ein Agent nach einem klar formulierten Auftrag brauchbaren Code erzeugen kann, sollte nicht ausschließlich auf Strict schauen. Wer den Agenten mehrere Tickets unbeaufsichtigt hintereinander bearbeiten lassen möchte, sollte dagegen genau diesen Wert ernst nehmen.

Was mit „Slop“ überhaupt gemeint ist

SlopCodeBench bewertet nicht nur die Tests. Der Benchmark verfolgt auch, wie sich der erzeugte Code verändert.

Die sogenannte Structural Erosion misst, wie viel der strukturellen Komplexität in besonders komplexen Funktionen konzentriert ist. Dafür werden unter anderem die zyklomatische Komplexität und die Größe der Funktionen kombiniert.

Verbosity misst auffällige Codezeilen, die durch 137 statische AST-Regeln oder durch Duplikation erkannt werden. Dazu gehören beispielsweise unnötige Wrapper, redundante Prüfungen, wiederholte Logik und andere Muster, die den Code aufblähen können. (arXiv)

Über alle offiziellen Läufe hinweg steigt die strukturelle Erosion in 77 Prozent der Entwicklungstrajektorien. Die Verbosity nimmt in 75,5 Prozent zu. Die durchschnittliche Zahl besonders komplexer Funktionen wächst von 3,6 am Anfang auf 23,7 am Ende. Die Code-Duplikation steigt im Verlauf im Mittel um 96 Prozent. (arXiv)

Als Vergleich untersuchten die Autoren 473 öffentliche Python-Repositories. Der von Agenten erzeugte Code war nach ihren Metriken im Mittel 2,3-mal so verbose und 2,0-mal so stark erodiert wie die Vergleichsprojekte. Die Autoren weisen allerdings selbst darauf hin, dass dies kein kontrollierter Vergleich zwischen Mensch und Maschine ist. Öffentliche Repositories entstehen unter völlig anderen Bedingungen, mit Code-Reviews, Refactorings, wechselnden Anforderungen und zum Teil vielen Jahren Entwicklungszeit. Die Zahlen dienen eher als Kalibrierung der Metriken. (arXiv)

Opus 5 schreibt deutlich mehr Code

Im kleinen Opus-5-Lauf fällt auf, dass das Modell erheblich mehr Funktionen erzeugt als Opus 4.8 und Sonnet 5. Über alle analysierten Artefakte hinweg waren es ungefähr fünfmal so viele Funktionen. Betrachtet man nur den eigentlichen Produktionscode und nicht die zusätzlich geschriebenen Tests, lag das Volumen ungefähr beim 1,8-Fachen von Opus 4.8. (selinyilmaz.dev)

Das lässt sich nicht eindeutig als Stärke oder Schwäche interpretieren.

Viele kleine Funktionen können das Ergebnis einer sauberen Zerlegung sein. Sie können aber ebenso aus übermäßiger Abstraktion, unnötigen Hilfsfunktionen und defensivem Code entstehen. Opus 5 hatte in dem Lauf die niedrigste durchschnittliche Komplexität pro Funktion und hielt die Duplikation weitgehend stabil. Opus 4.8 erzeugte weniger Funktionen, ließ dafür aber sowohl die Komplexität als auch die Duplikation deutlich stärker anwachsen. (selinyilmaz.dev)

Die Aussage „Opus 5 produziert fünfmal mehr Slop“ wäre deshalb genauso unseriös wie „Opus 5 schreibt fünfmal besser strukturierten Code“. Ohne eine qualitative Betrachtung der Architektur sagt die Zahl der Funktionen wenig aus.

Das gilt auch für die Verbosity-Metrik. Im Opus-5-Lauf wurden teilweise bereits am ersten Checkpoint ungefähr 65 Prozent und später bis zu 80 Prozent der Zeilen markiert. Solche Werte sprechen dafür, dass die Regeln sehr aggressiv anschlagen und nicht jede markierte Zeile tatsächlich schlechten Code darstellt. Die Autoren des Laufs weisen selbst darauf hin, dass diese Metriken Hinweise liefern, aber keine belastbare Messung von Wartbarkeit ersetzen. (selinyilmaz.dev)

Die Qualitätsmetriken sind interessant, aber keine Naturgesetze

Zyklomatische Komplexität, Zeilenzahl, Duplikation und AST-Regeln haben einen großen Vorteil: Sie sind deterministisch. Anders als bei einem LLM-as-a-Judge entscheidet nicht noch ein weiteres Sprachmodell, ob der Code „schön“ oder „wartbar“ aussieht.

Dadurch werden die Metriken aber nicht automatisch objektiv.

Eine lange Funktion kann problematisch sein. Sie kann aber auch eine lineare, gut lesbare Folge von Verarbeitungsschritten enthalten. Viele kleine Funktionen können eine klare Architektur bilden oder einen einfachen Ablauf über mehrere Dateien verteilen. Zusätzliche Fehlerprüfungen können redundant sein oder genau die Robustheit liefern, die in der Spezifikation fehlt.

Das Paper untersucht selbst, wie gut seine Erosion-Metrik spätere Ergebnisse vorhersagt. Die Korrelation mit dem Bestehen des nächsten Checkpoints liegt nahezu bei null. Die gesamte Codegröße und die maximale Komplexität einzelner Funktionen hängen stärker mit späteren Kosten zusammen als der zusammengesetzte Erosion-Wert. (arXiv)

Für mich bedeutet das nicht, dass die Qualitätsmessung nutzlos ist. Sie sollte nur als Warnsignal gelesen werden und nicht als automatische Bewertung einer Architektur. Der stärkste Indikator bleibt weiterhin, ob die Software ihre Anforderungen erfüllt, bestehendes Verhalten bewahrt und mit vertretbarem Aufwand erweitert werden kann.

Ein besserer Prompt löst das Problem nicht

Die Autoren haben zusätzlich untersucht, ob sich der Verfall mit strengeren Prompts verhindern lässt. Dafür wurden unter anderem eine Anti-Slop-Anweisung und ein Plan-first-Prompt getestet.

Beide Varianten verbesserten die gemessene Codequalität. Erosion und Verbosity gingen zurück. Gleichzeitig sank jedoch die durchschnittliche Strict-Pass-Rate. Beim Anti-Slop-Prompt fiel sie um 2,4 Prozentpunkte, beim Plan-first-Prompt um 3,6 Prozentpunkte. Die Kosten stiegen im Mittel um 12,1 Prozent. Bei GPT-5.5 sank der Strict-Wert von 14,8 Prozent mit dem einfachen Prompt auf 9,2 beziehungsweise 8,2 Prozent. (arXiv)

Das ist ein bekanntes Problem aus der Arbeit mit Coding-Agenten. Zusätzliche Regeln konkurrieren um Aufmerksamkeit. Wer das Modell zwingt, ständig über Abstraktionen, Duplikation, Funktionsgrößen und Architektur nachzudenken, bekommt möglicherweise schöneren Code, aber nicht automatisch mehr funktionierende Software.

Ein langer Prompt mit zwanzig Qualitätsregeln ersetzt keinen Entwicklungsprozess.

Was SlopCodeBench nicht misst

SlopCodeBench ist kein allgemeingültiges Urteil darüber, welches Modell der beste Programmierer ist.

Der Benchmark misst einen relativ speziellen, aber wichtigen Anwendungsfall: Ein Agent erhält nacheinander Anforderungen, arbeitet weitgehend autonom, kennt die versteckten Tests nicht und muss mit dem eigenen früheren Code weiterarbeiten.

So sehen viele reale Coding-Sessions nicht aus. In einem gut geführten Projekt gibt es Rückfragen, Architekturentscheidungen, Code-Reviews, CI-Feedback und eine Person, die nach jedem Schritt prüft, ob der Agent noch auf dem richtigen Weg ist. Ein Agent wird außerdem selten acht größere Änderungen am Stück übernehmen, ohne dass zwischendurch jemand den Stand betrachtet.

Auch die verwendete Agenten-Software gehört zum Messergebnis. Die Modelle liefen mit ihren nativen Harnesses, deren Tool-Nutzung, Kontextverwaltung und Standardverhalten sich unterscheiden. Der Benchmark vergleicht damit praktisch relevante Gesamtsysteme, aber nicht ausschließlich die Fähigkeiten der zugrunde liegenden Sprachmodelle. Bisher wurde außerdem nur der Python-Track ausgewertet. (arXiv)

Das macht SlopCodeBench nicht schlechter. Es grenzt lediglich ein, welche Schlüsse man daraus ziehen kann.

Was ich aus den Ergebnissen ableite

Opus 5 liefert im kleinen Vergleich ein gutes Ergebnis. Vier statt eines bestandenen Checkpoints sind kein Messfehler, und der Verlauf deutet darauf hin, dass das Modell bestehende Strukturen besser weiterführen kann als Opus 4.8 und Sonnet 5. Für eine belastbare Platzierung gegenüber GPT-5.5, GPT-5.4 oder GPT-5.3 Codex braucht es aber einen vollständigen Lauf über dieselbe Benchmark-Version.

Noch wichtiger ist die gemeinsame Schwäche aller Modelle. Kein Agent löst auch nur ein einziges vollständiges Problem des aktuellen Benchmarks. Das gilt für die offiziellen 36 Probleme ebenso wie für die drei Aufgaben des Opus-5-Laufs.

Coding-Agenten sind damit nicht unbrauchbar. Ganz im Gegenteil: Core-Werte von mehr als 60 Prozent zeigen, dass die Modelle viele einzelne Anforderungen durchaus korrekt umsetzen können. Problematisch wird es, wenn man aus dieser Fähigkeit ableitet, ein Agent könne eine wachsende Software unbeaufsichtigt über längere Zeit pflegen.

Für reale Projekte folgt daraus ein relativ nüchterner Arbeitsablauf. Aufgaben sollten klein genug bleiben, dass Änderungen überprüfbar sind. Nach jedem Schritt müssen Regressionstests laufen. Architektur und Codewachstum brauchen eigene Kontrollpunkte. Refactorings sollten nicht nebenbei in einem Feature-Ticket versteckt werden. Und spätestens wenn ein Agent dieselbe Stelle zum dritten Mal erweitert, sollte jemand prüfen, ob die ursprüngliche Struktur noch trägt.

Der Mensch wird dabei nicht benötigt, weil er schneller tippt. Er wird benötigt, weil er entscheidet, wann eine lokale Lösung beginnt, das Gesamtsystem zu beschädigen.

Fazit

Die Schlagzeile „Opus 5 erreicht 24 Prozent im SlopCodeBench“ ist technisch richtig und trotzdem irreführend.

Richtig ist: Opus 5 bestand in einem unabhängigen Lauf vier von 17 Checkpoints und lag damit deutlich vor Opus 4.8 und Sonnet 5.

Ebenso richtig ist: Der Lauf umfasst nur drei ausgewählte Probleme, ein einziger Checkpoint entspricht fast sechs Prozentpunkten, drei der vier Erfolge liegen am Anfang derselben Aufgabe und kein Modell beendet auch nur eine Aufgabe vollständig.

Derzeit gibt es deshalb keinen belastbaren Beleg dafür, dass Opus 5 den vollständigen SlopCodeBench anführt. Es gibt aber einen ersten Hinweis darauf, dass es seine eigene Codebasis besser weiterentwickeln kann als seine unmittelbaren Claude-Vorgänger.

Die wichtigere Erkenntnis betrifft ohnehin nicht ein einzelnes Modell. Der Abstand zwischen einer überzeugenden ersten Implementierung und dauerhaft zuverlässiger Software ist weiterhin groß. Genau diesen Abstand macht SlopCodeBench sichtbar.

Und vermutlich ist das wertvoller als noch ein Benchmark, in dem am Ende alle Modelle angeblich über 90 Prozent erreichen.