„Most existing coding benchmarks fail to capture these gaps and tend to be saturated quickly.“ Das schreibt das Cognition-Team im Blogpost zur zweiten Generation seines Coding-Benchmarks. Bemerkenswert ist der Satz, weil er von einem Anbieter kommt, der selbst solche Benchmarks baut – und weil er ein Problem benennt, das viele Teams kennen: Die Prüfungen sind zu leicht geworden. Ist eine Aufgabe vollständig durchspezifiziert, lösen gute Modelle sie zuverlässig. Gemessen wird dann nur ein Ausschnitt der Arbeit, nicht die Arbeit selbst.
Ein passender Vergleich ist die Probearbeit in einer fremden Werkstatt. Man kann jemandem eine exakte Zeichnung in die Hand drücken und prüfen, ob das Werkstück am Ende den Maßen entspricht. Sauber, fair – und es sagt fast nichts darüber, ob die Person in der echten Werkstatt bestehen würde, wo die Zeichnung unvollständig ist, wo es Konventionen gibt, die nirgends stehen, und wo ein Meister am Ende das Teil in der Hand hält und entscheidet, ob es eingebaut wird. FrontierCode 2.0 versucht diesen zweiten Teil zu messen. Nicht, ob der Code läuft, sondern ob ein Maintainer ihn mergen würde.
Was FrontierCode unter Mergeability versteht
„Code Mergeability“ ist der Kern des Ansatzes. Gemeint ist die Frage, ob ein eingereichter Patch die Review-Hürde eines echten Projekts nehmen würde: korrekt, sauber integriert, im Stil des Repositories, mit Tests, die tatsächlich Fehler fangen. Das Cognition-Team beschreibt drei Bereiche: funktionale Korrektheit, das Auslegen und Erweitern eines knappen Prompts sowie vernünftige Design- und Scope-Entscheidungen, damit die Änderung sich reibungslos in eine bestehende Codebasis einfügt.
Die Aufgaben stammen nicht von einem Benchmark-Team, das sich Code ausdenkt, sondern von mehr als zwanzig Open-Source-Entwicklern, die jeweils über vierzig Stunden pro Aufgabe investiert haben – aus den Repositories, die sie selbst betreuen. Das ist ein Unterschied zu synthetischen Aufgaben. Wer ein Repository seit Jahren pflegt, weiß, welche Änderung durchgeht und welche im Review zerrissen wird. Dieses Wissen steckt in den Bewertungskriterien. Ein Modell besteht die Aufgabe also nicht dadurch, dass es die Tests grün bekommt, sondern dadurch, dass es die impliziten Regeln des Projekts trifft.
Drei Verschiebungen: mehr Repositories, strengere Kriterien, größere Diffs
FrontierCode 2.0 übernimmt die Methodik des Vorgängers und schraubt an drei Stellen nach. Erstens die Breite: Die Aufgaben kommen aus 55 Prozent mehr Repositories und decken mehr Kategorien ab, darunter Sicherheitspatches und Performance-Optimierungen. Das ist kein Detail: Ein Benchmark sagt nur dann etwas über den Alltag aus, wenn er dessen Verteilung einigermaßen abbildet. Ein Repository mit überwiegend CRUD-Code stellt andere Anforderungen als eine Bibliothek, in der ein einziger Off-by-one-Fehler eine Sicherheitslücke öffnet.
Zweitens die Ansprüche: Die Zahl der blockierenden Kriterien ist um 43 Prozent gestiegen, also um jene Prüfpunkte, die bei Verletzung sofort zu null Punkten führen. Drittens der Umfang: Verglichen mit FrontierCode 1.1 ändern die Referenzlösungen im Schnitt 67 Prozent mehr Dateien und 89 Prozent mehr Zeilen, und zwar in Codebasen, die selbst 25 Prozent größer sind. Eine Aufgabe besteht damit nicht mehr darin, eine Funktion zu ergänzen, sondern einen zusammenhängenden Eingriff über mehrere Dateien hinweg sauber zu ziehen.
Dazu kommt ein Punkt, der leicht überlesen wird: die Qualitätskontrolle der Aufgaben selbst. In 80 Prozent der Fälle weicht die Referenzlösung inzwischen vom ursprünglichen Upstream-Pull-Request ab, gegenüber 60 Prozent in Version 1.0. Die Prüfer haben also nicht einfach übernommen, was im Projekt ohnehin gemergt wurde, sondern nachgebessert. In einer der automatisierten Prüfungen fand ein Agent eine Sicherheitslücke in der Upstream-Implementierung; nach menschlicher Prüfung wurde sie an die Maintainer gemeldet. Die Werkzeuge, die geprüft werden, prüfen inzwischen mit.
Die Ergebnisse: 45 Prozent an der Spitze
Claude Opus 5.5 liegt mit 45,5 Prozent vorn, GPT-6 Astra folgt mit 42,8 Prozent. Danach klafft eine Lücke: Grok 4.7 kommt auf 28,6 Prozent, Gemini 4 Argon auf 26,3, Muse Wonder 1.0 auf 24,3, SWE-2 auf 23,9. DeepSeek V4.1 Flash erreicht 19,3 Prozent, Kimi K3 landet bei 17,7 Prozent. Zum Vergleich dieselben Modelle unter FrontierCode 1.1: Dort lagen sie zwischen 54,6 und 43,9 Prozent. Der Rückgang ist kein Rückschritt der Modelle, sondern der Preis für strengere Kriterien.
In FrontierCode 1.1 lagen die Spitzenmodelle nur gut einen Punkt auseinander, jetzt trennt sie ein sichtbarer Abstand, und nach unten wird die Staffelung deutlich. Ein Benchmark, der alle Modelle auf einem Haufen abbildet, sagt wenig aus. Einer, der Abstufungen zeigt und an der Spitze bei 45 Prozent stehen bleibt, ist noch nicht gesättigt – für ein Werkzeug, das Fortschritt messen soll, eine gute Nachricht. Ebenfalls erwähnt: Auf der Kosten-Leistungs-Kurve liegen Opus 5.5 am oberen Ende, aber auch günstige Modelle wie Luna, Haiku und Sol – wobei GPT-6.1 Sol laut den Autoren ein besonders gutes Verhältnis von Ergebnis zu Preis zeigt. Für offene Modelle, insbesondere westliche, sehen sie dagegen noch viel Luft nach oben.
Thoroughness: der Blockertyp, der am häufigsten reißt
Eine Kategorie, die die Autoren „Thoroughness“ nennen, erklärt am meisten – Gründlichkeit. Gemeint sind Korrektheitsbedingungen, die ein Agent aus der Aufgabe und der bestehenden Codebasis ableiten kann, auch wenn sie niemand ausdrücklich hinschreibt. Das Standardbeispiel: Der Prompt nennt einen Fehler in einem Codepfad, derselbe Fehler steckt aber auch im Nachbarpfad. Ein gründlicher Agent findet beide. Oder: Gefragt ist neue Funktionalität für einen Eingabetyp, und ein aufmerksamer Bearbeiter merkt, dass ähnlicher Code daneben schon andere Typen behandelt – und unterstützt sie mit.
Genau hier scheitern die Modelle am häufigsten. Die Zahl der Thoroughness-Blocker ist von 168 auf 501 gestiegen, also um den Faktor drei, und ihr Anteil an allen Blockern ist deutlich gewachsen. Die Fehlerquote in dieser Kategorie liegt bei 19,2 Prozent, vorher 11,7 – und sie ist über alle Effort-Stufen hinweg die höchste, noch vor der Kernfunktionalität mit 14,9 Prozent. Darum geht es: eine Lösung, die den Prompt oberflächlich erfüllt und dabei erhebliche funktionale Schwächen hinterlässt oder neue einführt. Wer regelmäßig KI-generierte Pull Requests reviewt, wird das wiedererkennen.
Mehr Reasoning kann schlechtere Ergebnisse liefern
Zweiter Befund: Mehr Rechenzeit beim Nachdenken ist nicht immer besser. FrontierCode ist laut den Autoren einer der wenigen Benchmarks, bei denen zusätzlicher, korrekter Code den Score nicht zwingend hebt – Modelle können bei höherem Reasoning-Aufwand schlechter abschneiden. Der Mechanismus ist gut dokumentiert: Die Pass-Raten auf Implementierungskriterien steigen mit dem Aufwand, etwa bei Claude Opus 5 von 79,3 auf 83,0 Prozent. Die Pass-Raten auf Scope-Kriterien fallen gleichzeitig, im selben Beispiel von 69,2 auf 51,1 Prozent. Modelle schreiben bei mehr Nachdenken mehr Code und fassen mehr Dateien an, auch wenn das nicht hilft.
Die Autoren haben darauf reagiert und ihre Scope-Kriterien gelockert, weil sie bei der Untersuchung einige überraschend vernünftige Lösungen fanden, die an zu engen Vorgaben scheiterten. Die Fehlerquote in dieser Kategorie sank dadurch im Schnitt von 9,0 auf 3,8 Prozent. Nebenbei nennen sie zwei weitere Effekte: häufigeres „Cheating“ bei hohem Aufwand, wobei Modelle versehentlich den Lösungs-Commit ziehen, und schlichtes Überdenken, bei dem sich ein Modell in eine Fehlinterpretation der Anforderung hineinredet. Wer schon einmal erlebt hat, wie ein Agent eine einfache Änderung in einen Umbau verwandelt hat, kennt den Effekt.
Was das für den Einsatz von KI in der Softwareentwicklung bedeutet
Ein Benchmark bleibt ein Proxy, kein Urteil. FrontierCode 2.0 misst einen Ausschnitt – Mergeability in betreuten Open-Source-Repositories – und tut das mit einem Aufwand, den die meisten Unternehmen nicht betreiben können. Die Richtung ist trotzdem relevant, weil sie den Blick verschiebt. Nicht „löst das Modell die Aufgabe“ ist die interessante Frage, sondern „würde diese Änderung im Review bestehen“. Und diese Frage stellt sich in jedem Team, das KI in der Softwareentwicklung einsetzt, jeden Tag aufs Neue.
Für dich heißt das: Ein knapper Prompt ist keine faire Prüfung, sondern eine Zumutung mit Ansage. Wenn du willst, dass ein Agent die Konventionen deines Repositories trifft, musst du sie sichtbar machen – durch bestehenden Code in der Nähe, durch klare Namen, durch Tests, die wirklich Fehler fangen, und durch eine Aufgabenbeschreibung, die den Kontext mitliefert statt nur das Ziel. Die 45 Prozent an der Spitze sagen nicht, dass Modelle schlecht sind. Sie sagen, dass mehr als die Hälfte der Aufgaben in einem anspruchsvollen Setting nicht mergebar gelöst wird – und dass die Lücke zwischen „sieht gut aus“ und „ist wirklich fertig“ die eigentliche Baustelle ist.
Der Beitrag von FrontierCode 2.0 liegt nicht in den Ranglisten. Er liegt in der Verschiebung des Maßstabs: von der vollständigen Spezifikation zur unvollständigen, vom grünen Test zur Review-Fähigkeit, von der einzelnen Datei zum Eingriff über mehrere Dateien. Unbequemer zu messen, unbequemer zu lesen. Aber so findet die Arbeit tatsächlich statt – in einer fremden Werkstatt, mit einer Zeichnung, die Lücken hat, und einem Meister, der am Ende das Teil in die Hand nimmt.
Quelle: cognition.com
