Co-Design Bench: Bestes Coding-Modell löst 26,4 Prozent der Aufgaben vollständig
Ein neuer Benchmark aus echten Coding-Sitzungen zeigt, dass selbst das stärkste von zehn Modellen die meisten Aufgaben nicht vollständig erledigt.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- Co-Design Bench ist ein referenzfreier Benchmark mit 273 Aufgaben aus realen Nutzer-Coding-Sitzungen.
- Die Aufgaben wurden aus 37.463 deduplizierten Anfragen aus 26.314 Coding-Sitzungen kuratiert.
- Es gibt zwei Tracks, Multimodal Editing und Repository Editing; Dimensionen sind Grounded Understanding, UI Transformation, Functional Implementation.
- Bewertet wird per Judge-then-refute-Protokoll, bei dem ein separater LLM-Verifier positive Urteile anficht.
- Bei Repository-Edits erfüllen alle zehn Endpunkte mit drei oder vier Änderungstypen weniger Kriterien als mit ein oder zwei.
Bestes Modell löst nur 26,4 Prozent der Aufgaben vollständig
Der Benchmark Co-Design Bench umfasst 273 Aufgaben aus realen Coding-Sitzungen. Laut dem Fachportal The Decoder erfüllt das beste von zehn getesteten Modellen, GPT-6 Astra, im Schnitt rund 70 Prozent der Kriterien je Aufgabe. Ganz gelöst hat es 26,4 Prozent der Aufgaben. Diese Werte stammen aus der Fachpresse. Der vorliegende Auszug des Paper-Abstracts enthält sie nicht.
Als Entwickler nennt der Bericht Forschende von Alibaba und mehreren asiatischen Universitäten. Ein Befund steht im Paper selbst: Alle zehn Modelle schneiden bei Repository-Edits mit drei oder vier Änderungstypen schlechter ab als bei Änderungen mit einem oder zwei Typen. Je mehr Änderungstypen eine Aufgabe umfasst, desto geringer fällt die Kriteriumserfüllung aus.
Versteckte Expertenkriterien und ein Verifier, der Urteile anficht
Die 273 Aufgaben stammen aus 37.463 deduplizierten Anfragen in 26.314 realen Coding-Sitzungen. Jede Aufgabe besteht aus einer normalisierten Anfrage, einer lauffähigen Anwendung im Zustand vor der Änderung und versteckten, von Experten verfassten Abnahmekriterien. Die Quelle nennt insgesamt 2.331 dieser Kriterien. Der Auszug bricht an dieser Stelle ab.
Der Benchmark kennt zwei Tracks. Multimodal Editing umfasst lokale Änderungen, optional mit Bild-, Audio-, Video- oder Dokumenteingaben. Repository Editing verlangt koordinierte Änderungen am gesamten Repository. Die Aufgaben decken drei Fähigkeiten ab: Grounded Understanding, UI Transformation und Functional Implementation.
Bewertet wird im Judge-then-refute-Protokoll. Zuerst beurteilt ein Judge die Kriterien anhand von Quellcode und Browser-Evidenz. Positive Urteile ficht danach ein separates LLM als Verifier an. Visuelle und interaktive Aussagen prüft das System ohne Gold-Code oder Ziel-Screenshots. Der Benchmark ist damit referenzfrei. Laut README enthält das Repository das Evaluationsprotokoll, einen Quickstart mit synthetischen Aufgaben und eine öffentliche Teilmenge des Datensatzes. Der Referenz-Judge setzt eine authentifizierte Claude CLI, Node.js, Playwright und Chromium voraus.
Warum die Werte klassischer Tests und von Co-Design Bench nicht direkt vergleichbar sind
Die Autoren begründen den Benchmark mit der Sättigung bestehender Tests. Laut The Decoder liegen die Werte dort über 99 Prozent, sofern Modelle ihren Code selbst ausführen und nachbessern dürfen. Unterschiede zwischen Modellen lassen sich so kaum noch messen. Für Co-Design Bench wählten die Forschenden bevorzugt Fälle, in denen Nutzer ihre Bitten mehrfach umformulieren oder Änderungen zurücknehmen mussten.
Als Kontrast dient SWE-bench: 2.294 Aufgaben aus Pull Requests und Issues von 12 Python-Repositories. Das System erhält den Issue-Text als Vorgabe.
Die Zahlen beider Benchmarks stehen daher nicht direkt nebeneinander. SWE-bench wertet per Fail-to-Pass-Test, ob eine Aufgabe besteht. Co-Design Bench wertet versteckte Kriterien aus. Die rund 70 Prozent gelten dabei auf Kriterienebene, die 26,4 Prozent auf Aufgabenebene. Auch die Aufgabenart unterscheidet sich: hier formale Issues, dort mehrfach umformulierte und teils multimodale Nutzeranfragen. Ein Vergleich ist nur eingeschränkt zulässig. Laut dem Material müssen Teams bei größeren Agenten-Änderungen mit Nacharbeit und Verifikation rechnen.



