Jeder Fehler Wird zur Regel:
Wie diffray aus Ihrem Feedback Lernt

Warum KI-Code-Review ohne Feedback-Lernen nur ein teurer Rauschgenerator ist

9. Januar 2026
10 Min. Lesezeit

Boris Cherny, der Schöpfer von Claude Code, enthüllte kürzlich seinen Workflow, und ein Satz aus seinem Thread explodierte in der Entwickler-Community: "Jedes Mal, wenn wir sehen, dass Claude etwas falsch macht, fügen wir es zur CLAUDE.md hinzu, damit Claude es beim nächsten Mal nicht wieder tut."

Produktleiter Aakash Gupta fasste es perfekt zusammen: "Jeder Fehler wird zur Regel." Je länger ein Team mit KI zusammenarbeitet, desto intelligenter wird sie.

Das ist genau die Philosophie, auf der diffray aufgebaut ist. Heute zeigen wir Ihnen, wie es unter der Haube funktioniert.

Das Problem: Kontextverschmutzung Beeinträchtigt die Review-Qualität

Bevor wir über Regeln sprechen, müssen wir die technische Hauptherausforderung des KI-Code-Reviews verstehen — Kontextverschmutzung.

Anthropics Forschung zeigt, dass LLMs, wie Menschen, den Fokus verlieren, wenn das Kontextfenster sich füllt. Korrekturen häufen sich, Nebendiskussionen stapeln sich, veraltete Tool-Ausgaben bleiben bestehen. Das Ergebnis ist vorhersehbar:

False Positives

KI findet "Probleme", die nicht existieren

Halluzinationen

Imaginäre Bugs und nicht existierende Muster

Zieldrift

Reviews werden progressiv weniger relevant

JetBrains Research (Dezember 2025) quantifizierte dies: Agent-Kontexte wachsen so schnell, dass sie teuer werden, aber keine signifikant bessere Aufgabenleistung liefern. Mehr Kontext ≠ bessere Ergebnisse.

Die Lösung: Spezialisierte Subagenten mit Isoliertem Kontext

Boris Cherny verwendet Subagenten als "automatisierte Kapselungen der häufigsten Workflows." Seine Philosophie:

"Zuverlässigkeit kommt von Spezialisierung plus Einschränkung"

Anstelle eines allwissenden Reviewers erzeugt sein Code-Review-Befehl mehrere parallele Agenten mit unterschiedlichen Verantwortlichkeiten:

1.Ein Agent überprüft Stilrichtlinien
2.Ein anderer analysiert die Projektgeschichte, um Muster zu verstehen
3.Ein dritter markiert offensichtliche Bugs
4.Dann suchen fünf weitere Agenten gezielt nach Schwachstellen in den ersten Erkenntnissen

Diese adversariale Schicht ist entscheidend. Sekundäre Agenten hinterfragen die Erkenntnisse des ersten Durchgangs und eliminieren False Positives durch strukturierte Skepsis.

Das Ergebnis, in Chernys Worten: "findet alle echten Probleme ohne die falschen."

Wie Es Technisch Funktioniert

Wenn der Hauptagent an einen Subagenten delegiert, entsteht ein frisches Kontextfenster, das nur die Aufgabenbeschreibung und relevante Parameter enthält. Der Subagent kann extensiv erkunden—zehntausende Token beim Durchsuchen von Code verbrauchen—gibt aber nur eine kondensierte Zusammenfassung von 1.000-2.000 Token zurück.

Dies bewahrt den Fokus des Hauptagenten und ermöglicht gleichzeitig tiefgehende Analyse.

Hauptagent(sauberer Kontext)
🛡️
Sicherheit
isolierter Kontext
Stil
isolierter Kontext
Performance
isolierter Kontext
🏗️
Architektur
isolierter Kontext
Kondensierte Zusammenfassungen(1-2K Token jeweils)

Bei diffray verwenden wir über 30 spezialisierte Agenten, jeder auf eine bestimmte Domäne fokussiert: Sicherheit, Performance, Code-Stil, architektonische Muster und mehr. Jeder Agent arbeitet in einem isolierten Kontext und gibt nur substanzielle Erkenntnisse zurück.

