JetBrains veröffentlichte am 30. August 2026 eine Analyse der Methodik zur Bewertung großer Sprachmodelle, die innerhalb des Programmieragenten Junie eingesetzt werden, und rief dazu auf, sich nicht auf eine einzige Kennzahl, die „Lösungsquote“ (resolve rate), zu stützen. Nach Ansicht des Unternehmens ist es zwar wichtig zu wissen, ob der Agent die Tests einer Aufgabe bestanden hat, doch allein daraus geht nicht hervor, wie er zum Ergebnis gelangte, wie viel dies kostete und ob der Software-Patch begrenzt und wartbar ist.
Die Idee basiert auf einem Vergleich, den JetBrains zwischen Claude Opus 4.7 und Gemini 3.5 Flash anhand eines eigenen Benchmarks durchführte. Beide Modelle lösten dieselbe Anzahl von Aufgaben, doch Opus benötigte durchschnittlich 184 Schritte und verursachte Betriebskosten von 2,79 US-Dollar, gegenüber 271 Schritten und 1,24 US-Dollar bei Gemini. Das identische Endergebnis spiegelte keine deutlichen Unterschiede im Ausführungsablauf oder in der Effizienz der Tool-Nutzung wider.
Was verbirgt die Lösungsquote?
Junie arbeitet im Kontext eines Issues und eines Software-Repositories und ermöglicht es dem Modell, Dateien zu untersuchen, nach Symbolen zu suchen, Code zu ändern sowie Befehle und Tests auszuführen. Diese Aktionen bilden einen „Ausführungsablauf“, der beobachtet werden kann, ohne zu behaupten, dass er das interne Denken des Modells offenlegt. Anhand dieses Ablaufs lässt sich feststellen, ob der Agent vor der Änderung die Problemstelle identifizierte, Suchvorgänge wiederholte, seine Annahmen testete oder die Aufgabe beendete, ohne den endgültigen Patch zu überprüfen.
Deshalb schlägt JetBrains eine Bewertungspipeline vor, die vier Perspektiven verbindet: funktionales Ergebnis, Ausführungseffizienz, Patch-Qualität und Prozessqualität. Zu den konkreten Messgrößen gehören Testergebnisse, Laufzeit, Anzahl der Tokens sowie Modell- und Tool-Aufrufe, Kosten, Anzahl der geänderten Dateien und Symbole, Veränderungen der Komplexität, wiederholte Dateilesevorgänge, die erneute Ausführung von Befehlen mit unveränderten Ergebnissen sowie Tool-Fehlerschleifen.
Vom Ergebnis zu seinem Zustandekommen
JetBrains testete die Methodik anhand von vier Benchmarks mit 523 Aufgaben, als Claude Opus 4.7 und Gemini 3.5 Flash verglichen wurden. Opus löste 267 Aufgaben, eine Quote von 51,1 %, während Gemini 254 Aufgaben mit einer Quote von 48,6 % löste. Bei 430 Aufgaben stimmte das Ergebnis überein: Beide Modelle waren bei 214 Aufgaben erfolgreich und scheiterten bei 216 Aufgaben gemeinsam. Der tatsächliche Unterschied zeigte sich nur bei 93 Aufgaben, wodurch Verhaltensunterschiede wichtiger werden als der reine Abstand in der Rangliste.
Bei einer Aufgabe, die beide Modelle erfolgreich lösten, öffneten beide in Schritt 15 eine relevante Datei, ermittelten die Grundursache und führten eine umfassende Überprüfung durch. Opus verwendete jedoch eine gezieltere Suche, begann nach 13 Schritten mit der Ausführung und beendete die Aufgabe nach 53 Schritten mit sechs Wechseln zwischen Erkundung, Ausführung und Überprüfung. Gemini untersuchte dagegen die große Einheit breiter, führte die erste ausführbare Prüfung in Schritt 30 durch und nahm erst in Schritt 88 die erste Änderung am Produktionscode vor. Anschließend benötigte es 192 Schritte und 34 Wechsel zwischen den Phasen.
Beide Modelle bestanden die Tests und änderten dieselbe Datei und dieselben Symbole wie der Referenz-Patch. Opus berührte jedoch keine weiteren Dateien, während sich der Patch von Gemini auf vier zusätzliche Dateien erstreckte. Der Bewertungsprozess beschrieb ihn als umfangreich, mit deutlichen Wiederholungen und einigen Halluzinationen. JetBrains betont, dass dieses Beispiel der Veranschaulichung dient und kein unabhängiges statistisches Ergebnis darstellt.
Scheitern ist nicht immer dasselbe
Die Analyse der 216 Aufgaben, bei denen beide Modelle gemeinsam scheiterten, zeigte, dass in mehr als 85 % der Fälle laut Bewertung die Grundursache vollständig oder teilweise identifiziert wurde. In einem Fall verstanden beide Agenten, dass das Überschreiten der Token-Grenze durch den Text den Fehler verursachte, schlugen jedoch vor, den Text abzuschneiden, anstatt ihn in gültige Abschnitte aufzuteilen. In einem anderen Fall korrigierten sie einen Download-Parameter in einem Pfad und übersahen dasselbe Problem in einem begleitenden Pfad.
Diese Fälle unterscheiden sich praktisch von einem Scheitern des Agenten, die verantwortliche Komponente zu finden. Die Ursache kann in einer unvollständigen Umsetzung, einer Änderung in der falschen Schicht, der Nichteinhaltung des präzisen Auftragsvertrags oder dem Abbruch vor der Überprüfung liegen. Der Ausführungsablauf kann daher helfen, die erforderliche Intervention zu bestimmen: eine Verbesserung der Navigation im Repository, eine präzisere Aufgabenformulierung, eine bessere Vervollständigung der Änderungen oder das Erzwingen eines abschließenden Überprüfungsschritts.
Verhaltensprofile statt einer einzigen Rangliste
JetBrains kam zu dem Schluss, dass Claude Opus 4.7 eher die zugrunde liegende Ursache für schwer erkennbare Fehler ermittelte und 53 Aufgaben löste, an denen Gemini gescheitert war. Allerdings enthielten 123 seiner Durchläufe keine ausführbare Überprüfung, darunter 68 Aufgaben, die als gelöst eingestuft wurden. Nach Ansicht des Unternehmens kann dieses Verhalten unentdeckte Risiken im Zusammenhang mit Regressionen oder Randfällen hinterlassen.
Gemini 3.5 Flash führte dagegen eher eine ausführbare Prüfung durch und nutzte deren Ergebnis zur Verbesserung der Lösung, wenn das erwartete Verhalten klar und die verantwortliche Komponente relativ eindeutig war. Allerdings zeigte es Probleme bei der Konvergenz zur Lösung und bei der Verankerung im Repository: Es wiederholte gleichwertige Suchvorgänge oder Befehle, verwendete viele Schritte auf die Build-Struktur und stützte sich stärker auf nicht dokumentierte Schnittstellen, Abhängigkeiten, Pfade oder Test-Setups. Bei 195 seiner Durchläufe, also 37,3 %, wurden mittelschwere oder schwere Halluzinationen festgestellt, gegenüber 130 bei Opus. Außerdem zeigten 80 seiner Durchläufe, beziehungsweise 15,3 %, starke oder sehr starke Wiederholungen, gegenüber 6,5 % bei Opus.
Was bedeutet das in der Praxis?
In einem umfassenderen Vergleich, der GPT-5.5, Claude Opus 4.7, Gemini 3.5 Flash und Qwen 3.6 27B FP8 anhand von 522 gemeinsamen Aufgaben umfasste, erzielte GPT-5.5 mit 51,5 % die höchste Lösungsquote und war das einzige Modell, das jedes Mal eine ausführbare Prüfung durchführte. Opus führte die Kennzahlen zur Patch-Qualität an, während Qwen 3.6 27B FP8 38,9 % der Aufgaben löste und dabei Betriebskosten in Höhe von 3 % der Kosten von GPT-5.5 verursachte.
Diese Zahlen verdeutlichen, dass die Wahl des Modells davon abhängt, wo Kosten und Risiken liegen. Ein Modell, das besonders stark in der Diagnose ist, kann für ein unbekanntes Repository oder einen schwer erkennbaren Fehler geeignet sein, während ein Modell mit disziplinierterer Überprüfung besser sein kann, wenn Tests und Feedback verfügbar sind. Ein kostengünstiges Modell kann praktisch sein, wenn die Kosten eines fehlgeschlagenen Versuchs begrenzt sind, selbst bei einer niedrigeren Lösungsquote. Diese Einschätzung bedeutet jedoch nicht, dass ein Modell in jeder Umgebung dasselbe Verhalten zeigt.
JetBrains warnt davor, die Verhaltensprofile auf die Modelle selbst zu verallgemeinern, da die Ergebnisse auf der spezifischen Junie-Architektur basierten. Außerdem sind Bewertungen durch auf großen Sprachmodellen basierende Prüfer keine „Ground Truth“ und werden stark von einem einzigen Gold-Patch beeinflusst, obwohl korrekte Lösungen unterschiedliche Dateien oder Architekturschichten verwenden können. Daher bleibt die Lösungsquote eine notwendige Grundlage, doch ihr Wert steigt, wenn sie durch Belege zur Effizienz, Änderungsqualität und zum Arbeitsablauf ergänzt wird, anstatt sie auf eine einzige Gesamtrangliste zu reduzieren.