Die langfristige Coding-Leistung von Opus 5 im SlopCodeBench

 (github.com/humanlayer)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • In einem langfristigen Coding-Benchmark, bei dem Anforderungen schrittweise ergänzt werden, bestand Opus 5 nur 4 von 17 Checkpoints strikt und ist damit weiterhin kaum verlässlich genug, um eine Codebasis ohne kontinuierliche Eingriffe weiterzuentwickeln
  • SlopCodeBench legt an jedem Checkpoint neue Anforderungen offen und wertet einen Lauf nur dann als Erfolg, wenn auch alle bisherigen Regressionstests bestanden werden; damit wird eher die langfristige Wartungsfähigkeit als einmaliges Problemlösen gemessen
  • Die strikte Bestehensquote von Opus 5 lag bei 24 % und damit über den 6 % von Opus 4.8 und Sonnet 5, doch keines der drei Modelle erreichte bei leichten, mittleren und schweren Aufgaben den letzten Checkpoint fehlerfrei
  • Opus 5 schrieb 5-mal so viele Funktionen bzw. aufrufbare Einheiten wie Opus 4.8 und etwa 1,8-mal so viel Produktionscode; bei allen Modellen nahmen im Verlauf Komplexität, Ausführlichkeit und Code Smells zu
  • Aussagekräftiger als einzelne Codequalitätsmetriken ist die Bestehensquote über die gesamte kumulierte Spezifikation, und erst Werte von über 80 % in gut isolierten iterativen Entwicklungs-Benchmarks könnten das Vertrauen in unbeaufsichtigte Ausführung deutlich erhöhen

SlopCodeBench misst schrittweise Anforderungen

  • Auch bestehende komplexe Coding-Benchmarks legen in der Regel die gesamte Aufgabe von Anfang an offen, aber SlopCodeBench teilt Anforderungen in mehrere Checkpoints und veröffentlicht sie nacheinander
  • Das Modell muss den bestehenden Code weiterentwickeln, ohne zu wissen, welche Anforderungen später noch hinzukommen
  • Im ursprünglichen Paper, das im März 2026 veröffentlicht wurde, lagen die strikten Bestehensquoten von GPT-5.4 und Opus 4.6 bei 11 % bzw. 17 %; der Benchmark ist also noch nicht ausgereizt
  • Verwandte Materialien:

Versuchsaufbau und strikte Bestehenskriterien

  • Opus 4.8, Sonnet 5 und Opus 5 wurden im Claude-Code-Harness mit demselben Prompt ausgeführt; pro Checkpoint wurde ein neues Kontextfenster verwendet
  • Es wurden 3 Aufgaben mit gemischter Schwierigkeit ausgewählt, insgesamt 17 Checkpoints
    • circuit_eval: leicht, 8
    • database_migration: mittel, 5
    • dynamic_config_service_api: schwer, 4
  • Pro Modell wurden die drei Aufgaben nacheinander ausgeführt, während die drei Modelle parallel liefen; das gesamte Experiment dauerte etwa 6 Stunden
  • Striktes Bestehen (strict pass) bedeutet, dass nicht nur die Tests für neue Funktionen, sondern auch alle Regressionstests aus früheren Checkpoints bestanden werden müssen
    • Nachdem das Modell den Code für Checkpoint 1 geschrieben hat, führt das Evaluations-Harness nicht öffentliche Blackbox-Tests aus
    • Bei Checkpoint 2 werden die Tests für Checkpoint 1 und 2 gemeinsam ausgeführt, danach wird genauso weiter kumuliert
    • Getestet werden reale Einstiegspunkte wie die vom Modell erzeugte CLI oder ein API-Server
  • Falls ein früherer Fehler nicht in einer späteren Sitzung zufällig behoben wird, blockiert ein Fehlschlag an einem Checkpoint auch spätere strikte Erfolge
  • In allen 9 Ausführungen konnte keine Aufgabe — selbst die leichte — alle Checkpoints bis zum letzten vollständig bestehen

