OpenCodeReview AI Code Review in der Praxis: Wie viele Bugs, Sicherheitslücken und Qualitätsfunde findet es in einem echten Git-Diff?

Zuerst: Was OpenCodeReview wirklich prüft

Oft wird das mit OpenCode (Coding-Agent hinter opencode serve) in einen Topf geworfen. Anderes Produkt. OpenCodeReview ist Alibabas interner AI-Review-Assistent als CLI: Git-Änderungen lesen, strukturierte Zeilenkommentare, eingebaute Regeln (NPE, Threadsicherheit, XSS, SQL-Injection), OpenAI- und Anthropic-kompatible Endpunkte. Quelle: alibaba/open-code-review. Docs: open-codereview.ai.

Es ist kein Bot, der PRs lobt. Ein Chatmodell sieht nur das eingefügte Fragment. Es öffnet keine Caller und weiß nicht, ob die Nachbardatei schon die Sperre hält. Die Wette ist deterministische Triage plus tiefer Agent: entscheiden, was geprüft wird, Checkliste je Dateityp injizieren, dann file_read, Suche, Vergleich anderer geänderter Dateien.

Wir haben bereits 4GB / 8GB / 16GB für selbst gehostetes OpenCode beschrieben — das ist die RAM-Rechnung des Coding-Agents. Dieser Artikel ist nur ocr review: automatische Git-Diff-, Bug-, Security- und Qualitätsprüfung und wie viele Befunde ein echtes Projekt liefert.

Die Vendor-Linie lautet „Zehntausende Entwickler, Millionen Defekte“. Das ist Alibaba-Historie, kein Versprechen für euren nächsten PR. Zweite Augen vor dem Merge: passend. Maschine soll Production freigeben: weder README noch dieser Test unterschreiben.

Git-Diff lesen: drei Modi

Wer „Git-Diff automatisch prüfen“ sucht, meint „was habe ich geändert“. Die CLI teilt das in drei sich ausschließende Modi — Mischen ist ein harter Fehler. Flags: CLI Reference.

Range nutzt merge-base und liegt näher an menschlichem PR-Review als ein roher Zwei-Branch-Diff: spätere Commits auf main schwemmen nicht ein. Die offizielle GitHub Action macht dasselbe: merge-base, dann ocr review --from MERGE_BASE --to HEAD_SHA --format json, Inline-Kommentare auf den PR.

Vierter Weg: ocr scan — ganze Dateien, ohne sinnvolle Git-Historie, sinnvoll beim Erben eines Verzeichnisses. Tokens und Rauschen steigen. Für Merge zuerst Diff; Legacy-Baum später scannen.

Immer zuerst ocr review --preview. Nur Filter, kein Modellgeld. Ihr seht will_review gegen Extension / Löschung / Testpfad. In unserem Lauf verlor ein PR mit Bildern und Lockfiles etwa die Hälfte der „sieht riesig aus“-Dateien, bevor das LLM sie sah — korrekt.

Fünf Minuten: Install, Modell, Preview

npm global ist der Default. Es gibt install.sh und ein statisches Binary von GitHub Releases. Git ≥ 2.41. Ohne konfiguriertes Modell erfindet ocr review keine Kommentare (außer Delegation Mode an einen Coding-Agent, den ihr schon bezahlt).

npm install -g @alibaba-group/open-code-review
ocr version
ocr config provider
ocr config model
ocr llm test

cd /path/to/your-repo
ocr review --preview
ocr review --from main --to HEAD --format json --audience agent

Config liegt in ~/.opencodereview/config.json. In CI schreibt ocr config set Provider / Modell / Key, oder ihr nutzt ANTHROPIC_* / OCR_LLM_*. Kommentarsprache: ocr config set language Deutsch (Default Englisch). .opencodereview/rule.json darf ins Repo; Keys nicht.

Der npm-Wrapper aktualisiert im Hintergrund (~18 Minuten Cooldown). In CI Version pinnen und OCR_NO_UPDATE=1. Sessions unter ~/.opencodereview/sessions/. ocr viewer auf localhost:5483 zum Replay, kein öffentlicher Dienst.

Die OpenCode-Selfhost-RAM-Zahlen nicht kopieren. Schwer ist die LLM-API und parallele Git-Subprozesse; kein warmes LSP. Default --concurrency ist 8. Klapptdeck mitten im Range-Review hinterlässt eine Session zum --resume. Eine wache Maschine ist ehrlicher als eine Reise-Notebook-Wette.

Praxis: drei echte Change-Packs

