Android Bench 2.0 demütigt den Agent-Hype: Bei Long-Horizon Tasks knallt die Pass-Rate auf rund 28 Prozent, während Original-Tasks noch bei etwa 91 Prozent „grün“ leuchteten. Der Benchmark zeigt, warum Binary Pass für Wochenarbeit ein schlechter Alltagsmaßstab ist — und Continuous Score ehrlicher misst, wie weit ein Agent wirklich kommt. Spoiler: Wer nur die 91-Prozent-Welt kennt, unterschätzt die 28-Prozent-Welt gründlich.
Fail. Sie haben den Compose-Refactor durchgezogen, die Datenbank-Tabellen stehen, neunzig Prozent der Requirements sind erfüllt — und dann fällt eine einzige Edge-Case-Assertion. Binary sagt: null Prozent. Wochenarbeit demütigt. Der Leaderboard-Eintrag bleibt rot, obwohl das Bastelprojekt fast fertig war. Im Ernst: Wer das schon mal in einer echten Codebasis erlebt hat, weiß, wie unfair sich so eine Note anfühlt.
Genau dieses Szenario schildert Matthew McCullough im Android Developers Blog zu Android Bench 2.0 — und es ist der Grund, warum der Benchmark jetzt neu bewertet. Die kurze Version: Long-Horizon Tasks (LHT) plus Continuous Scoring statt nur Binary Pass. Nerd-Alarm: Der Leaderboard-König der alten Welt sieht auf einmal ziemlich nackt aus.
Stellen Sie sich den Leaderboard-Eintrag wie einen Kollegen vor, der nach einer Woche Pair-Programming nur die letzte Stunde bewertet. Alles davor? Irrelevant. Binary Pass ist genau dieser Kollege. Continuous Score wäre der Mentor, der den Diff liest, die Architektur würdigt und trotzdem den fehlenden Test markiert. Beides ist streng — aber nur eines ist fair für Long-Horizon Tasks.
Das ist der Winkel dieses Textes: Nicht „welche KI gewinnt“, sondern warum 28 Prozent Pass ehrlicher sein können als 91 Prozent in einer leichteren Welt. Der Benchmark demütigt den Hype, indem er Aufgaben stellt, die sich anfühlen wie echte Sprint-Arbeit statt wie ein Coding-Quiz.
Wir bei digital-magazin.de lesen solche Vendor-Zahlen mit dem gleichen Misstrauen wie Sie: Was bedeutet „grün“, wenn die Aufgabe eigentlich eine Woche Engineer-Zeit kostet? Und warum feiert jemand 28 Prozent Pass, wenn 90 Prozent Completion noch so aussah, als sei alles in Ordnung?
Was Android Bench 2.0 eigentlich misst
Android Bench war schon in der ersten Iteration ein strenger Maßstab dafür, wie Sprachmodelle bei echten Android-Aufgaben helfen. Die frühe Welt war klein: inkrementelle Fixes, Bugfixes, kleinere Feature-Requests in bestehenden Repos. Das spiegelte wider, was Modelle damals konnten — und wie Nutzende sie einsetzten.
Android Bench 2.0 hebt die Latte. Laut Blog kommen Long-Horizon Tasks dazu: Aufgaben, die eine Engineer mehrere Tage bis eine Woche kosten. Dazu zählen Dependency-Upgrades, neue Features, Apps from scratch und der Umbau einer Cross-Platform-App nach Android. Parallel startet eine agentische Evaluation — zunächst mit Agents der jeweiligen Modell-Anbieter — und die Methodik wird am Harbor-Framework ausgerichtet.
klingt einfach, ist es aber nicht. Der Benchmark personifiziert hier den ungeduldigen Tech-Lead: Er will nicht mehr nur wissen, ob der Agent den Tippfehler in Zeile 42 findet. Er will wissen, ob der Agent die Woche übersteht, ohne die Architektur zu zerlegen.
Dazu kommen multimodale Aspekte und eine feinere Bewertung. Wer nur Binary kennt, denkt in Ampeln. Wer Continuous Score kennt, denkt in Teilpunkten — und das ist der Kern dieser Geschichte.
Binary Pass: die Klausur, die nur 1 oder 0 kennt
Alltagsvergleich: Binary Scoring ist wie eine Klausur, in der es nur bestanden oder durchgefallen gibt. Keine Teilpunkte. Kein „fast“. Eine falsche Randbedingung — und die ganze Arbeit zählt null.
Das Blog-Beispiel ist brutal klar: Ein Agent refaktoriert 40 Screens nach Jetpack Compose, richtet Datenbank-Tabellen ein und erfüllt 90 Prozent der Anforderungen. Eine einzige Edge-Case-Assertion scheitert. Binary: 0 Prozent. Die architektonische Leistung verschwindet hinter einer Ampel.
Für kurze Tasks mag das noch okay sein. Für Wochen-Tasks ist es ein schlechter Alltagsmaßstab. Sie kennen das aus dem Alltag: Das Feature läuft lokal, der Design-Review nickt, und dann knallt ein CI-Check wegen einer Assertion, die niemand auf dem Schirm hatte. Binary sagt Fail. Continuous würde fragen: Wie weit sind Sie gekommen?
Spoiler: Genau deshalb zieht Android Bench 2.0 Continuous Scoring ein. Funktionalität, visuelle Treue, keine Regressionen — und objektive Penalties, wenn Eval-Instruktionen oder strukturelle Vorgaben verletzt werden. Der Completion-Score soll ein sinnvolleres Signal liefern, sowohl für Modellentwicklung als auch für Lesende, die verstehen wollen, wie KI im Alltag hilft.
Warum nervt Binary so sehr bei Wochen-Tasks? Weil der Fortschritt asymmetrisch ist. Die ersten 70 Prozent fühlen sich machbar an: Screens umbauen, Tabellen anlegen, Happy Path grün. Die letzten 30 Prozent sind Edge Cases, visuelle Treue, Regressionen in Ecken, die niemand täglich anfasst. Binary behandelt 90 Prozent fertig wie 0 Prozent fertig. Das ist mathematisch korrekt für Pass/Fail — und praktisch unfair für die Einschätzung von Agent-Fähigkeit.
Sie kennen das aus Reviews: „Funktioniert fast“ ist kein Merge-Kriterium. Aber es ist ein Lernsignal. Continuous Score macht dieses Lernsignal messbar. Binary versteckt es hinter der Ampel.
Für Lesende heißt das: Wenn ein Vendor oder ein Leaderboard nur Pass-Raten zeigt, fragen Sie nach der Task-Länge. 91 Prozent auf kurzen Tasks und 28 Prozent auf LHT beschreiben verschiedene Jobs. Wer das vermischt, baut falsche Erwartungen an den Agent im Alltag.
Nerd-Alarm: Eine Assertion ist oft der kleinste Teil der Arbeit — und der größte Teil der Note. Genau deshalb ist das Compose-Beispiel im Blog so wirksam. Es ist kein theoretisches Fail. Es ist das Fail, das Sie in CI schon gesehen haben.
| Maßstab | Original-Tasks (Android Bench) | Long-Horizon Tasks (2.0) | Alltagsbild |
|---|---|---|---|
| Pass-Rate (Binary) | rund 91 % | höchste LHT-Pass-Rate rund 28 % | Klausur nur 1 oder 0 |
| Continuous Score | weniger zentral in der alten Lesart | Funktionalität, visuelle Treue, keine Regressionen; Penalties bei Instruktions-/Strukturabweichung | Teilpunkte statt Ampel |
| Beispiel Compose-Refactor | — | 40 Screens + DB + 90 % Requirements, eine Assertion fail → Binary 0 % | Wochenarbeit demütigt |
Die Tabelle lügt nicht: Der Leaderboard-Abstand zwischen alter und neuer Welt ist kein Feinschliff. Es ist ein Realitätscheck.
28 Prozent Pass — und warum das trotzdem eine Story ist
Die höchste Pass-Rate bei Long-Horizon Tasks liegt laut Blog bei rund 28 Prozent. Bei den Original-Tasks lag die Pass-Rate bei etwa 91 Prozent. Das ist der Satz, den Sie zweimal lesen sollten.
Warum feiert man 28 Prozent? Weil die Aufgaben härter sind. Weil Binary bei Wochenarbeit gnadenlos ist. Weil Continuous Score zeigt, dass Frontier-Modelle oft weit kommen — und trotzdem an der letzten Assertion scheitern. Die 91-Prozent-Welt war die Welt der inkrementellen Fixes. Die 28-Prozent-Welt ist die Welt der Woche.
Nerd-Alarm: Wer nur die alten Zahlen kennt, unterschätzt systematisch, wie schwer Long-Horizon Tasks für Agents sind. Der Benchmark lacht hier nicht höhnisch — er zuckt mit den Schultern und sagt: So sieht echte Android-Arbeit aus, wenn Sie Dependencies upgraden, Features bauen oder eine App from scratch hochziehen.
Wir bei digital-magazin.de halten das für den ehrlicheren Rahmen: Nicht „das Modell ist plötzlich dumm geworden“, sondern „die Prüfung ist endlich so schwer wie der Job“. Wer Agent-Workflows mit Tools wie denen hinter Cursor Composer 2 oder agentischem Coding bei GitHub Copilot und Grok vergleicht, sollte genau diesen Unterschied im Kopf haben: kurze, grüne Tasks versus lange, demütigende Wochen.
Die kurze Version: 28 Prozent Pass ist kein Marketing-Fail. Es ist die ehrliche Note für eine härtere Klausur.
Feiern Sie 28 Prozent also nicht wie einen Marketing-Sieg. Feiern Sie die Methodik, die den Abstand sichtbar macht. Der Leaderboard-König der LHT-Welt sitzt auf einem Thron aus Demut: Selbst das beste gemessene Pass-Ergebnis bleibt weit unter der alten 91-Prozent-Komfortzone.
Continuous Score erklärt den scheinbaren Widerspruch. Ein Lauf kann Completion hoch halten und trotzdem Binary failen. Der Agent kommt weit — und scheitert am letzten Meter. Für Research ist das Gold. Für Nutzende auch: Sie sehen, ob Sie einen „fast fertigen“ Partner haben oder einen, der früh abstürzt.
Im Ernst: Die 28-Prozent-Welt ist die Welt, in der Agents Wochenarbeit versuchen. Die 91-Prozent-Welt war die Welt, in der Agents kleine Diffs landen. Beide Zahlen sind laut Blog valide — nur nicht austauschbar. Wer sie austauschbar liest, unterschätzt LHT und überschätzt den Alltag.
Bastelprojekt-Perspektive: Wenn Sie intern Agents evaluieren, bauen Sie zwei Spurweiten. Kurze Tasks für Smoke. Lange Tasks für Wahrheit. Android Bench 2.0 macht genau diese Spurtrennung öffentlich sichtbar.
Continuous Score: Teilpunkte statt Ampel
Continuous Scoring rechnet zusammen, wie weit der Agent gekommen ist. Laut Blog fließen Funktionalität, visuelle Treue und das Vermeiden von Regressionen ein. Dazu kommen objektive Abzüge, wenn der Lauf von Eval-Instruktionen oder strukturellen Constraints abweicht.
Im Leaderboard können Lesende laut Blog in die Model-Card-Ansicht klicken: Pass-Rate, Completion-Rate, durchschnittliche Kosten pro Modell und pro Task. Der Benchmark wird damit zum Gesprächspartner statt zur Ampel. Er sagt nicht nur „bestanden“, sondern „so weit bist du gekommen — und das hat es gekostet“.
Alltagsvergleich nochmal: Binary ist die Klausur ohne Teilpunkte. Continuous ist die Korrektur, die Ihnen sagt, dass die Argumentation stark war, die Fußnote aber falsch. Für Modellentwicklung ist das ein brauchbares Signal. Für Nutzende auch: Sie sehen, ob ein Agent eher „fast fertig“ oder „komplett daneben“ liegt.
Klingt einfach, ist es aber nicht. Denn Continuous Score verführt dazu, 80 Prozent Completion mit „fertig genug“ zu verwechseln. Im Ernst: Für Production-Android ist „fast“ oft noch Fail — nur eben ein anderer Fail als Binary 0. Der Punkt der 2.0-Methodik ist Transparenz, nicht Bequemlichkeit.
Wie setzt sich Continuous laut Blog zusammen? Funktionalität. Visuelle Treue. Keine Regressionen. Dazu Penalties, wenn Eval-Instruktionen oder strukturelle Constraints verletzt werden. Das ist kein weiches „Gefühl“, sondern ein Score mit Abzügen. Der Completion-Wert soll sagen: Wie nah am Ziel — unter den Regeln der Eval.
Die Model-Card-Ansicht im Leaderboard ergänzt Pass und Completion um Kosten. Das ist die Alltagsfrage hinter dem Nerd-Spaß: Was kostet ein Lauf, der 80 Prozent Completion liefert und trotzdem Binary failt? Für Teams, die Agents budgetieren, ist das relevanter als eine einzelne Ampel.
Klingt einfach, ist es aber nicht. Continuous Score braucht Disziplin in der Interpretation. Hohe Completion ist kein Freifahrtschein für Production. Niedrige Pass-Rate ist kein Beweis, dass Agents nutzlos sind. Beides zusammen zeichnet das Bild: stark bei Mustern, schwach bei der letzten Härte.
Die kurze Version: Teilpunkte machen den Fail lesbar. Ampeln machen ihn absolut. Für Wochen-Tasks brauchen Sie Lesbarkeit.
Was Modelle können — und wo die Woche sie demütigt
Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptDeveloper monitor showing a blurred continuous score bar instead of a pass-fail light, sticky notes beside keyboard, soft desk lamp, photorealistic, no logos, no readable text, 16:9Über Modellstufen hinweg, so der Blog, sind Modelle besser darin, neuen Code zu schreiben als bestehenden Code zu refaktorieren. Refactors und Migrationen werden kniffliger, weil Erfolg von Architekturkomplexität abhängt — nicht von Codevolumen.
Stark sind deterministische Transformationen: Java nach Kotlin, Retrofit nach Ktor, das Einziehen einer ViewModel-Schicht. Solche Muster wenden Modelle laut Blog konsistent an — auch über 125+ Dateien und 8000+ Zeilen Code. Das sind Blog-Beispielzahlen, keine eigenen Messungen. Aber sie zeigen die Richtung: Wenn das Muster klar ist, skaliert der Agent über die Dateimenge.
Schwach wird es bei Runtime-Validierung (etwa fehlenden Dependency-Injection-Graphen), bei Breaking Changes in Frameworks oder bei Wissenslücken zu unveröffentlichten Libraries. Cross-Platform-Port nach Android bleibt offen: Kein Modell erreicht 100 Prozent Pass; Frontier-Modelle kommen laut Blog höchstens auf rund 80 Prozent Completion.
Spoiler: 80 Prozent Completion klingt nach viel. Binary Pass bei denselben Tasks liegt trotzdem tiefer. Genau deshalb ist Continuous Score ehrlicher — und genau deshalb bleibt Binary als alleiniger Alltagsmaßstab gefährlich. Wer nur Pass/Fail sieht, unterschätzt, wie nah (oder fern) der Agent am Ziel war.
Wer sich mit Sub-Agent-Architekturen beschäftigt — etwa im Umfeld von GPT Mini/Nano und Sub-Agents — erkennt hier denselben Pattern-Bruch: Deterministische Schritte laufen, Architekturentscheidungen und Runtime-Fallen brechen den Lauf.
Neu schreiben versus Refactor: Das ist die praktische Leitplanke aus dem Blog. Greenfield und klar definierte Features spielen Modellen in die Karten. Bestehende Architektur, Legacy-Patterns, verwobene Module — dort steigt die Komplexität schneller als die Dateizahl. 8000 Zeilen deterministischer Umbau können leichter sein als 800 Zeilen Architektur-Migration. Volumen ist nicht Schwierigkeit.
Java nach Kotlin, Retrofit nach Ktor, ViewModel-Schicht: Das sind Muster mit Lehrbuch-Charakter. Agents wenden sie laut Blog konsistent an, selbst über 125+ Dateien. Für Teams heißt das: Mechanische Migrationen sind das beste Bastelprojekt für Agent-Hilfe. Architektur-Umbauten bleiben Menschenarbeit mit Agent-Assistenz — nicht umgekehrt.
Runtime-Fallen sind der Kill-Switch. Fehlende Dependency-Injection-Graphen zeigen sich oft erst beim Lauf. Breaking Framework Changes verlangen Wissen, das nicht in jedem Trainingsschnitt steckt. Unveröffentlichte Libraries sind Wissenslücken mit Ansage. Cross-Platform nach Android: kein Modell 100 Prozent Pass, Frontier maximal rund 80 Prozent Completion. Spoiler: Completion ohne Pass ist genau die Situation, in der Continuous Score seinen Job macht.
Wer Agents im Alltag einsetzt, sollte diese Landkarte kennen. Deterministisch: stark. Architektonisch und runtime-lastig: demütigend. Der Benchmark personifiziert hier den Senior, der sagt: „Toll, dass der Diff groß ist — aber kompiliert die DI-Graph?“
Agent-Evals: Harness zählt mit
Android Bench 2.0 nimmt Agents in die Evaluation auf. Startpunkt laut Blog: neue Modelle gegen LHTs mit Agents der jeweiligen Anbieter. Beispiele für das Eval-Setup: GPT 5.6 Sol auf Codex, Gemini 3.8 Flash auf Google Antigravity. Das Paar zeigt, wie Harness-Design Entwickler-Outcomes beeinflusst — etwa durch Prompt-Caching und kompaktes Tool-Windowing mit Token-Reduktionen.
Das ist keine Produktstory zu Claude Code Projects, Agents API oder Gemini Live. Es ist eine Eval-Notiz: Modell und Harness gehören zusammen, wenn Sie agentische Workflows bewerten. Der Benchmark personifiziert hier den Laborleiter, der nicht nur die Rohstoffqualität misst, sondern auch die Werkbank.
Wer Session- und Host-Kontexte in der IDE organisiert — Stichwort VS Code Agent Host und Folder-zu-Session-Links — weiß, dass der Rahmen den Lauf verändert. Android Bench 2.0 macht diesen Rahmen messbar, zumindest in den beschriebenen Pairings.
Die kurze Version: Ein Agent ohne Harness-Blick ist nur halb bewertet. Binary ohne Continuous Score auch.
Die genannten Pairings — GPT 5.6 Sol auf Codex, Gemini 3.8 Flash auf Antigravity — sind Eval-Setups, keine Kaufempfehlungen. Sie zeigen den Methodik-Schritt: Agent und Modell gemeinsam messen. Harness-Details wie Prompt-Caching und kompaktes Tool-Windowing können Token sparen und Outcomes verschieben. Wer nur das Rohmodell bewertet, missachtet die Werkbank.
Das Blog kündigt an, Kombinationen aus Modellen und Agents später breiter zu zeigen. Für Lesende ist der Takeaway jetzt schon klar: Vergleichen Sie nicht „Modell A vs. Modell B“ in Isolation, wenn Ihr Alltag Agent plus Tools plus Kontextfenster ist. Die Eval folgt dem Alltag — langsam, aber erkennbar.
Der Text bleibt beim Benchmark. Alles andere wäre Ablenkung vom Fail, der diese Geschichte trägt.
Leaderboard: neue Namen, harte Note
Das Leaderboard wächst. Neu dabei laut Blog unter anderem: Gemini 3.8 Flash, Gemini 3.7 Flash, OpenAI GPT-6, Anthropic Fable 5.1, Kimi K3 und Qwen 3.8 Max. An der Spitze steht GPT-6 Astra mit 28 Prozent Pass — das ist die Leaderboard-Notiz, mehr nicht. Kein Produktpitch, keine „beste KI der Woche“.
28 Prozent als Top-Wert ist die Pointe. Der Leaderboard-König der LHT-Welt trägt keine goldene Krone aus der 91-Prozent-Ära. Er trägt die ehrliche Note einer härteren Prüfung. Nerd-Alarm: Wenn „bester Eintrag“ bei 28 Prozent Pass liegt, ist das kein Versagen der Modelle allein — es ist der Beweis, dass Long-Horizon Tasks die alte Ampel-Logik sprengen.
Wir bei digital-magazin.de lesen solche Leaderboards als Orientierung, nicht als Kaufberatung. Vendor-Zahlen sind Vendor-Zahlen. Eigene Messungen haben wir hier nicht. Was zählt: Die Methodik erklärt, warum die alten 91 Prozent und die neuen 28 Prozent verschiedene Welten beschreiben.
Neue Einträge bedeuten frische Vergleichspunkte — und eine neue Hierarchie unter härteren Regeln. GPT-6 Astra mit 28 Prozent Pass an der Spitze ist die Leaderboard-Notiz. Punkt. Kein Pitch, keine Feature-Liste, keine „nächste Generation“-Rhetorik.
Daneben Gemini 3.8/3.7 Flash, GPT-6, Fable 5.1, Kimi K3, Qwen 3.8 Max: Namen ändern sich schneller als Methodiken. Was bleibt, ist die LHT-Härte. Wenn der Top-Pass bei rund 28 Prozent liegt, ist jede Marketing-Ampel aus der 91-Prozent-Ära unter Verdacht, die falsche Klausur zu zitieren.
Leaderboards gehören am liebsten immer mit Task-Definition gelesen. Ohne Task-Länge und Scoring-Art ist eine Prozentzahl Dekoration. Android Bench 2.0 liefert beides — und genau deshalb ist 28 Prozent hier eine Story wert.
| Task-Welt | Pass-Rate (Binary, Blog) | Was der Score verschluckt |
|---|---|---|
| Original-Tasks | ~91 % | Kleinere, inkrementelle Änderungen wirken „grün“ |
| Long-Horizon Tasks | ~28 % (höchste) | 90 % Requirements + eine Assertion fail = Binary 0 % |
| Cross-Platform → Android | kein Modell 100 % Pass | Frontier max. ~80 % Completion |
Fail bleibt Fail — aber Continuous Score sagt Ihnen wenigstens, wie nah Sie am Ziel waren, bevor die Ampel umschlug.
Harbor, Feedback, Bastelprojekt Benchmark
Android Bench 2.0 richtet die Methodik am Harbor-Framework aus. Das klingt nach Infrastruktur-Detail, ist aber Teil der Glaubwürdigkeit: Eval-Frameworks sollen vergleichbar und nachvollziehbar sein. Feedback läuft über GitHub — das Repo android-bench/android-bench ist die Adresse für Hinweise, nicht die Quelle erfundener 2.0-Zahlen.
Das Repo beschreibt Android Bench als Framework, um LLMs an Android-Entwicklungsaufgaben zu messen: Codebasen verstehen, Patches erzeugen, Android-spezifische Probleme lösen. Für Lesende heißt das: Der Benchmark ist ein öffentliches Bastelprojekt mit Feedback-Kanal — kein geschlossenes Marketing-Dashboard.
Im Ernst: Wenn Sie die Zahlen anzweifeln, ist der richtige Ort nicht ein Kommentar unter einem Screenshot, sondern Issues und Diskussion am Repo. Der Leaderboard-König darf kritisiert werden; die Methodik auch.
Was Android Bench 2.0 laut Blog liefern will, ist ein robusteres Umfeld: Long-Horizon Tasks, multimodale Evaluation, Agents, Continuous Scoring. Für Research-Teams und für Entwicklerinnen und Entwickler, die Transparenz wollen. Für Sie heißt das vor allem: Vergleichen Sie nicht 91 Prozent mit 28 Prozent, als wären es dieselbe Klausur.
Feedback über GitHub ist die Einladung zum Mitreden. Das Repo ist die Adresse für Hinweise und Issues. Es ist nicht die Quelle, aus der man 2.0-Pass-Raten erfindet. Zahlen kommen aus dem Blog-Claim; das Repo trägt Framework und Community-Kanal.
Für Entwicklerinnen und Entwickler, die selbst evaluieren, ist das die gesunde Trennung: Vendor-Blog für die veröffentlichten Ergebnisse, Repo für Methodik-Diskussion und Feedback. Wer Zahlen in Screenshots teilt, ohne Scoring zu nennen, macht genau den Fehler, den Continuous Score korrigieren will.
Bastelprojekt Benchmark heißt auch: Methodik lebt. Harbor-Alignment, Agent-Evals, Continuous Scoring — das sind Bausteine, keine fertige Religion. Lesende dürfen skeptisch bleiben und trotzdem die Richtung würdigen: längere Tasks, ehrlichere Noten.
Was bleibt?
Der Punkt ist: Binary Pass ist ein schlechter Alltagsmaßstab für Wochen-Tasks. Continuous Score zeigt ehrlicher, wie weit ein Agent kommt — und Frontier scheitert bei Long-Horizon Tasks oft, auch wenn Completion noch „grün“ aussieht. Wer nur die 91-Prozent-Welt kennt, unterschätzt die 28-Prozent-Welt.
Android Bench 2.0 feiert nicht 28 Prozent aus Bescheidenheit. Der Benchmark demütigt den Hype, indem er Aufgaben stellt, die Tage bis eine Woche kosten — und dann ehrlich bewertet: Pass, Completion, Kosten, Penalties. Deterministische Umbauten laufen stark; Architektur, Runtime und Cross-Platform-Ports bleiben die Stolperfallen.
Fail bei einer Assertion nach 90 Prozent Requirements bleibt schmerzhaft. Aber wenigstens wissen Sie jetzt, warum die Ampel lügt — und warum Teilpunkte die ehrlichere Note sind.
Was Sie mitnehmen können, ohne Vendor-Glauben zu müssen: Trennen Sie kurze Tasks von Wochen-Tasks. Lesen Sie Pass und Completion getrennt. Erwarten Sie Stärke bei deterministischen Migrationen und Demut bei Architektur, Runtime und Cross-Platform-Ports. Und fragen Sie bei jeder „grünen“ Demo: Welche Assertion fehlt noch?
Der Leaderboard-König der alten Welt trägt in der neuen Welt eine andere Krone. 28 Prozent Pass ist keine Schande — es ist die Note einer Prüfung, die endlich so schwer ist wie die Woche, die Sie dem Agent zumuten.