Co-Design Bench macht Schwächen von KI-Agenten bei App-Änderungen messbar

Zwei Bearbeitungsspuren und fünf Eingabeformen

Die erste Spur, Multimodal Editing (ME), umfasst 100 Aufgaben zu lokal begrenzten visuellen, strukturellen oder inhaltlichen Änderungen. Neben einer lauffähigen Seite und einer markierten Zielregion können die Aufgaben Bild-, Audio-, Video- oder Dokumentanhänge enthalten. Die zweite Spur, Repository Editing (RE), umfasst 173 Aufgaben und prüft koordinierte Änderungen in mehrteiligen Frontend-Repositories, etwa über Komponenten, Routen, Zustand, Datenfluss und Inhalte hinweg. [1] [3]

Die Kriterien ordnen die Anforderungen drei übergeordneten Kompetenzbereichen zu: Grounded Understanding, UI Transformation und Functional Implementation. Damit soll der Benchmark sowohl erfassen, ob ein Agent Informationen aus einer Referenz richtig interpretiert, als auch, ob er die Oberfläche und die dahinterliegenden Funktionen korrekt anpasst. Viele Aufgaben verbinden mehrere dieser Bereiche. [1] [3] [4]

Die Beispiele veranschaulichen, warum einzelne Änderungen nicht isoliert betrachtet werden können. Bei einer Videoaufgabe muss ein Agent drei unterschiedliche Textanimationen einer bestehenden Website zuordnen und umsetzen, während Text und Layout erhalten bleiben. Eine dokumentgestützte Aufgabe verlangt, einen Belegwert zu korrigieren und abhängige Summen oder Ansichten konsistent nachzuführen. Das sind Beispiele für Anforderungen, bei denen eine sichtbare Änderung allein noch keinen vollständigen Erfolg belegt. [3] [4]

• ME: 100 Aufgaben zu lokalen Änderungen, mit optionalen multimodalen Anhängen. [1] [3]
• RE: 173 Aufgaben zu koordinierten Änderungen über mehrere Teile einer Anwendung hinweg. [1] [3]
• Insgesamt: 2.331 verdeckte Abnahmekriterien, die mehrere gültige Implementierungen zulassen. [1] [3]

Wie die Bewertung positive Ergebnisse hinterfragt

Die Autoren bezeichnen ihr Verfahren als „judge-then-refute“: Ein primärer Bewerter prüft jedes verdeckte Kriterium anhand von Quellcode und Browserbelegen und vergibt PASS, PARTIAL oder FAIL. Anschließend soll ein separater Sprachmodell-Verifizierer positive Urteile gezielt infrage stellen. Er sucht unter anderem nach Platzhalterimplementierungen, fest codierten Ausgaben, nicht erreichbaren Funktionen oder Abweichungen von der eigentlichen Anforderung. [2] [3]

Für visuelle Aussagen verlangt das Verfahren einen erfolgreichen Render und Screenshots; für Aussagen zum Interaktionsverhalten sind aufgezeichnete Browseraktionen und die daraus resultierenden Zustände vorgesehen. Fehlen erforderliche Belege, wird die Aggregation der Ergebnisse abgebrochen. Der Benchmark benötigt weder eine vorgegebene Musterimplementierung noch einen Ziel-Screenshot. „Referenzfrei“ bedeutet hier allerdings nicht, dass der Agent ohne Kontext arbeitet: Die lauffähige Ausgangsanwendung bleibt Teil der Aufgabe. [1] [2] [3]

Die Kennzahlen trennen Fortschritt bei Einzelanforderungen von vollständiger Lieferung. Strict Completion misst den Anteil der Kriterien, die als PASS bewertet wurden; PARTIAL zählt dabei nicht als bestanden. Graded Completion berücksichtigt PARTIAL mit halber Wertung. Die Full-Pass-Rate zählt eine Aufgabe nur dann als vollständig erledigt, wenn jedes ihrer Kriterien PASS erreicht. Aufgaben werden für die Mittelwerte gleich gewichtet, sodass ein längerer Kriterienkatalog nicht automatisch stärker in die Gesamtbewertung eingeht. [2] [4]