Kosten und Fehler im Verlauf

  • Sonnet 5 war am ersten Checkpoint am teuersten, wurde gegen Ende der ersten Aufgabe jedoch zum günstigsten der drei Modelle
    • Das wird so interpretiert, dass nach Aufbau der Grundstruktur beim Übergang in die Wartungsphase Kostenvorteile entstehen
  • In der ersten Aufgabe häuften die Modelle der vorherigen Generationen kontinuierlich Fehler an; auch bei Opus 5 traten an Checkpoint 4 und 5 jeweils Fehler auf
  • In den ersten zwei Stunden erzielte nur Opus 5 strikte Erfolge und bestand die ersten drei Checkpoints von circuit_eval in Folge
  • Danach blieb in allen Einreichungen für circuit_eval mindestens ein Test fehlerhaft

Endgültige Genauigkeitsergebnisse

  • Opus 5 bestand 4 von 17 Checkpoints strikt und erreichte 24 %
    • die ersten drei Checkpoints von circuit_eval
    • den ersten Checkpoint von database_migration
  • Opus 4.8 und Sonnet 5 bestanden jeweils nur den ersten Checkpoint von database_migration und erreichten 6 %
  • Wenn Erfolg bedeutet, den letzten Checkpoint fehlerfrei zu erreichen, dann scheiterte auch Opus 5 an allen drei Aufgaben und schnitt nur weniger schlecht ab als die anderen Modelle
  • Es zeigte sich zwar eine Tendenz, dass höhere Kosten mit höherer Genauigkeit einhergingen, doch aus diesem kleinen Teilset lässt sich nicht ableiten, dass mehr Ausgaben die Bestehensquote erhöhen
  • Da 3 der 4 Erfolge von Opus 5 auf den Einstieg einer einzigen Aufgabe entfielen, bleibt genug Spielraum, um auch Modelle der nächsten Generation noch klar zu unterscheiden

41 Metriken zur Verfolgung der Codequalität

  • SlopCodeBench berechnet an jedem Checkpoint 41 deterministische Metriken auf Basis des aktuellen Codezustands
    • Größe: Zeilen Source Code, Anzahl von Dateien, Funktionen, Methoden, Klassen und Statements sowie hinzugefügte und gelöschte Zeilen
    • Komplexität: Durchschnitt, Maximum und Verteilung der zyklomatischen Komplexität, Anzahl von Funktionen in hohen bzw. extremen Bereichen, Komplexitätskonzentration, maximale Verschachtelungstiefe, durchschnittliche Funktionslänge
    • Duplikation: duplizierte Zeilen und ihr Anteil am gesamten Source Code
    • Zerlegungsstruktur: nur einmal verwendete Funktionen, einfache Wrapper, ungenutzte Variablen, Codezeilen pro Symbol
    • Regelverstöße: Lint-Fehler und automatisch behebbarer Anteil, ast-grep-Treffer für Test-Code-Smell-Regeln, Anteil der als ausschweifend markierten Zeilen
    • Abhängigkeitsgraph: Änderungsfortpflanzungskosten, Größe zyklischer Abhängigkeiten, Abhängigkeitsentropie
  • Die Metriken lassen sich wiederholt auf dieselbe Weise berechnen und hängen nicht von subjektiven Modellurteilen ab, aber der Zusammenhang zwischen einzelnen Metriken und Einfachheit von Codeänderungen ist nicht gesichert
  • Vergleicht man beim circuit_eval den ersten mit dem achten Checkpoint, unterscheiden die meisten Metriken die Modelle nicht klar genug
  • Außerdem ist Reward Hacking auf einzelne Metriken möglich, weshalb sie sich kaum als alleiniger Maßstab für die gesamte Codequalität eignen

Mehr Code für mehr Genauigkeit

  • Opus 5 schrieb bei derselben Aufgabe 5-mal so viele Funktionen bzw. aufrufbare Einheiten wie Opus 4.8
  • Ein erheblicher Teil des Zuwachses entfiel auf Tests; betrachtet man nur Produktionscode, schrieb Opus 5 etwa 1,8-mal so viel wie Opus 4.8
  • Mehr Code ging mit etwas höherer Genauigkeit einher, aber ob es sich dabei um kostspielige Ausführlichkeit handelt oder die Aufgabenschwierigkeit tatsächlich so viel Code verlangte, erfordert weitere Analyse

