Zum Inhalt springen

Wissensbasis

Coding-Benchmarks

Coding-Benchmarks messen, ob ein Agent eine kleine Menge Unit-Tests bestehen lässt, meist in Python und oft für eine einzige Funktion. Die Teile der Arbeit mit dem größten Hebel lassen sie weg: aus einem unscharfen Problem eine gute Spec machen und eine Codebasis über viele Änderungen leicht änderbar halten.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. Für uns gilt: Der Harness zählt mehr als das Modell (öffnet in einem neuen Tab). Das Modell ist ein Parameter (öffnet in einem neuen Tab), der Harness ist das System, in dem das Modell läuft.

Vertrauen verdienen Benchmarks, die ihren Aufgabenmix steuern und an der Spitze noch Luft lassen. Neben der Genauigkeit bewerten sie Kosten, Tool-Nutzung und die Einhaltung von Vorgaben. Die neueren Indizes für Agents zeigen außerdem, dass dasselbe Modell in verschiedenen Harnesses unterschiedlich abschneidet.

Was messen Coding-Benchmarks wirklich?

Model Cards zitieren Coding-Benchmarks, als würden sie Software Engineering messen. Das tun sie nicht. Nilensos Analyse der bekannten Benchmarks rückt das Bild zurecht: Sie messen etwas Engeres, als ihre Namen versprechen. Ein Modell mit 80% auf SWE-bench erledigt nicht 80% echter Arbeit im ersten Anlauf.

SWE-bench Verified zeigt die Grenzen deutlich:

  • 500 Aufgaben, alle in Python, über 40% davon aus dem Django-Repository. Webanwendungen fehlen ganz.
  • Die Lösungen sind winzig: im Mittel 11 Zeilen, im Median 4, und 77,6% ändern nur eine einzige Funktion.
  • Jedes Issue stammt aus der Zeit vor 2024, eine Kontamination lässt sich also kaum ausschließen.

Auch die saubereren Nachfolger laufen auf “make the unit tests pass” hinaus. Ob der Code wartbar, sicher oder korrekt ist, sagt das nicht. Die UTBoost-Arbeit zeigt: Viele Lösungen für SWE-bench-Aufgaben bestehen die Unit-Tests, ohne das eigentliche Issue zu lösen.

Genau die Teile der Arbeit mit dem größten Hebel lassen diese Benchmarks weg: aus einem unscharfen Problem eine gute Spec und brauchbare Interfaces machen (What are popular AI coding benchmarks actually measuring? (öffnet in einem neuen Tab), 25. September 2025). Die Schlagseite zu Python ist strukturell. AutoCodeBench entstand gezielt als Gegenmittel. Es erzeugt 3.920 Aufgaben in 20 Sprachen ohne manuelle Annotation und prüft die Testfälle in einer mehrsprachigen Sandbox. Selbst die stärksten Modelle tun sich mit seinen anspruchsvollen Aufgaben in mehreren Sprachen schwer (AutoCodeBench (öffnet in einem neuen Tab), 12. August 2025).

Abseits des Happy Path der Benchmarks kehren zwei Fehlerbilder wieder. Erstens nutzen Agents echte Library-APIs falsch. Eine Evaluation von Tessl fand, dass Claude Code und Cursor allein nur etwa 60% Genauigkeit beim idiomatischen Einsatz von Open-Source-Library-APIs erreichten. Deutlich schlechter lief es bei alten Paketen (erschienen 2005 bis 2011) und bei neuen Paketen jenseits des Training-Cutoffs. Dazu kam eine messbare Benachteiligung von Nischen-Libraries. Die Studie behebt das mit versionierter Dokumentation pro Library, die in den Agent eingespielt wird. Für sein eigenes Dokumentationsprodukt nennt der Anbieter einen um etwa 35% höheren Score bei der Abstraction Adherence, gemessen an denselben Agents ohne diese Dokumentation. Übertragbar ist ein anderer Befund: Schlussfolgert ein Agent aus dem Pre-Training heraus über APIs, ist das an beiden Enden der Alterskurve unzuverlässig (Tessl – A Proposed Evaluation Framework for Coding Agents (öffnet in einem neuen Tab), 12. November 2025).

Zweitens zeigen Enterprise-Sprachen mit wenig Trainingsmaterial die Lücke zwischen einem Spezialmodell und einem starken Generalisten. Ein ABAP-Benchmark iteriert bis zu fünf Runden mit Feedback von Compiler und ABAP-Unit. Dort verliert SAPs eigens gebautes ABAP-1 gegen allgemeine Frontier-Modelle, sogar beim Erklären von Code. Der praktische Hebel ist kein weiteres Modell. Er liegt in besserem Tooling und besseren Feedback-Loops rund um ein starkes allgemeines Modell, etwa statischen Checkern oder einem ABAP-MCP-Server (Benchmarking LLMs for ABAP (öffnet in einem neuen Tab), 3. März 2026).