Viele erfüllte Teilanforderungen bedeuten nicht vollständige Lieferung

Unter einem gemeinsamen agentischen Test-Setup erzielte der stärkste der zehn Modellendpunkte im Mittel 69,9 Prozent Strict Completion, bestand aber nur 26,4 Prozent der Aufgaben vollständig. Der erste Wert bezeichnet den durchschnittlichen Anteil bestandener Einzelkriterien, nicht den Anteil komplett erledigter Aufgaben. Die Ergebnisse zeigen damit eine erhebliche Lücke zwischen punktuellem Fortschritt und vollständiger Erfüllung eines zusammengesetzten Auftrags. [1] [2] [4]

Für Unternehmen ist diese Unterscheidung relevant, weil ein Agent eine Änderung teilweise korrekt umsetzen kann, während ein abhängiger Schritt, eine Interaktion oder eine geforderte Bewahrung des ursprünglichen Inhalts noch fehlt. Ein Durchschnittswert über Einzelkriterien kann solche unvollständigen Lieferungen weniger sichtbar machen als eine Kennzahl, die nur komplett erfüllte Aufgaben zählt. Das ist eine Interpretation der im Benchmark getrennt ausgewiesenen Kennzahlen, keine Aussage über die Leistung eines konkreten Unternehmenssystems. [2] [4]

Die Studie berichtet außerdem, dass alle zehn Endpunkte bei Repository-Aufgaben mit drei oder vier Änderungstypen niedrigere Kriteriumsquoten erreichten als bei Aufgaben mit einem oder zwei Typen. In der gepoolten Auswertung lag Strict Completion bei 65,4 Prozent für die Gruppe mit ein oder zwei Änderungstypen und bei 59,1 Prozent für die Gruppe mit drei oder vier. Die Gruppen umfassten 53 beziehungsweise 120 Aufgaben. [1] [2]

Die Autoren weisen darauf hin, dass sich die Aufgabengruppen in Anfrage und Kontext unterscheiden. Die Differenz ist deshalb ein beschreibendes Muster und kein kontrollierter Nachweis, dass allein die Zahl der Änderungstypen den Leistungsabfall verursacht. Auch bei der vollständigen Erfolgsquote ergibt sich kein entsprechender Abfall: Sie lag in den beiden Gruppen bei 9,1 beziehungsweise 9,7 Prozent. [2]

Agentisches Ausführen verändert die gemessene Leistung

Ein Hintergrund der Arbeit ist, dass die Art der Ausführung Benchmarkscores beeinflussen kann. Auf denselben 150 WebCompass-Edit-Aufgaben stieg die mittlere bewertete Feature-Vervollständigung für den Endpunkt qwen3.7-plus von 73,6 Prozent bei einer einmaligen Ausführung auf 95,1 Prozent mit agentischem Vorgehen. Rubrik, Bewertungsverfahren und Render-Pipeline blieben in diesem Vergleich gleich. [2] [3]

Dieser Vergleich zeigt, dass iterative Werkzeugnutzung die Messung in diesem konkreten Test erheblich verändern kann. Er ist jedoch kein direkter Leistungsvergleich zwischen WebCompass und Co-Design Bench: Die Benchmarks verwenden unterschiedliche Aufgabenpools und Protokolle. Die Co-Design-Ergebnisse beziehen sich ihrerseits auf zehn Endpunkte unter einem gemeinsamen Agenten-Setup. [1] [2] [3]

Für die Interpretation betrieblicher Tests folgt daraus: Ein Modellname allein beschreibt die getestete Leistung nicht vollständig. Werkzeuge, Ausführungsregeln und die Möglichkeit, eine Anwendung wiederholt zu untersuchen und zu korrigieren, gehören ebenfalls zum Messkontext. Das ist eine methodische Schlussfolgerung aus dem beschriebenen Vergleich, keine Aussage darüber, welche Konfiguration für einen bestimmten Produktivbetrieb geeignet ist. [2] [3]

Was der Benchmark für die Auswahl von Coding-Agenten leisten kann