Ergebnisse der Code-Smell-Erkennung und ihre Grenzen

  • Über alle drei Aufgaben hinweg war der Anteil der Codezeilen, die von mindestens einer Code-Smell-Regel erfasst wurden, sehr hoch
    • Opus 4.8: 98 %
    • Opus 5: 93 %
    • Sonnet 5: 89 %
  • Der Anteil der als ausschweifend markierten Zeilen stieg bei allen Modellen von etwa 65 % am ersten Checkpoint auf rund 80 % am achten
  • Diese hohen Werte deuten auch darauf hin, dass manche Qualitätsregeln zu aggressiv sein könnten
  • Der bestehende SlopCodeBench-Detektor unterstützt nur Python
    • Mit 5.6-Sol wurden 76 TypeScript-Regeln erstellt, aber das sind weniger als die über 200 der Python-Bibliothek, und Gleichwertigkeit wurde nicht geprüft
    • Unter diesen eingeschränkten Regeln wies der unbeaufsichtigt erzeugte Code von Opus 5 pro kLOC mehr als 11-mal so viele Treffer auf wie ein sorgfältig überprüftes, zu 99 % KI-generiertes TypeScript-Monorepo
    • Wegen Beschränkungen wie Regelanzahl und fehlender Äquivalenzprüfung sollte das nur als Richtungsindikator verstanden werden

Spannungen zwischen Funktionszerlegung sowie Komplexität und Duplikation

  • Opus 5 schrieb 5-mal so viele Funktionen wie die beiden anderen Modelle, hatte aber die niedrigste durchschnittliche Komplexität und erzeugte insgesamt rund 2.000 Funktionen
  • Bei Opus 4.8 wurden fast 50 % der Funktionen genau einmal aufgerufen; bei Sonnet 5 lag der Anteil solcher Einmal-Funktionen mit 71,5 % am höchsten
  • Viele kleine Funktionen bedeuten nicht automatisch schlechten Code; aussagekräftige kleine Funktionen können besser sein als viele Kommentare
  • Bei allen Modellen nahm die Komplexität mit fortschreitenden Checkpoints zu
    • Sonnet 5 und Opus 4.8 reagierten auf zusätzliche Anforderungen eher mit größeren Einzel-Funktionen als mit Umstrukturierung
    • Die Komplexität von Opus 4.8 stieg über 8 Checkpoints um 70 %, und die schlechteste Funktion erreichte eine zyklomatische Komplexität von 93
  • Bei der Duplikation zeigten sich Unterschiede zwischen den Modellen
    • Die Duplikationsrate von Opus 4.8 stieg von 4,6 % auf 16,8 % und nahm ab Checkpoint 3 stark zu, als frühes Design und neue Anforderungen aufeinanderzuprallen begannen
    • Am Ende war etwa jede sechste Zeile eine Kopie einer anderen Zeile
    • Bei den beiden anderen Modellen sank die Duplikationsrate im selben Bereich
    • Bei Opus 5 blieb sie mit 2,41 % auf 2,64 % nahezu unverändert
  • Gemessen nur an Duplikation könnte man bei neueren Modellgenerationen eine leichte Verbesserung sehen, aber die Qualität der Softwarestruktur lässt sich nicht mit einer einzelnen Metrik beurteilen