Gleiche Config (OpenAI-kompatibel, mittelgroßes Chatmodell, Systemregeln plus Projekregel) gegen drei PR-förmige Packs — kein Zehn-Zeilen-Spielzeug. Jedes Pack: --preview, dann ocr review --from --to --format json. Labels: must-fix, should-fix, Stil, False Positive. Ein Snapshot; anderes Modell, andere Zahlen. Die Mischung zählt mehr als die Headline.

Must-fix (7): drei Security, vier Defekte. Security: zusammengebaute Queries, unescaped HTML-Ausgabe, interne Fehlertexte an den Client. Defekte: Nil als Objekt, Map-Write ohne Lock, Fehler ohne %w. Das landet im beworbenen Ruleset — NPE, Threads, XSS, SQL — kein Aufsatz.

Should-fix (6): fehlende Timeouts, Retries auf nicht-idempotente Calls, Logs mit Mail oder Body. Ein Mensch sollte sie nennen; Freitagnachmittag oft nicht. Der Agent wird nicht müde.

Stil (10) ist der größte Eimer. Namen, Early Returns, „zieh die Funktion raus“. Nützlich und verdünnt das Signal. Ungepflegt faltet das Team in Woche drei das ganze Review weg — dieselbe Pathologie lauter PR-Bots.

False Positives (4) waren langweilig im guten Sinn: Fixture-SQL als Produktionsinjection; schon parametrisierte Query erneut gescholten; Loop-Variable von vor Go 1.22. Drei von vier sterben, wenn Testpfade nach --preview ausgeschlossen werden. Filter vor Modell beschuldigen.

Die Größenordnung trifft das offizielle Beispiel: ein Range-Review oft „9 Dateien, ein Dutzend Kommentare, etwa eine Minute, ~20k Tokens“. Unsere drei Packs sind drei isolierte Ranges, kein Mega-PR. Ein Datei-Diff, der ~80% des Tokenfensters frisst, fällt vor dem LLM — generierte Blobs und Lockfiles gehören ins Preview, nicht auf die Rechnung.

Bugs, Security, Qualität: Treffer und Lücken

Die 27 Kommentare nach den vier Worten im Titel zu teilen, ist näher an der Nutzung als eine einzige „Issues gefunden“-Zahl.

Weil der Agent die ganze Datei liest, schlägt er „nur grüne Zeilen“. Das offizielle Map-ohne-Lock-Beispiel ist der Typ: Diff addiert eine Zuweisung; der shared State lebte schon oben. Diff-only-Bots verpassen das; file_read holt Kontext. Das ist die beworbene Lücke zu Patch-only-PR-Reviewern — die sind schneller und leiser und schwächer über Dateien.

Absichtliche Misses: falsche Rabattformel, Währungsfeld als USD gelesen, Endpoint der vor Freigabe zu bleiben hat. Null Kommentare. Das Modell hat euer Fachglossar nicht. --background mit PR-Text hilft. Es ersetzt keinen Menschen bei Requirements.

Security-Kommentare sind Hinweise, keine Urteile. „Hier wird SQL zusammengebaut“ braucht trotzdem Treiber, Rolle und Datenklasse. Dieser Artikel zeigt nicht, wie man die Zeilen ausnutzt — nur ob der Reviewer sie markierte. Schreibgrenzen für Coding-Agents: Dateien sicher ändern mit VFS — Review ist read-only, der Coding-Agent schreibt Platte.

CI: GitHub Actions, Regeln, False Positives

Lokal läuft, Teams wollen Inline-Kommentare. Die offizielle Composite Action checkt eine vertrauenswürdige Base aus (kein untrusted Fork-Worktree), holt Head-Git-Objekte, rechnet merge-base, läuft ocr review --format json und postet Zeilenkommentare plus Sticky-Summary. Trigger: PR opened/synchronized oder /open-code-review.

Least privilege: contents: read; pull-requests: write nur zum Posten. Keys in Secrets, Modellnamen in Variables. Forks bekommen Repo-Secrets nicht — Schutz, kein Bug. Nicht pull_request_target mit Checkout untrusted Codes kombinieren, nur um Forks zu reviewen; das leakt Secrets. GitHub: Security hardening for GitHub Actions.

Regeln in vier Schichten: --rule, Projekt .opencodereview/rule.json, Home-Global, Built-in. ocr rules check zeigt den Gewinner. merge_system_rule: true, damit zwei Log-Hinweise die Java-NPE-Liste nicht löschen. Tests, Generated, Vendor auszuschließen ist billiger als später über False Positives zu streiten.

Unter macOS ist Xcode-Diffs zu reviewen einfach; den Runner am Leben zu halten nicht. Aufbau: GitHub Actions macOS Self-hosted Runner. Eine Maschine, die nicht schläft, mit Keys ohne Laptop-Quota-Kampf, macht Review wiederholbar.