Die Architektur von diffox: 17 spezialisierte Agenten, vier Phasen
diffox verteilt ein KI-Code-Review auf 17 spezialisierte Agenten. Jede Feststellung zitiert den Code. Geprüft wird das Zitat von Code, nicht von einem Modell.
Zusammenfassung. diffox ist ein KI-Code-Review-Tool, das Pull Requests auf GitHub prüft. Jedes Review durchläuft vier Phasen. Dieser Beitrag zeigt, was in jeder Phase passiert und warum. Die Ergebnisse haben wir in den ersten beiden Beiträgen gemessen: diffox ultra liegt in Martians Benchmark unter 23 Tools auf Platz eins; ein Review mit diffox kostet $0,41.
- Kontext & Zuordnung. diffox stellt die Änderung zusammen: mit ihren Dateien vorher und nachher und mit den Regeln, die Sie geschrieben haben. Art und Risiko der Änderung bestimmen, welche spezialisierten Agenten sie lesen.
- Spezialistenprüfung. Das Team besteht aus 17 spezialisierten Agenten. Jeder sucht nach genau einer Sache und belegt, was er findet, mit einem wörtlichen Zitat aus dem Code.
- Belegprüfung. Jede Feststellung wird von Code geprüft, nicht von einem Modell. Steht der zitierte Code wirklich in dieser Datei? Betrifft die Feststellung etwas, das dieser Pull Request geändert hat? Wurde dasselbe Problem zweimal gemeldet?
- Auswahl & Ausgabe. Jede Feststellung hat eine Klasse: Kritisch, Warnung oder Vorschlag. Im Pull Request steht, was Sie beheben sollten: kritische Feststellungen und Warnungen. Vorschläge gehen nicht verloren, sie warten auf der Seite Feststellungen. Ein Review blockiert nie einen Merge.
Wie ein Review abläuft
Am schnellsten prüft man eine Änderung, indem man ein Modell fragt: „Ist hier ein Fehler?“ Das tut diffox nicht. Es lässt dieselbe Änderung von verschiedenen spezialisierten Agenten lesen: Einer achtet auf Logikfehler, einer auf Nebenläufigkeit, einer darauf, ob ein Test wirklich etwas prüft. Jeder Agent hat eine enge, klar umrissene Aufgabe. Danach folgen zwei weitere Schritte. Prüfungen binden jede Feststellung an die Datei selbst statt an das Wort des Modells, und eine Auswahl entscheidet, was veröffentlicht wird.
Was dieser Aufbau leistet, haben wir im ersten Beitrag gemessen: In Martians Benchmark mit 50 Pull Requests fand diffox ultra 119 der 158 bekannten Fehler, diffox 106. Was das kostet, steht im zweiten Beitrag. Im Folgenden die vier Phasen der Reihe nach.
Was die Agenten sehen und welche zum Einsatz kommen
Ein Review startet, ohne dass Sie es anfordern: wenn ein Pull Request geöffnet wird, und bei jedem neuen Push. diffox schreibt zuerst einen Kommentar in den Pull Request, dass das Review begonnen hat. Ist es fertig, wird aus demselben Kommentar das Ergebnis. Bevor die spezialisierten Agenten die Änderung sehen, wird zweierlei entschieden: was sie vorgelegt bekommen und welche von ihnen aufgerufen werden.
Jeder der vier Teile beantwortet eine andere Frage. Der Diff sagt, was sich geändert hat. Die Dateien, vorher und nachher, zeigen, wo die Änderung sitzt. Titel, Beschreibung und Commit-Nachrichten sagen, was beabsichtigt war. Und AGENTS.md oder CLAUDE.md, falls Ihr Repository eine solche Datei hat, sagt, an welche Regeln sich Ihr Team hält.
Die Regeldatei wird aus dem Branch gelesen, in den der Pull Request gemergt wird, nicht aus dem Branch des Pull Requests selbst. So kann ein Pull Request die Regeln seines eigenen Reviews nicht ändern: Eine Änderung an der Regeldatei gilt erst, wenn sie gemergt ist. Lock-Dateien, Fremdcode wie vendor/ und node_modules/ und minifizierte Dateien werden nicht geprüft.
Dann folgt die Zuordnung. diffox bestimmt die Art der Änderung (Fehlerbehebung, neue Funktion, Refactoring, Migration, Test …) und schätzt ihr Risiko ein: wie viele Dateien sie berührt, ob sie andere Dateien betrifft, ob Tests dabei sind. Einige Agenten lesen jede Änderung, andere laufen nur, wenn ihr Thema vorkommt. Wurde keine Zeile gelöscht, hat der Agent für entferntes Verhalten nichts zu tun. Wurde kein Test angefasst, gilt das auch für den Agenten, der leere Tests sucht.
Kommt ein neuer Push in denselben Pull Request, liest diffox nur die neue Änderung.
Jeder Agent sucht nach genau einer Sache
In der zweiten Phase lesen die spezialisierten Agenten die Änderung. Das Team hat 17 Agenten, und je nachdem, wonach sie suchen, gibt es zwei Arten.
12 Agenten suchen Fehler: Code, der beim Ausführen ein falsches Ergebnis liefert. 5 suchen Widersprüche: Stellen, an denen der Code nicht zu dem Kommentar, dem Test oder dem Dokument daneben passt. Jeder Agent hat seine eigene Anweisung; alle lesen dieselbe Änderung und denselben Kontext.
Damit eine Feststellung zählt, muss sie drei Dinge nennen: ihre Behauptung, was in welcher Situation schiefgeht, und den Code, auf den sich die Behauptung stützt, als wörtliches Zitat. Eine Widerspruchs-Feststellung bringt zwei Zitate mit: den Code und den Text, der ihm widerspricht. Fehlt eines davon, zählt die Feststellung nicht.
Agenten nennen keine Zeilennummern. Sprachmodelle zählen Zeilen nicht zuverlässig. Deshalb verlangt diffox vom Modell das Zitat statt der Zeilennummer und sucht die Zeile selbst, indem es das Zitat in der Datei findet. Ob eine Feststellung unter der richtigen Zeile landet, hängt also nicht davon ab, was das Modell sagt.
Neben den spezialisierten Agenten laufen regelbasierte Detektoren. Sie nutzen kein Modell, sondern suchen mit festen Regeln: Zugangsdaten, die in den Code geraten sind, eine Methode, die in derselben Klasse zweimal definiert ist, ein Zweig, der nie erreicht werden kann.
Das ganze Team und wonach jeder Agent sucht:
| Agent | Art | Sucht nach |
|---|---|---|
| ➗ Logic | Fehler | Sucht Off-by-one-Fehler, Randbedingungen, invertierte Bedingungen, falsche Operatoren und verletzte Funktionsverträge. |
| ⭕ Null Path | Fehler | Sucht einen Wert, der fehlen kann, wo der Code ihn als vorhanden liest: None, null oder ein leeres Ergebnis, das benutzt wird, als enthielte es etwas. |
| 🔀 Race | Fehler | Sucht Race Conditions, Deadlocks, nicht-atomares Read-Modify-Write, unsicheren geteilten Zustand und Risiken in der Lock-Reihenfolge. |
| 🔇 Silent Failure | Fehler | Sucht verschluckte Exceptions, zu breite Catches, ignorierte Rückgabewerte und vorgetäuschte Fallbacks, die Fehler verdecken. |
| 💾 Data Integrity | Fehler | Sucht Schema-Abweichungen, nicht rückwärtskompatible Migrationen, verlorene Schreibvorgänge und nicht idempotente Operationen. |
| 🔓 Security | Fehler | Sucht Injection, kaputte Authentifizierung und Autorisierung, geleakte Secrets, SSRF sowie unsichere Deserialisierung oder Pfadbehandlung. |
| 💥 Blast Radius | Fehler | Sucht kaputte Aufrufer, veränderte API-Oberflächen und Signatur- oder Rückgabetyp-Änderungen, die andere Dateien im Änderungsgraphen brechen. |
| 🐛 Regression | Fehler | Sucht die Wiederkehr von Fehlermustern, die in diesen Dateien schon einmal behoben wurden. |
| 🥅 Safety Net | Fehler | Sucht eine Lücke zwischen der Änderung und den Tests, die sie absichern: Verhalten, das ein Test prüft und das dieser Diff geändert hat, ohne den Test anzupassen. |
| 🔥 Hot Path | Fehler | Sucht N+1-Abfragen, unnötige Allokationen auf Hot Paths und algorithmische Regressionen. |
| 🏷️ Naming | Fehler | Sucht nur vier nachweisbare Fälle: einen Tippfehler in einem Bezeichner, dem ein Nachbar im selben Diff widerspricht, zwei Schreibweisen eines Schlüssels, ein Label, das das Falsche benennt, und einen Test, dessen Name etwas verspricht, das er nie ausführt. |
| 📐 House Rules | Fehler | Sucht Zeilen in diesem Diff, die gegen die Review-Regeln verstoßen, die das Repository selbst in AGENTS.md oder CLAUDE.md festgehalten hat – sofern es sie gibt. |
| 💬 Broken Promise | Widerspruch | Sucht Text, der etwas behauptet, das der Code daneben nicht einhält: einen Kommentar, Docstring oder README, der etwas sagt, was der Code nicht tut. |
| 🪦 Dead Code | Widerspruch | Sucht Code, dessen Wirkung nicht beobachtbar ist: nach dieser Änderung unerreichbar oder doppelt vorhanden. |
| 📜 Stale Contract | Widerspruch | Sucht eine Deklaration, die sich hier geändert hat, während etwas im Blickfeld noch die alte Form erwartet. |
| 🗑️ Lost Behaviour | Widerspruch | Sucht Verhalten, das diese Änderung gelöscht hat, ohne es zu ersetzen, und fragt, ob noch etwas davon abhängt. |
| 📭 Empty Test | Widerspruch | Sucht einen Test, der nicht prüft, was er behauptet: Er bestünde, egal was der Code tut. |
Der Kommentar zu einer Feststellung trägt das Zeichen und den Namen des Agenten, der sie gefunden hat, zum Beispiel ➗ Logic Agent.
Wie jede Feststellung am Code geprüft wird
Ein Sprachmodell kann etwas schreiben, das überzeugend klingt und trotzdem falsch ist: Es zitiert eine Zeile, die nicht in der Datei steht, beanstandet Code, den dieser Pull Request gar nicht berührt hat, oder nennt dasselbe Problem dreimal in drei verschiedenen Sätzen. Die dritte Phase bindet deshalb jede Feststellung an die Datei selbst, nicht an das Wort des Modells.
Diese Prüfungen sind gewöhnlicher Code, kein Modellaufruf: Dieselbe Eingabe ergibt jedes Mal dieselbe Antwort.
- Anchor Verifier. Das Zitat der Feststellung wird in der Datei gesucht. Ein Zitat, das sich nicht findet, hat keine Zeile, auf die es zeigen kann. Liegt die gefundene Zeile außerhalb dessen, was dieser Pull Request geändert hat, liegt die Feststellung außerhalb des Prüfumfangs.
- Second Witness. Feststellungen, die an derselben Stelle denselben Einwand erheben, werden zu einer zusammengefasst; Sie bekommen dasselbe Problem nicht zweimal. Zeigen mehrere Quellen auf dieselbe Stelle, spricht das für die Feststellung.
- Verbatim Matcher. Auch das zweite Zitat einer Widerspruchs-Feststellung wird Wort für Wort gesucht: in der Änderung, in den Dateien, in der Beschreibung des Pull Requests, in den Commit-Nachrichten und in Ihrer Regeldatei. Behauptet das Modell, ein Kommentar sage etwas, das er nicht sagt, fällt es hier auf.
Dazu kommt eine weitere Prüfung: Eine Feststellung, nach der ein Wert leer sein könnte, gilt als widerlegt, wenn der Typ des Werts oder eine Prüfung ein paar Zeilen darüber das schon ausschließt.
Welche Feststellungen veröffentlicht werden
Nach den Prüfungen bleibt eine Liste von Kandidaten. Die vierte Phase entscheidet, welche davon im Pull Request veröffentlicht werden.
Attention Ranker beantwortet für jeden Kandidaten eine einzige Frage: Wie wahrscheinlich ist es, dass diese Feststellung ein echter Fehler ist? In die Bewertung gehen Schwere und Art der Feststellung ein, das Ergebnis der Belegprüfungen und ob weitere Feststellungen auf dieselbe Stelle zeigen. Von mehreren Feststellungen auf benachbarten Zeilen wird nur die stärkste veröffentlicht.
Im Pull Request sehen Sie nur, was behoben werden sollte: kritische Feststellungen und Warnungen. Vorschläge warten auf der Seite Feststellungen; dafür müssen Sie nichts einstellen.
Die Zahlen unten haben wir auf demselben Benchmark mit drei Empfindlichkeitseinstellungen gemessen. Diese Einstellung war eine Schwelle, die die Bewertung einer Feststellung überschreiten musste. Hoch fand die meisten Fehler. Mittel und Niedrig hoben die Schwelle an: diffox veröffentlichte weniger Feststellungen und war sich bei denen, die es veröffentlichte, sicherer.
| Empfindlichkeit | diffox | diffox ultra | ||
|---|---|---|---|---|
| Echte Fehler | Fehlalarme | Echte Fehler | Fehlalarme | |
| Hoch | 106 | 132 | 119 | 144 |
| Mittel | 89 | 55 | 98 | 51 |
| Niedrig | 59 | 19 | 70 | 19 |
Martians Benchmark: 50 Pull Requests, 158 bekannte Fehler, Richter Claude Opus 4.5. Hohe Empfindlichkeit: unser öffentlicher Lauf, 7. Oktober 2026. Mittel und Niedrig: unsere interne Messung auf denselben 50 Pull Requests, Mittel aus 5 Läufen für diffox ultra und 2 für diffox.
Was nicht im Pull Request erscheint, geht nicht verloren. 30 Tage lang liegt es auf Ihrer Seite Feststellungen in der Konsole, und von dort aus können Sie alles davon veröffentlichen.
Die Ausgabe besteht aus zwei Teilen: einem zusammenfassenden Kommentar im Pull Request und, für jede Feststellung, einem Kommentar direkt unter der betroffenen Zeile. Lässt sich eine Feststellung beheben, enthält sie eine vorgeschlagene Korrektur, die GitHub mit einem Klick übernimmt; der Commit läuft unter Ihrem Namen. Titel und vorgeschlagene Korrekturen entstehen erst nach der Auswahl und nur für die Feststellungen, die veröffentlicht werden. Das Review kommt in der Sprache Ihres Teams. Die letzte Zeile der Zusammenfassung nennt den Preis des Reviews, seine Dauer und den gelesenen Commit.
Der Status von diffox in einem Pull Request wird nie rot: Ob gemergt wird, entscheidet Ihr Team. Mit jedem 👍 und 👎 auf seine Kommentare lernt diffox Sie und Ihr Repository besser kennen, und seine Reviews passen mit der Zeit immer besser zu Ihrem Team.
Was diffox ultra anders macht
diffox ultra durchläuft dieselben vier Phasen; der Unterschied liegt in der zweiten und der vierten. Zwei getrennte Modelle lesen die Änderung, und jedes führt von Anfang bis Ende ein eigenes Review durch. Beide Reviews laufen parallel und werden als eines veröffentlicht. In der Auswahl arbeitet zusätzlich ein drittes, kleines Entscheidungsmodell: Es schreibt keinen Text, sondern beantwortet zu jeder Feststellung Ja-Nein-Fragen. Die Auswahl bewertet die Feststellungen beider Reviews zusammen mit diesen Antworten. Zeigen beide Modelle auf dieselbe Stelle, spricht das für die Feststellung. Nach der Auswahl erkennt das Entscheidungsmodell Feststellungen, die auf dieselbe Ursache zurückgehen, und fasst sie zu einer zusammen.
Das Ergebnis steht in den ersten beiden Beiträgen: diffox ultra fand 119 der 158 bekannten Fehler, diffox 106; ein Review mit diffox ultra kostet im Schnitt $1,64, eines mit diffox $0,41.
Häufige Fragen
Warum nutzt diffox spezialisierte Agenten?
„Ist hier ein Fehler?“ ist eine weite Frage, und entsprechend weit fällt die Antwort aus. Jeder spezialisierte Agent sucht nach genau einer Sache und muss seinen Fund mit einem Zitat aus dem Code belegen. So sehen Sie, von welchem Agenten jede Feststellung stammt.
Kann ich diffox eigene Review-Regeln vorgeben?
Ja. Die Regeln, die Sie in AGENTS.md oder CLAUDE.md im Wurzelverzeichnis Ihres Repositorys festhalten, werden bei jedem Review gelesen, und ein eigener Agent sucht nach Zeilen, die gegen sie verstoßen. Gelesen werden die Regeln aus dem Branch, in den der Pull Request gemergt wird. Ändert ein Pull Request die Regeldatei, gilt die Änderung also erst nach dem Merge.
Wozu dienen 👍 und 👎?
Mit jeder Reaktion lernt diffox Sie und Ihr Repository besser kennen: was Ihnen wichtig ist und was nur Rauschen ist. Seine Reviews passen mit der Zeit immer besser zu Ihrem Team.
Blockiert diffox einen Merge?
Nein. Der Status von diffox in einem Pull Request wird nie rot und ist keine Pflichtprüfung; Ihr Team mergt, wann es will.
Wird bei jedem Push der ganze Pull Request erneut geprüft?
Nein. diffox prüft jeden Push automatisch, liest aber nur die neue Änderung. Nach den ersten 5 Pushes prüft es nur noch, wenn Sie es anfordern; diese Zahl können Sie in der Konsole ändern.
Warum erscheinen Vorschläge nicht im Pull Request?
In unseren Messungen brachten auch veröffentlichte Vorschläge mehr Kommentare in den Pull Request und senkten den Anteil echter Fehler darunter. Deshalb erscheinen im Pull Request kritische Feststellungen und Warnungen. Vorschläge gehen nicht verloren; auf der Seite Feststellungen warten sie 30 Tage, und von dort aus veröffentlichen Sie jeden davon.
Speichert diffox meinen Code?
Nein. diffox behält keine Kopie des geprüften Codes; die Kopie des Repositorys wird gelöscht, sobald die Prüfung endet. Welche Dienste genutzt werden, steht auf unserer Datenschutzseite.
Weiter: das Entscheidungsmodell
Der vierte Beitrag beschreibt das Entscheidungsmodell, das diffox ultra damals in der vierten Phase nutzte, und die Regel, die wir aus unseren Messungen abgeleitet haben: Wie wir Jev im KI-Code-Review für zwei Aufgaben einsetzen.