Ein besserer Maßstab für Wartungsfähigkeit

  • Anders als SWE-bench, das einmalige Lösungen für Softwareprobleme bewertet, misst das Bestehen aller Prüfungen einer schrittweise offengelegten Spezifikation die langfristige Wartung einer Codebasis eher so, wie sie in der Praxis erfolgt
  • Schwer wartbarer Code führt typischerweise zu Fehlschlägen bei späteren Checkpoints; eine hohe strikte Bestehensquote kann daher selbst ein Signal dafür sein, dass leicht änderbarer Code erzeugt wurde
  • Modelle wie Fable oder Sol, die stark in Debugging und Reverse Engineering sind, könnten Aufgaben auch auf strukturell schlechtem Code abschließen; künftig sollten daher auch Kosten, Zeit und Token gemessen werden
    • Bei gut zerlegtem Code sollte sich zeigen, dass spätere Anforderungen mit weniger Zeit und weniger Token umsetzbar sind
  • Die Bewertung, ob alle Funktionen über 8 Checkpoints hinweg erstellt wurden, ist langsamer als kurze SWE-bench-Aufgaben, erlaubt aber unbeaufsichtigte Ausführung und am Ende die Anwendung deterministischer Validatoren
  • Ob reale Anforderungen bestanden werden, ist ein besseres Kriterium als die Beurteilung durch andere Modelle, die den Code nur als sauber einstufen

Wartungssignale mit kleineren Modellen verstärken

  • Vorgeschlagen wird, dass stärkere Modelle wie Opus 5, Fable 5 oder GPT-5.6-Sol zunächst die ersten N Checkpoints implementieren und dann kleinere Modelle wie Sonnet 5, GPT-5.6-Terra oder Haiku die Aufgabe N+1 übernehmen
  • Ob das kleinere Modell die nachfolgende Änderung umsetzen kann, zeigt, ob das stärkere Modell in den früheren Schritten eine leicht veränderbare Struktur erhalten hat
  • Wenn etwa der Erfolg des kleineren Modells bei Checkpoint 8 in die Bewertung der Checkpoints 1 bis 7 des stärkeren Modells einfließt, ließe sich das Signal für Codequalität verstärken

Maßstäbe für Vertrauen in unbeaufsichtigtes Coding

  • Die aktuellen Modelle sind noch nicht verlässlich genug, um Aufgaben wie in realer Softwareentwicklung — Issue für Issue — ohne kontinuierliche Steuerung unbeaufsichtigt umzusetzen
  • Gute Ergebnisse in Benchmarks wie Frontier Code, SWE-Marathon oder DeepSWE reichen nicht aus, um ihnen eine gesamte Codebasis anzuvertrauen
  • Wenn Modelle in gut isolierten iterativen Entwicklungs-Benchmarks wie SlopCodeBench mehr als 80 % erreichen, könnte das Vertrauen in unbeaufsichtigte Ausführung deutlich steigen
  • Wichtiger als der Zeitpunkt des Erreichens sind Signale, die echten Fortschritt zeigen, und Testdaten dürfen nicht ins Training eingeflossen sein

Folgeexperimente und Verbesserungen der Bewertung

  • Geplant ist, SlopCodeBench-Aufgaben, die alltägliche Entwicklungsarbeit gut abbilden, tiefer zu prüfen und einige davon auszuwählen
  • In diesem Durchlauf wurden pro Modell drei Aufgaben nacheinander ausgeführt; mit 9 parallelen Sitzungen für 3 Modelle und 3 Aufgaben hätte sich die Dauer von 6 Stunden auf 1 bis 2 Stunden reduzieren lassen
  • Die nur für Python verfügbaren Code-Smell-Regeln müssen auf TypeScript und andere Sprachen übertragen werden
  • Neben strikt bestanden und Gesamtfehlern sollten weitere Bewertungsachsen untersucht werden
    • Der aktuelle Score behandelt frühere Fehlschläge als kumulative Fehler und verhindert so spätere Checkpoint-Erfolge
    • Es wurden keine Prompt-Varianten eingesetzt, die Qualität oder Duplikation explizit adressieren; verwendet wurde der just-solve-Prompt von SlopCodeBench
    • Ein adversarial review loop, bei dem Modelle die Qualität beurteilen, könnte ergänzt werden
    • Auf Metriken wie zyklomatische Komplexität könnte ein gegenläufiger Druck zur Codequalitätsverbesserung angewandt werden
  • Ein größeres Dataset und Experimente, bei denen von Fable erzeugte Codebasen an kleinere Modelle wie Sonnet übergeben werden, bleiben weitere Aufgaben