Regelerstellung: Feedback in Wissen Verwandeln

Jetzt zum Hauptereignis. Subagenten lösen das Kontextproblem. Aber wie bringt man KI dazu, aus Ihren Korrekturen zu lernen?

Das CLAUDE.md-Muster

In Claude Code pflegen Teams eine CLAUDE.md-Datei in ihrem Repository—eine Art "Verfassung" für das Projekt. Die Datei wird automatisch bei jeder Sitzung in den Kontext geladen.

Aber es gibt eine kritische Einschränkung. HumanLayer-Forschung zeigt, dass Claude Codes System-Prompt bereits ~50 Anweisungen enthält, und Frontier-LLMs folgen zuverlässig nur 150-200 Anweisungen insgesamt. Die Qualität der Anweisungsbefolgung nimmt gleichmäßig ab, wenn die Anzahl steigt.

Das bedeutet: Sie können nicht einfach 500 Regeln abladen und Magie erwarten.

Drei Ebenen des Wissens

Effektive Regeln kodieren Wissen auf drei Ebenen:

WAS (Projektkarte)

## Tech-Stack
- Backend: Python 3.11, FastAPI, SQLAlchemy
- Frontend: React 18, TypeScript, TailwindCSS
- DB: PostgreSQL 15

WARUM (Architekturentscheidungen)

## Warum Wir KEIN ORM für Komplexe Abfragen Verwenden
Geschichte: ORM generierte N+1-Abfragen in Berichten.
Entscheidung: Raw SQL für Analytics, ORM nur für CRUD.

WIE (Prozesse)

## Vor dem Commit
- `make lint` ausführen — muss ohne Fehler bestehen
- `make test` ausführen — Abdeckung darf nicht sinken

Das Problem mit Manuellen Ansätzen

Manuelle Regelwartung funktioniert... solange Ihr Team klein und diszipliniert ist. In der Realität:

Entwickler vergessen, Regeln zu aktualisieren

Regeln veralten schneller als Code

Implizite Konventionen bleiben implizit

Stammeswissen stirbt, wenn Schlüsselpersonen gehen

Wie diffray die Regelerstellung Automatisiert

diffray dreht den Prozess um. Statt Regeln manuell zu schreiben, geben Sie einfach Feedback zu Reviews.

Der Lernkreislauf

📝
PR
🔍
diffray Review
💬
Entwickler-Feedback
🧠
Analyse
🔬Musterextraktion
Was war falsch?
⚙️Regelgenerierung
Spezifische Regel erstellen
Validierung
An PR-Historie testen
Nächster PR integriert die Regel

Schritt 1: Sie Geben Feedback

Daumen runter für einen diffray-Kommentar gegeben? Geantwortet "das ist kein Bug, das ist beabsichtigt"? Eine Empfehlung ignoriert? diffray erfasst alles.

Schritt 2: Musterextraktion

diffray analysiert: Was genau war falsch? War es ein Fehlalarm (Code ist korrekt), nicht anwendbarer Kontext (Regel gilt hier nicht), oder projektspezifische Konvention (so machen wir das hier)?

Schritt 3: Regelgenerierung

Basierend auf dem Muster formuliert diffray eine Regel, die den Geltungsbereich (welche Dateien/Verzeichnisse), was unterdrückt oder durchgesetzt werden soll, und warum spezifiziert. Die Regel wird für Nachverfolgbarkeit mit dem ursprünglichen Feedback verknüpft.

Schritt 4: Validierung

Bevor die Regel angewendet wird, führt diffray sie gegen historische PRs aus. Wie viele Kommentare wären unterdrückt worden? Wie viele davon waren tatsächlich False Positives? Die Regel wird nur angewendet, wenn sie die Genauigkeit verbessert.

Arten von Regeln in diffray

🚫

Unterdrückungsregeln

"X im Kontext Y nicht markieren" — bestimmte Warnungen in Legacy-Code, Testdateien oder generiertem Code unterdrücken.

🛡️

Durchsetzungsregeln

"Immer auf Z prüfen" — sicherstellen, dass kritische Muster wie SQL-Parametrisierung oder Auth-Prüfungen nie übersehen werden.

🎯

Kontextregeln

