SWE-PRBench -- Wie gut koennen LLMs Code Reviews?
Code Review durch AI wird als eine der vielversprechendsten Anwendungen von LLMs im Software-Engineering gehandelt. Aber wie gut funktioniert es wirklich? Deepak Kumar liefert mit SWE-PRBench die erste systematische Antwort -- und sie ist ernuechternd. Kein getestetes Frontier-Modell findet mehr als ein Drittel der Probleme, die menschliche Reviewer erkennen. Noch ueberraschender: Wenn man den Modellen mehr Kontext gibt, werden sie schlechter.
Kernaussagen
Der Benchmark testet 8 Frontier-Modelle an 350 realen Pull Requests mit menschlich annotierten Ground-Truth-Reviews. Die Ergebnisse teilen sich in zwei klare Leistungsgruppen.
Die obere Gruppe -- Claude Haiku 4.5, Claude Sonnet 4.6, DeepSeek V3 und Mistral Large 3 -- erreicht Composite Scores zwischen 0,147 und 0,153. Der Unterschied innerhalb dieser Gruppe ist statistisch nicht signifikant. Die untere Gruppe -- GPT-4o, GPT-4o-mini, Mistral Small und Llama 3.3 70B -- bleibt bei 0,079 bis 0,113.
Bei den Erkennungsraten (Detection Rates) liegt Sonnet mit 0,190 vorne, gefolgt von DeepSeek (0,181) und Haiku (0,172). Selbst die besten Modelle erkennen also nur knapp ein Fuenftel der von Menschen gefundenen Probleme. Menschliche Reviewer erreichen typischerweise 50-70% Recall -- eine Luecke von 20-40 Prozentpunkten.
Die vielleicht wichtigste Erkenntnis betrifft Halluzinationen. Die False-Positive-Raten variieren stark: GPT-4o liegt bei 0,193 (niedrigster Wert), DeepSeek bei 0,315 und Llama 3.3 bei 0,417. Ein Modell wie Llama produziert also bei fast jeder zweiten gemeldeten Issue einen Fehlalarm -- ein Problem, das in der Praxis schnell dazu fuehrt, dass Entwickler die AI-Reviews ignorieren.
Das kontraintuitivste Ergebnis: Alle 8 Modelle werden monoton schlechter, wenn man ihnen mehr Kontext gibt. In drei Konfigurationen getestet -- Diff-only (Config_A, 2.000 Tokens), Diff plus Dateiinhalt (Config_B, 2.200 Tokens) und voller Kontext mit Testdaten (Config_C, 2.500 Tokens) -- sinkt die Leistung bei jedem Schritt. Bei kontextabhaengigen Issues (Type2_Contextual) bricht die Performance um ueber 50% ein: Sonnet faellt von 0,22 auf 0,10, DeepSeek von 0,20 auf 0,10.
Methodik
Die 350 Pull Requests wurden aus 700 Kandidaten gefiltert. Ein Repository Quality Score (RQS) stellt sicher, dass nur aktive Open-Source-Projekte mit hoher Codequalitaet einfliessen. Eine 10-stufige Filterpipeline entfernt Bot-generierte und AI-generierte PRs. Die Sprachverteilung: Python 69,1%, JavaScript 10,6%, Go 10,0%, TypeScript 6,0%, Java 4,3%.
Die Issues werden in drei Schwierigkeitsgrade klassifiziert: Type1_Direct (66,3%) -- direkt im Diff erkennbar; Type2_Contextual (21,4%) -- erfordert Verstaendnis des umgebenden Codes; Type3_Latent (12,3%) -- erfordert tiefes Domaenwissen oder Architekturverstaendnis.
Die Bewertung nutzt ein LLM-as-Judge-Framework mit GPT-5.2 als festem Richter (Cohen's Kappa = 0,75). Jede gefundene Issue wird als CONFIRMED, PLAUSIBLE oder FABRICATED klassifiziert. Eine Kreuzvalidierung mit Claude Sonnet 4.6 (Kappa = 0,616) bestaetigt die Robustheit der Bewertung.
Ein bemerkenswerter Kostenaspekt: DeepSeek V3 erreicht die gleiche Leistungsstufe wie die teureren Modelle bei etwa einem Neuntel der API-Kosten (0,28 Dollar pro Million Tokens gegenueber 2,50 Dollar bei GPT-4o).
Relevanz fuer die Praxis
AI Code Review ist ein Ergaenzungstool, kein Ersatz. Mit maximal 31% Erkennungsrate sind LLMs weit entfernt davon, menschliche Reviewer zu ersetzen. Sie koennen offensichtliche Probleme abfangen, aber komplexe architektonische oder kontextabhaengige Issues bleiben ihnen verborgen.
Weniger Kontext ist besser. Das ist die ueberraschendste praktische Erkenntnis. Wer AI-gestuetzte Code-Reviews implementiert, sollte den Modellen nur den Diff schicken -- nicht den gesamten Dateiinhalt oder Testkontext. Die Autoren fuehren das auf ein Attention-Allokations-Problem zurueck: Die Modelle verteilen ihre Aufmerksamkeit auf den zusaetzlichen Kontext, statt sich auf die geaenderten Zeilen zu konzentrieren.
Halluzinationsrate als Auswahlkriterium. Fuer den produktiven Einsatz ist die False-Positive-Rate mindestens so wichtig wie die Erkennungsrate. Ein Modell, das viel findet, aber haeufig falschen Alarm gibt, wird von Entwicklern schnell ignoriert. GPT-4o hat hier mit 0,193 den besten Wert, liegt aber bei der Gesamtleistung in der unteren Gruppe -- ein klassischer Precision-Recall-Tradeoff.