Die Kombination aus verdeckten Kriterien, ausführbarer Ausgangsanwendung und Browserprüfung zielt auf eine Lücke zwischen vorhandenem Code und tatsächlich nutzbarem Verhalten. Ein Element im Quellcode belegt für sich genommen nicht, dass eine Funktion erreichbar ist oder sich korrekt verhält; der Prüfablauf verlangt deshalb zusätzliche Laufzeitbelege. [3]

Für Unternehmen kann diese Art der Messung als Ergänzung zu Tests einzelner Funktionen dienen: Bei einer Evaluierung lässt sich nicht nur fragen, ob ein Agent bestimmte Änderungen erzeugt, sondern auch, ob alle miteinander verbundenen Anforderungen einer Aufgabe erfüllt sind. Gerade bei Änderungen, die Oberfläche, Zustand und Datenfluss verbinden, sollte die vollständige Aufgabenerfüllung neben der Kriterienquote betrachtet werden. Diese Einordnung leitet sich aus den Metriken und dem Aufgabendesign ab; die Studie belegt nicht, dass ein bestimmtes Beschaffungs- oder Freigabeverfahren dadurch überlegen wäre. [2] [3]

Die Ergebnisse sollten zugleich nicht als allgemeine Aussage über alle Softwareentwicklungsaufgaben gelesen werden. Co-Design Bench konzentriert sich auf Revisionen bestehender Webanwendungen und Frontend-Repositories sowie auf die dort festgelegten Aufgaben und Kriterien. Die gemessenen Werte belegen daher weder zuverlässige Leistung in beliebigen Codebasen noch die Eignung eines Modells für den unbeaufsichtigten Einsatz in einer Produktionsumgebung. [1] [3]

Umfang und bereitgestellte Datensätze auseinanderhalten

Bei der Einordnung der verfügbaren Materialien ist eine Abgrenzung wichtig: Die veröffentlichte Evaluation beschreibt den vollständigen Benchmark mit 273 Aufgaben, darunter 100 ME-Aufgaben. Die Projektseite weist für den verlinkten Hugging-Face-Datensatz dagegen 96 ME-Aufgaben aus; die Einreichungsseite bezeichnet ME-96 als einen eigenen Teilumfang mit 521 Kriterien. Diese Angaben sollten nicht mit dem vollständigen Evaluationsumfang gleichgesetzt werden. [1] [3] [4]

Die Projektseite zeigt außerdem einzelne Agentenläufe, darunter eine archivierte Videoaufgabe, bei der ein Modell sechs von sechs Kriterien bestand. Das illustriert einen konkreten Arbeitsablauf, ist aber kein Beleg für die benchmarkweite Erfolgsquote; diese liegt bei der Full-Pass-Rate des stärksten Endpunkts bei 26,4 Prozent über alle Aufgaben. [1] [4]

Insgesamt macht Co-Design Bench damit eine wichtige Bewertungsfrage explizit: Wie oft erfüllt ein Agent einzelne Anforderungen – und wie oft liefert er eine Änderung, die alle Kriterien einer realitätsnahen Aufgabe erfüllt? Die gemeldeten Resultate zeigen, dass beide Antworten deutlich auseinanderliegen können. Für belastbare betriebliche Entscheidungen müssen sie deshalb zusammen mit Aufgabenbereich, Bewertungsverfahren und Ausführungs-Setup betrachtet werden. [1] [2] [3]

Quellen

1. [1] Paper page - Co-Design Bench: Multimodal Collaborative Coding Evaluation for Agentic Models — https://huggingface.co/papers/2610.35138 (abgerufen am 2026-10-30)
2. [2] Co-Design Bench: Multimodal Collaborative Coding Evaluation for Agentic Models | alphaXiv — https://www.alphaxiv.org/abs/2610.35138 (abgerufen am 2026-10-30)
3. [3] Co-Design Bench:Multimodal Collaborative Coding Evaluation for Agentic Models — https://arxiv.org/html/2610.35138 (abgerufen am 2026-10-30)
4. [4] Co-Design Bench · Multimodal collaborative coding evaluation — https://codesignbench.github.io/ (abgerufen am 2026-10-30)