Kann man AI-Reviews vertrauen?

 (medium.com)
9 Punkte von bangdori1 9 일 전 | 4 Kommentare | Auf WhatsApp teilen

Beim Betrieb eines internen AI-Review-Tools teile ich den Prozess, mit dem wir die Qualität quantitativ gemessen und verbessert haben, um Fragen wie „Kann man AI-Reviews vertrauen?“ und „Prüft es wirklich zuverlässig?“ zu beantworten.

Hintergrund

  • AI-generierter Code hat im Vergleich zu von Menschen geschriebenem Code 1,7-mal mehr Issues pro PR und 75 % mehr Logikfehler (CodeRabbit)
  • Amazon führte nach einem Ausfall durch AI-Code eine Pflicht zur Freigabe von PRs durch Senior-Entwickler ein, Shopify verbietet das automatische Mergen von AI-PRs
  • AI-Reviews wurden in diesem Kontext als ein Mittel zur Validierung eingeführt, um Issues und Fehler frühzeitig zu erkennen
  • Da AI-Reviews selbst jedoch nicht deterministisch sind, muss zuerst gemessen werden, ob „dieses Validierungsmittel wirklich zuverlässig prüft“

Aufbau eines eigenen Benchmarks

  • Hotfix-PR → Rückverfolgung zum ursprünglichen PR, um zu messen: „Hätte ein AI-Review diesen Bug zum Zeitpunkt des ursprünglichen PR erkennen können?“
  • Es wurden nur Fälle aufgenommen, die sich allein anhand des PR-Diffs beurteilen lassen; Fälle mit notwendigem externem Kontext wurden ausgeschlossen
  • Bewertung mit GPT-4o mini als LLM-as-a-Judge. Auch wenn absolute Werte ungenau sind, reicht es für relative Vergleiche aus
  • Erster Wert: 33 Punkte. Das „Gefühl, dass es gut funktioniert“, war eine Täuschung durch eine sehr kleine Zahl erfolgreicher Einzelfälle

Fehlschlag 1 (Sub-Agent-Orchestrierung)

  • Versuch einer Struktur, in der spezialisierte Sub-Agenten pro Bereich arbeiten und ein Haupt-Agent sie koordiniert
  • Ergebnis: Erkennungsrate ↓, Kosten 1,5- bis 3-mal ↑
  • Drei Ursachen
    • Informationsverlust durch Kontextkomprimierung
    • Verengung des Blickfelds durch eingeschränkte Zuständigkeiten
    • Verantwortungslücken in bereichsübergreifenden Themen

Fehlschlag 2 (Benchmark-Kontamination)

  • Als Prompts in einer Schleife automatisch getunt wurden, konvergierte das System zu einer Aufzählung von Anweisungen wie „Division by Zero prüfen“
  • Auch SWE-bench ist bereits kontaminiert
  • Damit wurde bestätigt, dass sich mit externen Benchmarks keine belastbare Grundlage für die Modellauswahl schaffen lässt

Neue Metrik (Adoption Rate)

  • adopted: Das Review führte tatsächlich zu einer Codeänderung
  • engaged: Keine Änderung, aber Interaktion per Antwortkommentar (Wert der Kreuzvalidierung anerkannt)
  • noised: Weder Änderung noch Antwortkommentar
  • Bewertungsmethode: Vergleich der commit SHA zum Zeitpunkt des Reviews mit der SHA beim Merge; als adopted gilt eine Änderung innerhalb von ±3 Zeilen zur kommentierten Stelle

Opus 4.6 vs. GPT-5.2 Codex A/B

  • Aufteilung der Modelle nach geraden/ungeraden PR-Nummern, Vergleich von rund 100 PRs
  • Opus 4.6: schnell und kreativ, aber zu wenig sorgfältig, Approve zu leicht
  • GPT-5.2 Codex: langsam, aber gründlich; auch bei erneut angeforderten Reviews kamen oft noch valide zusätzliche Hinweise
  • Nach der Festlegung auf Codex wurde ein wöchentlicher Spitzenwert der Übernahmerate von 60 % erreicht

Drei Maßnahmen zur Erhöhung der Übernahmerate

  • Question: Wenn etwas nicht sicher ist, statt eines Hinweises lieber eine Frage stellen
  • PR-Template mit den Abschnitten Intent/Decisions
    • Intent: Mit dem create-pr-Skill werden Antworten auf die Frage „Warum ist das nötig?“ eingefügt
    • Decisions: Ein Claude-Stop-Hook extrahiert automatisch die Entscheidungen aus der Gesprächssitzung
    • Fehlalarme durch fehlenden Kontext auf Seiten der Reviewer wurden um bis zu 29 % reduziert
  • Automatisches Resolve von Threads: Wenn die Berücksichtigung des Reviews bestätigt ist, schließt die AI den Thread selbstständig

Ergebnis

  • Monatliche Übernahmerate von 63 % erreicht (Stand: 2026-04-17)
  • Da alle Maßnahmen datenbasiert sind, lassen sich auch Entscheidungen für die nächsten Experimente fundiert treffen
  • Auch die Adoption Rate garantiert nicht, dass „übernommen = richtig“ bedeutet; daher muss man wachsam bleiben, dass auch diese Metrik kontaminiert werden kann

Verwandte Beiträge

4 Kommentare

 
pkj3186 9 일 전
  • Allerdings sind AI-Reviews selbst nicht deterministisch, daher muss zuerst der Schritt erfolgen, zu messen, ob „dieses Prüfmittel wirklich gut prüft“.

Also ... das klingt wie „Wer überwacht die Wächter?“
 
bangdori1 8 일 전

Mit dem oben erwähnten „Verifizierungsmittel“ meinte ich den AI-Reviewer. Da AI nicht deterministisch ist, wollte ich sagen, dass man zuerst eine Baseline (Benchmark) braucht, um die Qualität von AI-Reviews zu messen. Aus Sicht der Lesenden könnte es aber auch so verstanden werden, dass man zunächst die Validität des Benchmarks selbst hinterfragen sollte.

Ich habe den Satz wohl missverständlich formuliert und damit für Verwirrung gesorgt. Danke für den Hinweis..!
 
epdlemflaj 7 일 전

Persönlich nutze ich für das Schreiben von Code und für das Reviewen unterschiedliche Modelle.
Meiner Erfahrung nach hält Claude von Claude geschriebenen Code für gut geschriebenen Code, und ChatGPT scheint von ChatGPT geschriebenen Code als besser geschrieben anzusehen.
 
jimmy2056 9 일 전

Ich habe in der Planungsphase und in der Validierungsphase Codex verwendet, also habe ich es wohl richtig gemacht.