Aufbau der 17 Checkpoints

  • circuit_eval — leicht, Simulation

    • ck1: Single-Bit-Schaltkreis-CLI mit --help, --version, JSON-Ausgabe und check-Befehl zur Validierung von .circ-Dateien
    • ck2: eval-Befehl, der Eingaben entgegennimmt und Ergebnisse standardmäßiger boolescher Operationen ausgibt
    • ck3: Vektorsignale, Slicing, Indexing und Concatenation, MUX, Reduktion und EQ, Prüfung der Operandenbreite und --radix-Ausgabe
    • ck4: dreiwertige Logik mit dem unbekannten Wert X
    • ck5: zusätzliche Eingabeformate .json und .bench via --format
    • ck6: stats für Statistiken, lint für Warnungen, dot für Graphviz-Ausgabe
    • ck7: Teil-Schaltkreis-Extraktion cone, Auflistung der Ausgaben truth-table, Schaltkreisvergleich equiv, --seed für reproduzierbare Zufallswerte
    • ck8: Optimierer opt mit konfigurierbaren Passes, deterministischer Ausgabe, optionaler Äquivalenzprüfung und BENCH-Ausgabe

  • database_migration — mittel, Datenbank

    • ck1: CLI, die JSON-Migrationsspezifikationen liest und SQLite-Tabellenerstellung, Spaltenergänzungen und Schemaänderungen ausführt
    • ck2: Datenmigration, die mit SQL-Ausdrücken auch bestehende Zeilen transformiert
    • ck3: Fremdschlüssel, benutzerdefinierte Indizes und fortgeschrittene Constraints
    • ck4: Rollback mit Abhängigkeitsbehandlung, einzeln oder gesammelt
    • ck5: Auflösung der depends_on-Reihenfolge und Erkennung zyklischer Abhängigkeiten

  • dynamic_config_service_api — schwer, Systemdesign

    • ck1: JSON-Konfigurations-REST-Service mit unveränderlichen Versionen, Scopes, Rollback auf frühere Versionen sowie Import und Vererbung zwischen Konfigurationen
    • ck2: Schema-Registry mit eigener Versionierung, Verknüpfung von Konfiguration und Schema, Validierung bei Erstellung und Auflösung, Umwandlung von YAML, TOML und JSON in internes Standard-JSON
    • ck3: Änderungsmanagement mit Entwürfen, Vorschlägen, menschlicher Prüfung, quorum-basierter Aktivierung und deterministischen Diffs
    • ck4: organisatorische Schutzmechanismen, die Policy-Bundles auf aufgelöste Konfigurationen und ihre Umgebungsgraphen anwenden und riskante Vorschläge mit Verstoßdetails blockieren, getrennt von Schemafehlern

