"Wenn moderne LLMs 200k Tokens verarbeiten können, warum nicht einfach den Diff mit relevantem Kontext senden und das Modell herausfinden lassen? Was bringt die ganze Agenten-Komplexität?"
Ein Prompt kann nur sehen, was Sie ihm senden. Für bedeutungsvolles Code Review brauchen Sie Kontext aus Ihrer gesamten Codebase — Imports, Dependencies, verwandte Dateien, Tests, Konventionen.
Forschung beweist, dass mehr Kontext in LLMs zu packen der Performance aktiv schadet. Das nennt man "Kontextverwässerung."
10-20%
Performance-Verlust durch zu viele Dokumente
U-Kurve
Info in der Mitte geht "verloren"
60-80%
False-Positive-Rate bei Context-Dump-Tools
Agenten "lesen Prompts nicht besser." Sie untersuchen aktiv Ihre Codebase:
Holen nur relevante Dateien on-demand, nicht alles upfront dumpen
"Ich vermute einen Typ-Mismatch" → Aufrufer suchen → mit statischer Analyse bestätigen
Leads über Dateien hinweg verfolgen, tiefer graben wenn etwas verdächtig aussieht
Linter, Type-Checker und Analyzer ausführen, um Erkenntnisse mit echten Daten zu verifizieren
Ein Prompt sieht, was Sie ihm geben.
Ein Agent findet, was er braucht.
Der Unterschied zwischen nützlichem Review und Rauschen ist nicht, wie viel Kontext Sie haben — es ist den richtigen Kontext zu haben
Vor dem Review erstellen wir eine Karte, wie Dateien verbunden sind — Imports, Exports, Typdefinitionen und Call-Chains
Jeder Agent erhält nur den für seine Aufgabe relevanten Kontext — Security-Agent bekommt Auth-Flows, nicht UI-Styling
Agenten holen zusätzlichen Kontext nur bei Bedarf — Leads verfolgen ohne Upfront-Überlastung
Kern-Kontext (Diff, Typen) bleibt resident; umgebender Kontext (Aufrufer, Tests) bei Bedarf geladen
200k Tokens von allem — Diff, vollständige Dateien, zufällige Dependencies...
Fokussierte Chunks — Diff + direkte Dependencies + relevante Muster
Ein einzelner LLM-Call für Code Review hat fundamentale Grenzen
Beschränkt auf den Diff, den Sie bereitstellen
Keine Iteration oder Verifizierung
Blind für Dependencies und Kontext
Keine Möglichkeit, Behauptungen zu validieren
Aufmerksamkeit dünn über alle Belange verteilt
"Stellen Sie sicher, dass Aufrufer aktualisiert werden"
Navigiert durch Ihr gesamtes Projekt
Verfolgt Leads, gräbt tiefer
Versteht Imports und Dependencies
Führt statische Analyzer zur Bestätigung aus
Jeder Agent spezialisiert sich auf einen Bereich
"3 Aufrufstellen haben Typ-Mismatches in Zeilen 45, 89, 112"
Der Unterschied ist zwischen Spekulation und Investigation.
Ein Agent ist ein KI-System, das denken, handeln und verifizieren kann
Dateien lesen, Code durchsuchen, statische Analyzer ausführen
Wählen, was basierend auf Erkenntnissen untersucht werden soll
Leads verfolgen, Hypothesen verifizieren, tiefer graben
Reasoning gegen echte Daten validieren
Wenn diffray Ihren PR reviewed, "schauen" Agenten nicht nur "auf den Diff"
Imports folgen, um zu verstehen, wie geänderter Code das gesamte System beeinflusst
Tests, Configs und Dokumentation für Kontext untersuchen
Statische Analyse ausführen, um zu bestätigen, dass vermutete Issues wirklich existieren
Typdefinitionen, API-Verträge und Konventionen nachschlagen
Betrachten Sie eine Änderung der Funktionssignatur in einem PR:
"Dies ändert den Rückgabetyp, stellen Sie sicher, dass Aufrufer aktualisiert werden"
Generischer Rat. Keine Spezifika.
→ "3 Breaking Changes gefunden: src/api/users.ts:45, src/hooks/useAuth.ts:89, src/utils/validate.ts:112"
Um Änderungen wirklich zu verstehen, müssen Sie sehen, wie sie in die gesamte Codebase passen
Neue Funktion formatUserName() hinzugefügt
Sieht syntaktisch korrekt aus
Keine offensichtlichen Bugs in diesen 20 Zeilen
Urteil: "LGTM" — aber das größere Bild komplett übersehen
Diese Funktion dupliziert utils/names.ts:formatName()
Existierende Funktion behandelt Edge Cases, die diese übersieht
3 andere Dateien nutzen bereits das existierende Utility
Dies bricht die Namenskonvention in /docs/CONVENTIONS.md
Urteil: "Erwägen Sie, existierendes formatName() aus utils/names.ts zu verwenden"
Erfindet der Entwickler das Rad neu? Existiert bereits eine ähnliche Lösung in der Codebase?
Folgen diese Änderungen etablierten Mustern? Oder führen sie einen widersprüchlichen Ansatz ein?
Wie beeinflussen diese Änderungen den Rest des Systems? Was hängt vom geänderten Code ab?
Werden Team-Konventionen und dokumentierte Standards befolgt?
Ein Diff zeigt Ihnen was sich geändert hat. Voller Codebase-Kontext zeigt Ihnen ob es das hätte sollen.
Leistungsstarke Grundlagen, die echte Multi-Agenten-Zusammenarbeit ermöglichen
Jedes Review durchläuft eine Multi-Phase-Pipeline, jede Phase für ihren Zweck optimiert
Clone
Repo fetchen & PR auschecken
Data Prep
Dependency-Graph aufbauen
Summarize
LLM fasst Änderungen zusammen
Triage
Dateien an Agenten routen
Rules
Regeln laden & filtern
Review
Parallele Agenten-Analyse
Dedupe
Zusammenführen & neu bewerten
Validation
Verifizieren & neu bewerten
Report
PR-Kommentare generieren
Clone
Repo fetchen & PR auschecken
Data Prep
Dependency-Graph aufbauen
Summarize
LLM fasst Änderungen zusammen
Triage
Dateien an Agenten routen
Rules
Regeln laden & filtern
Review
Parallele Agenten-Analyse
Dedupe
Zusammenführen & neu bewerten
Validation
Verifizieren & neu bewerten
Report
PR-Kommentare generieren
Das Ergebnis
Ein Multi-Agenten-System, das KI-Reasoning mit konkreter Code-Analyse kombiniert — liefert genaue, verifizierte Erkenntnisse statt Spekulation.
Sehen Sie, wie Investigation Spekulation schlägt. Testen Sie diffray kostenlos bei Ihrem nächsten PR.