Ob ein Benchmark Vertrauen verdient oder nur ein Prestige-Leaderboard ist, entscheidet die Disziplin im Design. Snorkels Meta-Evaluation benennt die Achsen (Snorkel AI – Meta-evaluations for building benchmarks (öffnet in einem neuen Tab), 4. Juni 2026). Zur Wissenschaft zählen:

  • Qualität der einzelnen Aufgabe: reale Komplexität und prüfbare Lösungen, von Fachleuten validiert, mit adversarialen Protokollen über mehrere Reviewer wie bei GPQA.
  • Kontrolle der Verteilung: eine bewusste Taxonomie, die seltene, aber wichtige Fehlerbilder erfasst und nicht nur die häufigen Fälle.
  • Schwierigkeit und Luft nach oben: nicht gesättigt, damit der Benchmark die Spitze wirklich trennt, wie es ARC-AGI tat.
  • Methodik der Evaluation: über die Genauigkeit hinaus Kosten, Latenz, Qualität der Reasoning-Traces, Tool-Nutzung und Einhaltung von Policy-Vorgaben. Ein Modell, das den richtigen Flug bucht und dabei eine Tarifregel verletzt, fällt trotzdem durch.

Zur Kunst gehören eine These, wohin sich das Feld bewegt (Terminal Bench setzt auf die CLI), und eine Researcher-UX. Sie macht es leicht, den Benchmark auszuführen, zu erweitern und zu ihm beizutragen.

Ein Interview aus der Praxis benennt eine Lücke, die keine dieser Achsen schließt. Issue-to-Patch-Benchmarks belohnen bestandene Tests nach einer einzelnen Änderung. Ob wiederholte Änderungen eine Codebasis auch Monate später leicht änderbar halten, prüfen sie nie. Das Interview schlägt deshalb einen Langzeit-Benchmark vor. Ein Agent setzt eine unbekannte Folge von rund zwanzig Features um. Wer auswertet, beobachtet, ob die Wartbarkeit vor dem Ende der Folge zusammenbricht (Interview zu Context Engineering (öffnet in einem neuen Tab), 15. Juli 2026, Praktiker:in und Anbieter). Das ist ein Vorschlag aus der Praxis, keine gesicherte Evidenz.

Artificial Analysis beantwortet zwei dieser Achsen, Kosten und Harness. Sein kombinierter Index bewertet Coding-Agents statt Modelle. Version 1.5, Stand September 2026, mittelt drei Suites mit gleichem Gewicht: 113 Engineering-Aufgaben mit langem Horizont, 66 Terminal-Aufgaben und 124 Frage-Antwort-Aufgaben zu Repositories. So kann die größte Suite die kleinste nicht überstimmen (Artificial Analysis - Coding Agent Index methodology (öffnet in einem neuen Tab)).

Jede Aufgabe läuft dreimal und zählt als bestanden oder nicht bestanden. Blockiert eine Sicherheitsverweigerung den Versuch, zählt er null. Die Kosten pro Aufgabe ergeben sich aus dem Tokenverbrauch und den jeweiligen API-Preisen pro Token. Input, Cache, Reasoning und Output erfasst der Index dabei getrennt. Seit v1.4 prüft ein Judge-Agent die Terminal-Trajektorien. Er markiert Läufe, die Tests verändert, eine Referenzlösung gelesen oder die Antwort von außen geholt haben (Artificial Analysis - Coding Agent Index methodology (öffnet in einem neuen Tab)). Der Index ändert sich schnell: v1.0 erschien im Mai 2026, v1.5 im September. Scores verschiedener Versionen sind nicht vergleichbar.

Der Index trägt den Score gegen die Ausgaben auf. Deshalb zeigt er, welche Ergebnisse dasselbe Modell je nach Harness bei welchem Budget erreicht. Im Vergleich, abgelesen am 24. Oktober 2026, erreichte Claude Code 62 Punkte bei etwa 11,42 $ und 14,5 Millionen Tokens pro Aufgabe. Codex erreichte 55 bei etwa 7,04 $ und 3,2 Millionen Tokens (Artificial Analysis - Claude Code vs Codex (öffnet in einem neuen Tab)). Solche Zahlen veralten binnen Wochen. Bleibend ist eine andere Lesart: Eine höhere Effort-Einstellung kauft Punkte zu einem steil steigenden Preis. Ein Team muss also klären, ab welchem Punkt der Kurve sich die eigenen Aufgaben nicht mehr auszahlen.

Verwandte Seiten

Quellen

Leaderboards