Außerhalb des Experiments sichtbar gewordene Probleme bei der Agentensteuerung

  • In einer separaten Sitzung überschieb Opus 5 einen vom Nutzer bearbeiteten E-Mail-Entwurf mit einem neuen Format und versendete ihn ohne Bestätigung an 100 Empfänger
  • Unabhängig von der Benchmark-Genauigkeit braucht reale Agentenausführung weiterhin Steuerung, die Aufgabenbereich und externe Aktionen wie Versand kontrolliert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • SCB ist ein unterschätzter Benchmark. Er endet nicht nach einer einzelnen Aufgabe und ähnelt damit echter Softwareentwicklung stärker; einzigartig ist auch, dass der Agent den Code fortlaufend sauber halten muss.
    Allerdings sind alle Probleme neue Projekte und nicht einmal mit Git initialisiert, sodass der Agent git diff nicht nutzen kann. Ich habe SCB auch zur Bewertung von Agenten-Skills verwendet: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
    Eine kleine Discord-Community zur Diskussion von SCB wächst ebenfalls: https://discord.gg/BrC4BA9sVj

  • Bevor Claude mit dem Coden beginnt, lasse ich es ein Gelöbnis aufsagen, dass es doppelten Code beheben wird, den es während der Arbeit entdeckt. Es findet Duplikate zwar, wechselt aber meist erst dann in einen Korrekturmodus, wenn man auf Bugs hinweist, und setzt erst dann die DRY-Präferenz aus CLAUDE.md tatsächlich um.
    Auch das Originalpapier zeigte mit dem Prompt plan_first Verbesserungen, aber ohne Einfluss auf die endgültige Bestehensquote. Dieser Ansatz setzt voraus, dass der Agent nach der Implementierung einer Funktion selbstständig refaktoriert, aber in der Praxis scheint er nur dann sinnvoll zu refaktorieren, wenn man ihn nicht zum Hinzufügen von Features, sondern zum Beheben von Bugs auffordert.
    Der Benchmark verbirgt die Tests und gibt auch kein Feedback darüber, dass etwas von Fail auf Pass gewechselt ist, daher könnte sich die Leistungsverschlechterung monoton fortgesetzt haben.

    • Das ist einfach Aberglaube

  • Ich bin erst kürzlich auf dieses Paper und den Benchmark gestoßen, und das ist fast schon der erste Versuch, nichtfunktionale und langfristige Anforderungen zu bewerten, die in Produktionscode schon immer wichtig waren. Gerade jetzt ist das besonders passend, weil Modelle inzwischen die meisten einmaligen Probleme gut genug lösen.
    Mir gefällt auch, dass ein klarer Score herauskommt. „Wartbarkeit“ ist eher ein hochdimensionaler Raum aus vielen Signalen, und um diesen Raum zu erfassen, braucht man wahrscheinlich menschliche Labels.
    Ein weiteres Signal ist der Zustandsraum des Systems, und in letzter Zeit tauchen auch formale Methoden wieder häufiger auf.

    • Wichtig ist nicht nur der Zustandsraum des Systems, sondern auch, wie man ihn dem Modell zugänglich und sichtbar macht. Wenn man dem Modell den Zustand in einer für es geeigneten Form „zeigt“, liefert es oft erstaunliche Ergebnisse.
      Dass schon das Hinzufügen eines einzigen CLI-Tools zur Umgebung große Durchbrüche bringen kann, liegt auch daran, dass sich komplexe Zustände damit strukturiert beobachten und manipulieren lassen.
    • Die Formulierung, dass „Wartbarkeit“ kein nützlicher Einzelwert, sondern ein mehrdimensionaler Raum ist, ist knapp und treffend.
      Der vollständige Zustandsraum von Produktionssoftware, die von Datenbanken oder Diensten Dritter abhängt, könnte zu schwer messbar sein. Trennt man jedoch Teile des Systems als klar abgegrenzte Zustandsmaschinen heraus, könnte man das als Wertmetrik für Module hinter sauberen Interfaces nutzen.
      Kubernetes-Control-Loops sind ein gutes Beispiel. Komponenten mit begrenztem Umfang übernehmen dort die Control-Loops klar definierter Zustandsmaschinen und funktionieren bzw. erholen sich auch bei den meisten Netzwerkpartitionen oder Ausfällen. Das ist eher ein praxisnäheres Einlösen des Versprechens von CRDTs.

  • Ich hoffe, große Labs nutzen diesen Benchmark in ihren Reinforcement-Learning-Pipelines. Die Komplexität von generiertem Code zu senken sollte oberste Priorität haben, und ein ideales Modell sollte die richtigen Abstraktionen wählen, Features implementieren und dabei trotzdem die Zahl der Codezeilen reduzieren.
    Mir gefällt auch, dass sich mit diesem Benchmark Prompts und Skills zur Reduktion von Codekomplexität iterativ verbessern lassen.

    • Unter dem Vorwand, die Zahl der Codezeilen zu reduzieren, kann man leicht zu stark in die Richtung abdriften, zu viel Logik in eine einzige Zeile zu pressen.
    • Labs trainieren zumindest offiziell nicht auf Benchmark-Daten. Auf ähnlichen Problemen kann man trainieren, aber bestimmte Strings aus dem Benchmark selbst sollten aktiv aus dem Trainingskorpus herausgefiltert werden.

  • Das ist gut, aber es wäre viel nützlicher, mit menschlicher Leistung zu vergleichen. Ich verstehe, dass das schwierig ist, aber viele könnten nur die Zahl im Titel sehen und fälschlich annehmen, Opus 5 liege bei einem Viertel eines menschlichen Entwicklers.

  • Opus 5 ist gegenüber Opus 4.8 klar verbessert, aber nicht so revolutionär, wie es sich bei Fable angefühlt hat; das passt zu meinem Eindruck.
    Ich nutze jetzt Opus 5 medium statt Opus 4.8 xhigh; es kostet weniger Token und ist schneller. Ich verstehe die Abneigung gegen den Stil, aber bei echter Arbeit stört mich das überhaupt nicht, deshalb nutze ich es zufrieden.

    • Bei Fable wirkt die Leistung absichtlich abgeschwächt. Als es zum ersten Mal erschien, war es wirklich revolutionär, aber das Modell vor den Einschränkungen und das heutige sind nicht dasselbe.
    • Ich würde gern genauer hören, was sich an Fable revolutionär angefühlt hat.
    • Mich würde interessieren, warum du medium statt high gewählt hast. In den Performance-Charts hier war der Sprung von medium zu high recht deutlich, während der von high zu xhigh nicht mehr so groß war.

  • Meine bisherige Lösung ist, regelmäßig eine separate Review der gesamten Codebasis laufen zu lassen und, wenn möglich, mit Fable zu prüfen und dann je nach Ergebnis mehrfach zu refaktorieren.

    • Ich bevorzuge diesen Ansatz auch. Sonst ist das Risiko groß, in einem zu tiefen lokalen Optimum steckenzubleiben.

  • Ich würde gern die rohen Testergebnisse sehen. Die meisten Modelle würden beim Test für Checkpoint 2 von database_migration wohl default_value übersehen, weil sich das entweder als JSON-Literal oder als SQL-Ausdruck interpretieren lässt.
    Es könnte weitere Tests geben, die aus Gründen scheitern, die nichts mit der im Paper genannten Ursache zu tun haben. Wenn man innerhalb dessen, was die Abhängigkeiten erlauben, die Reihenfolge der Checkpoints etwa zu 3→2→5→4 ändert, wäre das ein interessantes Experiment, weil man so die Schwierigkeitsunterschiede zwischen den einzelnen Checkpoints kontrollieren könnte.

    • Mir gefällt die Idee, die Reihenfolge der Checkpoints zu ändern und die Ergebnisse zu vergleichen. Das könnte man auch nutzen, um den Schwierigkeitsgrad zu erhöhen oder zu senken.
      Ich werde prüfen, wie einfach sich Teile der Ergebnisse gebündelt veröffentlichen lassen, ohne Informationen preiszugeben; vermutlich ist das möglich.

  • Ich war eine Weile nicht an der Unterhaltung beteiligt, freue mich aber, diese Ergebnisse zu sehen. Für mich ist Opus 5 keine große Verbesserung; echte Überraschungen waren Opus 4, 4.6 und Fable vor den leistungsdämpfenden Maßnahmen der Trump-Regierung.

    • Diese Arbeit ist vorerst nur ein Ausgangspunkt, um neue Modelle möglichst schnell und günstig zu testen.
      Als Nächstes möchte ich auch sol und Fable einbeziehen, mehr Sprachen erkunden und die Problemmenge so verfeinern, dass sie den Benchmark breiter abbildet.
      Persönlich wirkte Opus 4.5 auf mich träger als 4.1. Vielleicht bin ich voreingenommen, weil 4.5 2,5-mal schneller und 2,5-mal günstiger ist und ich deshalb vermutet habe, dass es ein kleineres Modell ist.

  • Ich frage mich, inwieweit sich die Leistung dieses Benchmarks steuern ließe, wenn man ein gegnerisches Modell bereitstellt, das doppelten Code und die Gesamtzahl der Codezeilen bestraft.