OpenCodeReview: Feste Prüfregeln und ein LLM-Agent teilen sich das Code-Review
Alibabas quelloffenes CLI prüft Git-Diffs oder vollständige Dateien, holt bei Bedarf Repository-Kontext hinzu und erzeugt strukturierte Kommentare an den betroffenen Zeilen.
Geteilte Verantwortung
Eine deterministische Pipeline übernimmt Auswahl, Bündelung, Regeln und Positionierung. Der LLM-Agent untersucht ergänzend den Repository-Kontext, wenn der sichtbare Diff für eine belastbare Bewertung nicht ausreicht.
Vier Review-Ziele
Prüfbar sind Pull Requests, Commits sowie gestagte und ungestagte Änderungen.
Menschen geben frei
Vorgeschlagene Korrekturen werden nicht automatisch ohne menschliche Prüfung übernommen.
OpenCodeReview setzt nicht darauf, ein komplettes Code-Review in einen einzigen Modellaufruf zu verpacken. Das quelloffene CLI von Alibaba trennt berechenbare Aufgaben von kontextabhängiger Analyse: Eine deterministische Pipeline wählt Dateien aus, bündelt Inhalte, weist Regeln zu und verankert Kommentare an konkreten Zeilen. Ein LLM-Agent kann zusätzlich Dateien lesen, das Repository durchsuchen und weitere Änderungen als Kontext heranziehen.
Auf der Release-Seite war am 17. September 2026 die Version 1.12.5 aufgeführt. Das Werkzeug unterstützt laut Repository mehr als 40 Programmiersprachen und Dateitypen. Es richtet sich damit nicht nur an einzelne Entwickler, die vor einem Commit eine zweite Einschätzung suchen, sondern auch an Plattformteams, die maschinelle Reviews in bestehende CI-Systeme einhängen möchten.
Das ist an der Kombination neu
Bei einem reinen LLM-Review muss das Modell häufig zugleich entscheiden, welche Dateien relevant sind, wie viel davon in eine Anfrage passt, welche Regel gilt und an welcher Stelle ein Befund ausgegeben werden soll. OpenCodeReview verschiebt diese mechanischen Entscheidungen in eine feste Pipeline. Der Agent erhält dadurch eine enger umrissene Aufgabe: Er untersucht die Bedeutung einer Änderung und beschafft bei Bedarf zusätzlichen Codekontext.
Diese Aufteilung ist mehr als eine technische Feinheit. Dateiauswahl, Bündelung und Kommentarpositionierung sollen bei identischer Eingabe reproduzierbar bleiben. Sprachmodelle werden für jene Fragen eingesetzt, bei denen semantische Zusammenhänge zählen: Passt ein neuer Aufruf zur vorhandenen Schnittstelle? Wird eine Annahme aus einem anderen Modul verletzt? Ändert eine Konfiguration die Bedeutung der bearbeiteten Zeile?
Das Ergebnis sind strukturierte Kommentare auf Zeilenebene statt einer losen Zusammenfassung des gesamten Diffs. Ein Hinweis bleibt dadurch an der Stelle sichtbar, an der er überprüft und diskutiert werden kann. Genau diese Verbindung aus fester Platzierung und flexibel beschafftem Kontext ist die Kernidee des Werkzeugs.
Ein Diff wird nicht isoliert betrachtet
Angenommen, ein Pull Request ändert in einem Dienst nur wenige Zeilen: Ein Funktionsaufruf erhält einen zusätzlichen Parameter, und eine Fehlerbehandlung wird verkürzt. Der Diff allein zeigt zwar die Änderung, aber nicht zwingend den Vertrag der Funktion, die zulässigen Parameterwerte oder eine Konvention in einem benachbarten Modul.
Der Agent von OpenCodeReview kann für diese Prüfung weitere Dateien lesen und das Repository durchsuchen. Er kann somit die Definition der aufgerufenen Funktion, verwandte Verwendungsstellen oder zusätzlich geänderte Dateien in die Analyse einbeziehen. Die deterministische Ebene hält unterdessen fest, welche Ausgangsdatei geprüft wird, welcher Regelbestand anzuwenden ist und wo ein gefundener Hinweis hingehört.
Damit wird eine Aufgabe möglich, die bei einem einfachen Diff-Prompt leicht brüchig bleibt: Ein lokaler Codeausschnitt lässt sich gegen den tatsächlich vorhandenen Repository-Kontext prüfen, ohne sämtliche Dateien pauschal in den Modellkontext zu kopieren. Der Agent sucht gezielt nach den Informationen, die für die konkrete Änderung relevant sind.
Vier Arten von Änderungen lassen sich direkt prüfen
Die Integrationsdokumentation nennt Pull Requests, einzelne Commits sowie gestagte und ungestagte Änderungen als unterstützte Ziele. Dadurch kann dieselbe Review-Logik an unterschiedlichen Punkten der Entwicklung eingesetzt werden.
Bei ungestagten Änderungen eignet sich das CLI für eine frühe Prüfung während der Arbeit. Ein Review der gestagten Dateien konzentriert sich dagegen auf genau den Stand, der für den nächsten Commit vorgesehen ist. Die Prüfung eines Commits erlaubt eine abgeschlossene Änderungseinheit zu analysieren, während ein Pull-Request-Review mehrere zusammengehörige Commits im vorgesehenen Integrationskontext betrachtet.
Auch vollständige Dateien können analysiert werden. Das ist nützlich, wenn eine Regel nicht nur die geänderten Zeilen betrifft oder wenn der Diff zu wenig strukturellen Zusammenhang liefert. Die Auswahl zwischen Diff und vollständiger Datei verändert also nicht den Zweck des Reviews, sondern die verfügbare Betrachtungsfläche.
So nutzt man die Aufgabenteilung sinnvoll
Der erste sinnvolle Einsatzpunkt ist ein lokaler Review vor dem Commit. OpenCodeReview wird unter anderem als npm-Paket @alibaba-group/open-code-review angeboten; laut Repository wird außerdem Git ab Version 2.41 vorausgesetzt. Nach der Installation benötigt das CLI einen konfigurierten LLM-Anbieter. Anschließend kann die Prüfung auf die ungestagten Änderungen oder den bereits vorbereiteten Staging-Bereich gerichtet werden.
Für kleine Änderungen ist ein enger Zielbereich meist aussagekräftiger als ein pauschaler Scan des gesamten Projekts. Wer beispielsweise einen API-Aufruf geändert hat, lässt den Diff prüfen und erlaubt dem Agenten, die zugehörige Definition und weitere Aufrufstellen zu finden. Bei einer übergreifenden Regeländerung kann dagegen die vollständige Datei den notwendigen strukturellen Zusammenhang liefern.
In einer CI-Umgebung bietet sich der Pull Request als Einheit an. Die Pipeline kann das Review nach der Erstellung oder Aktualisierung des Pull Requests starten und die strukturierten Hinweise an den betroffenen Zeilen bereitstellen. Die menschliche Prüfung bleibt Teil der Entscheidung: Die Roadmap sieht keine automatische Übernahme vorgeschlagener Änderungen ohne Freigabe vor.
Eigene Regeln treffen auf Repository-Kontext
Die Regelzuordnung in der deterministischen Pipeline ist besonders interessant, wenn ein Repository mehr verlangt als allgemeine Stilhinweise. Ein Team kann Review-Vorgaben an bestimmte Dateien oder Änderungstypen binden, während der Agent den Code untersucht, der für die Anwendung dieser Vorgaben relevant ist.
Ein Beispiel ist eine Änderung an einer Zugriffsschicht. Die feste Ebene kann dafür vorgesehene Review-Regeln auswählen. Der Agent kann anschließend nach ähnlichen Zugriffen, Typdefinitionen oder der Konfiguration suchen, die das Verhalten beeinflusst. Der Kommentar wird nicht als allgemeine Warnung ausgegeben, sondern an der betreffenden Zeile platziert.
Frühere Einträge auf der Release-Seite nennen unter anderem Reviews mit Rego-Policies. Das erweitert die Kombination um einen weiteren kontrollierbaren Baustein: Formale Richtlinien und semantische Modellanalyse können denselben Änderungssatz aus unterschiedlichen Blickwinkeln prüfen. Die feste Policy entscheidet über explizit formulierbare Bedingungen; der Agent hilft bei Zusammenhängen, die erst aus mehreren Dateien verständlich werden.
Die Modellauswahl bleibt beim Betreiber
OpenCodeReview liefert selbst kein Sprachmodell aus. Nach der Integrationsdokumentation kann das CLI Modellendpunkte über Anthropic Messages, OpenAI Chat Completions, OpenAI Responses und AWS Bedrock ansprechen. Das Werkzeug legt damit die Review-Orchestrierung fest, während Modellzugang, Abrechnung und Anbieterwahl außerhalb des Projekts bleiben.
Diese Trennung erlaubt es, den Review-Mechanismus beizubehalten und den Modellendpunkt passend zur vorhandenen Infrastruktur auszuwählen. Wer bereits einen Zugang zu Anthropic oder OpenAI verwaltet, kann den entsprechenden Protokollweg nutzen. In einer AWS-Umgebung kann Bedrock die Verbindung zu den dort verfügbaren Modellen herstellen.
Kosten und Nutzungsgrenzen ergeben sich folglich aus dem gewählten Modellanbieter und dem Umfang der übermittelten Inhalte, nicht aus einem mitgelieferten OpenCodeReview-Modell. Die gezielte Kontextsuche ist deshalb auch betrieblich relevant: Zusätzliche Dateien sollten einen konkreten Erkenntniszweck erfüllen, statt das Repository unterschiedslos an das Modell zu senden.
Kein allgemeiner Coding-Assistent
Die Roadmap grenzt das Projekt ausdrücklich von Chat-, Codegenerierungs- und Refactoring-Werkzeugen ab. OpenCodeReview soll Code beurteilen und Korrekturen vorschlagen, aber nicht selbstständig als universeller Programmieragent auftreten. Diese Konzentration erklärt auch die Bedeutung der zeilengenauen Ausgabe.
Ein allgemeiner Assistent optimiert häufig auf die Erzeugung eines Ergebnisses: eine neue Funktion, einen Patch oder eine umgebaute Datei. OpenCodeReview optimiert dagegen auf nachvollziehbare Befunde zu einer vorliegenden Änderung. Der Entwickler sieht, welche Stelle beanstandet wird, kann den herangezogenen Kontext bewerten und entscheidet selbst über eine Anpassung.
Diese Grenze verhindert nicht, dass Hinweise in weitere Werkzeuge übernommen werden. Sie hält aber die Zuständigkeiten klar: Das CLI analysiert und kommentiert; Menschen genehmigen Änderungen. Wer vollautomatische Reparaturen sucht, benötigt dafür ein separates Werkzeug und eine eigene Freigabelogik.
Wo OpenCodeReview besonders gut passt
Der Ansatz ist attraktiv für Repositories, in denen allgemeine Modellhinweise allein zu ungenau sind, ein rein regelbasierter Prüfer aber semantische Zusammenhänge übersieht. Die Pipeline sorgt für eine konsistente Prüfgrundlage, während der Agent bei Bedarf über den sichtbaren Diff hinausschaut.
Für Einzelentwickler ist vor allem die lokale Auswahl zwischen ungestagten Änderungen, Staging-Bereich und Commit praktisch. Plattformteams erhalten eine CLI, die sich in CI-Systeme einbinden lässt und mehrere Modellprotokolle unterstützt. In beiden Fällen bleibt das Ergebnis ein Review-Vorschlag und keine automatisch ausgeführte Änderung.
Die interessanteste Anwendung ist daher nicht der möglichst große Repository-Scan. Es ist die gezielte Verbindung: ein klar abgegrenzter Änderungssatz, passende Regeln und ein Agent, der genau den fehlenden Kontext beschafft. So ergänzt das Modell die deterministische Prüfung, ohne deren reproduzierbare Aufgaben zu übernehmen.