"Die Besonderheiten berücksichtigen" — Priorität basierend auf Dateityp, Dekoratoren oder umgebenden Codemustern anpassen.

📖

Terminologieregeln

"Wir nennen es so" — diffray Ihr Domänenvokabular beibringen, damit es Ihre Codebasis besser versteht.

Praktisches Beispiel: Von Ärgernis zu Regel

Stellen Sie sich vor: diffray hinterlässt einen Kommentar zu Ihrem PR:

Warnung Performance: Die Verwendung von any reduziert die Typsicherheit. Erwägen Sie explizite Typisierung.

Sie wissen, dass dies ein Legacy-Modul ist, das für das nächste Quartal zur Umschreibung vorgesehen ist. Jetzt Typen zu korrigieren wäre Zeitverschwendung.

Sie antworten: "Das ist Legacy, Typisierung wird während der Q2-Refaktorierung behandelt"

Was als Nächstes passiert:

1.diffray erkennt das negative Feedback
2.Analysiert den Kontext: Datei ist in src/legacy/, es gibt ein TODO mit Datum
3.Findet ähnliche Fälle in der Historie: 12 analoge Kommentare im letzten Monat
4.Generiert eine Unterdrückungsregel für src/legacy/** mit Ablaufdatum (Q2)
5.Nächster PR in src/legacy/ — diffray schweigt zu Typen

Aber wichtig: Die Regel ist nicht permanent. Das Ablaufdatum bedeutet, dass diffray nach Q2 wieder beginnt, Typen in diesem Verzeichnis zu prüfen.

Die Metrik: False-Positive-Rate Reduzieren

Das Schlüsselmaß für die Effektivität von KI-Code-Review ist die False-Positive-Rate. Wie viele von 100 Kommentaren waren nutzlos?

Typische Branchen-Benchmarks:

40-60%

Basis-KI-Review False Positives

25-35%

Mit manuellen Regeln

8-13%

diffray mit gelernten Regeln

Wie wir das erreichen:

Kontextisolierung

Durch Subagenten verhindert Drift

Agentenspezialisierung

Verbessert Genauigkeit in jeder Domäne

Lernen aus Feedback

Eliminiert wiederkehrende False Positives

Regelvalidierung

Verhindert Overfitting

Erste Schritte: Drei Schritte

Schritt 1: Verbinden Sie diffray mit Ihrem Repository

Die Integration dauert 5 Minuten über GitHub App oder GitLab-Webhook.

Schritt 2: Arbeiten Sie Einfach

In den ersten 2-3 Wochen arbeitet diffray im Lernmodus. Es studiert Ihre Projektstruktur, Ihre PR-Muster und den Kommentarstil Ihrer Reviewer.

Schritt 3: Geben Sie Feedback

Ignorieren Sie diffray-Kommentare nicht stillschweigend. Geben Sie Daumen hoch für nützliche, Daumen runter für nutzlose, antworten Sie auf diskutierbare.

Jede Interaktion macht diffray intelligenter. Nach einem Monat haben Sie einen personalisierten KI-Reviewer, der Ihre Konventionen besser kennt als ein neuer Entwickler nach dem Onboarding.

Fazit: KI, Die Mit Ihrem Team Wächst

Die Philosophie "jeder Fehler wird zur Regel" ist nicht nur ein eingängiger Spruch. Es ist ein architektonisches Prinzip, das Spielzeugtools von produktionsreifen Lösungen unterscheidet.

diffray ist auf drei Säulen aufgebaut:

Subagenten mit isoliertem Kontext

Für Genauigkeit ohne Verschmutzung

Regelerstellung aus Feedback

Für Lernen ohne manuelle Arbeit

Validierung an Historie

Für Vertrauen in Verbesserungen

Das Ergebnis: KI-Code-Review, das mit jedem PR besser wird. Nicht weil das Modell aktualisiert wurde, sondern weil es von Ihrem Team lernt.

Beginnen Sie Heute, Ihren KI-Reviewer zu Trainieren

Installieren Sie diffray und öffnen Sie einen PR. Es ist kostenlos für öffentliche Repos und enthält eine großzügige kostenlose Stufe für private Repos.

Verwandte Artikel