Automatisiertes Code-Review im Jahr 2026: Lassen Sie es auf jedem PR laufen, ohne einen Sitzplatz zu kaufen.

Automatisierte Code-Reviews sind ein CI-Job, der Ihren Diff an ein Sprachmodell sendet, Befunde an den betroffenen Zeilen veröffentlicht und einen Statuscheck fehlschlagen lässt, wenn etwas Ernstes gefunden wird. Um das bei jedem Pull-Request ohne Pro-Sitzplatz-Abo zum Laufen zu bringen, hosten Sie selbst einen Open-Source-Harness: Kopieren Sie ein Workflow von etwa fünfzehn Zeilen in Ihr Repository, fügen Sie einen API-Schlüssel hinzu, und bezahlen Sie nur für die Tokens, die jedes Review verbraucht. Es gibt keine Sitzplatzanzahl zu kaufen, denn es gibt keinen Sitzplatz. Die Referenzimplementierung, die wir pflegen, ist das Orca-Code-Review-Repository — öffentlich, MIT-lizenziert und seit seiner Erstellung am 25. Juni 2026 der Code hinter der GitHub Action OrcaCode Review. Das mitgelieferte Routing-Rezept setzt den Review-Durchlauf standardmäßig auf DeepSeek V4 Flash und den unabhängigen Verifikations-Judge auf GLM-5.3; beide können Sie ändern. Dieser Artikel erläutert, was bei jedem Push tatsächlich ausgeführt wird, was Sie konfigurieren, was es an Token kostet und welche Fehlermodi Ihnen in der zweiten Woche begegnen.

Die Kurzfassung. Jeder Push erhält ein Review. Findings werden inline an den geänderten Zeilen gepostet. P0- und P1-Findings lassen den Check fehlschlagen und blockieren den Merge; ein sauberer Lauf besteht den Check. Du kannst auf Anfrage erneut reviewen, indem du kommentierst: /orcacode-review. Der Workflow liegt in deinem Repo; die Review-Logik liegt in der veröffentlichten Action; die Modellwahl liegt in einem Routing-Rezept, das du in deinem eigenen Workspace bearbeiten kannst. Der Reviewer liest den Diff und die Repository-Dateien und führt den Code deines PRs niemals aus. Und der ehrliche Hinweis vorab: Er findet echte Bugs und übersieht trotzdem diejenigen, die einen Menschen brauchen, der weiß, warum der Code so ist, wie er ist.

• Ein Workflow + ein Secret + eine Token-Abrechnung. Keine Lizenz pro Sitzplatz zu irgendeinem Zeitpunkt.

• Das Harness ist Open Source. Kopiere es, forke es, prüfe es, pinne es auf einen Commit-SHA.

• Das Modell ist eine Einstellung, kein Anbieter. Ändern Sie den Reviewer, indem Sie ein Routing-Rezept bearbeiten, nicht indem Sie YAML umschreiben oder die Action aktualisieren.

• Übergroße Diffs kosten nichts. Die Größenprüfung wird vor dem Modell ausgeführt.

• Es liest deinen Code, führt ihn aber nie aus. Das ist die Sicherheitseigenschaft, die pull_request_target überhaupt sicher zu verwenden macht.

Wie automatisiertes Code-Review tatsächlich funktioniert

Jedes automatisierte Bewertungssystem besteht aus denselben drei Zutaten in unterschiedlicher Verkleidung: einem Ereignis, einem Ausführenden und einem Prüfer.

Das Ereignis ist der Auslöser. Der mitgelieferte Workflow wird durch Pull-Request-Ereignisse ausgelöst – opened, synchronize (ein neuer Push), ready_for_review (ein Entwurf wird als bereit markiert) – sowie durch einen PR-Kommentar. Da er auf pull_request_target ausgeführt wird, wird die Workflow-Definition aus dem Basis-Branch gelesen. Deshalb muss der Workflow im Basis-Branch vorhanden sein, bevor er für einen PR ausgeführt werden kann. Eine Review pro Push; der Concurrency-Block bricht den vorherigen Lauf ab, sodass eine schnelle Folge von Pushes nicht fünf Reviews von veraltetem Code in die Warteschlange stellt.

Der runner ist GitHub Actions auf ubuntu-latest. Der Job benötigt drei Berechtigungen: Lesezugriff auf Inhalte, Schreibzugriff auf Pull Requests (um Inline-Kommentare zu posten) und Schreibzugriff auf Issues (um die Zusammenfassung zu posten und veraltete Kommentare zu bereinigen).

Der Reviewer ist ein Sprachmodell. Die Aktion ruft den PR-Head ab, stellt den Diff und den Repository-Kontext zusammen, den die Engine auswählt, und sendet das an das Review-Modell. Das Ergebnis ist eine Reihe von Findings, die jeweils mit einem Schweregrad gekennzeichnet und an einer Datei und Zeile verankert sind. Die Aktion veröffentlicht sie als Inline-PR-Kommentare und schreibt einen zusammenfassenden Kommentar in einen Marker-Bereich am oberen Rand der PR-Beschreibung, der bei jedem Push an Ort und Stelle ersetzt wird.

Das Gate ist ein Status-Check. GitHub weiß nicht, was „Review“ bedeutet; es weiß nur, ob der Review-Check besteht. Man macht das Gate real, indem man diesen Check in Branch Protection als erforderlich markiert. Das ist der gesamte Mechanismus zur Merge-Blockierung — keine Admin-API-Aufrufe, keine Labels, nur ein fehlgeschlagener erforderlicher Check.

Was nicht passiert: Nichts führt den Code des PR aus. Die Engine liest nur. Genau diese eine Invariante macht den privilegierten pull_request_target-Trigger sicher für die Verwendung mit einem kostenpflichtigen API-Schlüssel.

Der Open-Source-Harness ist das Unterscheidungsmerkmal.

All das oben Genannte trifft auf viele Tools zu. Was für die meisten nicht gilt, ist, dass das Ganze einsehbar und selbst hostbar ist – genau das verschafft Ihnen das Orca-Code-Review-Repository. Es ist ein öffentliches, MIT-lizenziertes GitHub-Repository (JavaScript, erstellt am 25. Juni 2026), das die Überprüfung als wiederverwendbare Composite-GitHub-Action und einen Installer bündelt, und es ist derselbe Code, dendie gehostete OrcaCode-Review-App ausführt.

Verbringe zehn Minuten im Baum, und du kannst jedes Teil benennen, das deinen PR berührt:

• action.yml — die Composite-Action, etwa fünfzehn dokumentierte Eingaben. Darin sind keine Modellnamen fest codiert.

• workflows/orca-code-review.yml — das Beispiel-Consumer-Workflow: die ungefähr fünfzehn Zeilen, die Sie in .github/workflows/.

• recipes/ — das Routing-DSL. Hier wird das Modell tatsächlich ausgewählt.

• Regeln/ — das Schweregrad-Raster (P0–P3), die verbindliche Ausgabeform und eine Konventionsrichtlinie, die das projekteigene Konventionsdokument als nicht vertrauenswürdige Referenzdaten in die Überprüfung einspeist.

• scripts/ — der Präzisionsfilter (L1 plus ein L2-Bewerter), der Diff-Wächter, das Merge-Gate, der Laufbericht und der Token-Zähler. Jedes ist eine kleine, lesbare .mjsDatei mit Tests.

• skills/setup-orca-code-review — der Skill, den der Installer in deinen Coding-Agenten einfügt und der die Installation, Neukonfiguration, Fehlerbehebung und Deinstallation abdeckt.

• .claude-plugin/ — was Claude Code ermöglicht, den Skill als selbstaktualisierendes Plugin zu installieren.

Die Installation ist ein Einzeiler, der Ihrer KI beibringt, was das Produkt ist, und dann aufhört:

npx @orcarouter/code-review

Die CLI erkennt, welche Coding-Agenten du verwendest — der Katalog umfasst 36 Plattformen, von Claude Code, Cursor, Codex, OpenCode und Windsurf bis hin zu GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode und anderen — installiert den Skill und übergibt. Du fragst dann deinen Agenten in einfacher Sprache: „Richte OrcaCode Review in diesem Repo ein,“ „blockiere nur P0,“ „Warum ist das Review nicht gelaufen?“ Der Skill übernimmt den Lebenszyklus: er schreibt den Workflow, führt dich durch den API-Schlüssel, setzt das Gate und stellt nur die Fragen, die wirklich deine sind.

Claude Code kann den Skill stattdessen als Plugin installieren, wodurch er auf dem neuesten Stand bleibt, während sich das Repo weiterentwickelt:

/plugin marketplace add Continuum-AI-Corp/orca-code-review

/plugin install orca-code-review

Überhaupt kein Agent? Der gleiche Lebenszyklus besteht schlicht aus Unterbefehlen — init schreibt den Workflow, reconfigure ändert Blockierungsregeln und Diff-Limits, doctor diagnostiziert Reviews, die nicht ausgeführt werden oder nicht gepostet werden, uninstall entfernt ihn (wobei zuerst der erforderliche Check entfernt wird). Der Skill ist die Haupttür, nicht die einzige Tür. Oder binden Sie es manuell ein: Kopieren Sie den Workflow, fügen Sie ein Geheimnis namens ORCAROUTER_API_KEY hinzu und markieren Sie den review-Check als erforderlich.

Die darunterliegende Engine ist Ali​baba’s Open Code Review, auf eine exakte Version festgepinnt und unter Apache-2.0 lizenziert. OrcaCode entscheidet, wie die Überprüfung erfolgt; OrcaRouter entscheidet, welches Modell sie ausführt. Die Kostenaufstellung für Self-Hosting gegenüber gehostetem Betrieb — was „kostenlos“ tatsächlich kostet, wenn man einen Open-Source-Reviewer selbst hostet — wird in unserem Artikel über offenes Code-Review durchgearbeitet.

Was wird bei jedem Push der Reihe nach ausgeführt?

Es hilft, die Reihenfolge zu kennen, denn jeder Schritt kann unabhängig voneinander fehlschlagen oder übersprungen werden:

• Der Diff-Guard läuft zuerst, bevor das Modell überhaupt läuft. Wenn der Merge-Base-Diff 512 KB überschreitet oder mehr als 300 Dateien betrifft, wird das Review übersprungen und ein Hinweis gepostet. Die Standardeinstellung ist on-oversized-diff: fail, sodass ein über die Grenzen hinaus aufgeblähter Diff nicht ungeprüft durch ein erforderliches Gate gelangen kann. Dies ist auch die Kostenkontrolle: Ein übergroßer PR kostet null Token.

• Die Engine prüft den Diff. Ein Durchlauf, mit dateiweiser Nebenläufigkeit (Standard: 24) und einer Obergrenze von 20 Minuten Wanduhrzeit pro Durchlauf.

• Der Präzisionsfilter verarbeitet die Rohbefunde nach. L1, ein deterministischer Filter, prüft das angegebene bestehende Code-Snippet jedes Befunds gegen den geprüften Commit und ordnet Abweichungen neu zu oder verwirft sie. L2, ein LLM-Richter, gruppiert Befunde nach Grundursache und verwirft Cluster mit geringer Konfidenz. Beide Ebenen sind Soft-Fail: Ein Fehler behält die Befunde der vorherigen Stufe und bricht die Überprüfung nie ab.

• Das Gate gilt. P0- und P1-Funde lassen den Check fehlschlagen; die PR-Zusammenfassung zählt jeden Fund, einschließlich der im Diff stummgeschalteten.

• Der Zähler druckt aus, was es gekostet hat. Die Zählereingabe erfasst die Token-Abrechnung pro Aufruf — Prompt, Completion, gecachte Token und das Modell, das der Router aufgelöst hat — und druckt eine Gesamttabelle im Job-Log.

• Ein optionaler Laufbericht sendet Schweregrad-Zählungen und Gate-Metadaten an die OrcaRouter-Control-Plane für das Analytics-Dashboard. Er enthält keinen Code, kein Diff und keinen Finding-Text.

Was Sie tatsächlich konfigurieren

Es gibt drei Angriffsflächen, und sie haben einen sehr unterschiedlichen Sprengradius.

1. Die Workflow-Datei. Der Consumer-Workflow ist bewusst schlank gehalten. Die Eingaben, die man anpassen sollte, liegen in der Action: block-on (welche Schweregrade den Check fehlschlagen lassen – Standard P0,P1), fix-first (welche Schweregrade eine vollständige Überprüfung vorzeitig beenden), auto-review-authors (eine Allowlist dafür, wer automatisch überprüft wird), max-diff-kb und max-diff-files und on-oversized-diff (der Größenschutz), timeout-minutes, concurrency, meter, und report. Jeder hat einen dokumentierten Standardwert, daher ist ein neuer Workflow nur fünf Zeilen YAML plus ein Secret.

2. Das Dashboard. Mit settings: true (der Standardeinstellung) ruft jeder Lauf die pro Repository festgelegten Einstellungen von OrcaRouter → Apps → OrcaCode Review ab: das Modell, den Review-Modus, die Merge-Richtlinie, die Schweregrade von Meldungen, den stillen Modus, die umfassende Überprüfung, eine benutzerdefinierte Rubrik und Guardrails. Setzen Sie settings: "false" und die Workflow-Datei ist maßgeblich — kein Dashboard-Wert kann sie außer Kraft setzen. Wenn Sie die Konsole nie öffnen, verlieren Sie nichts von der Funktionalität; Sie konfigurieren einfach in YAML.

3. Das Routing-Rezept — das die Leute übersehen. Die Action nennt nie ein Modell. Stattdessen injiziert sie Rohdaten als Request-Header — als welche Stufe der Lauf aufgezeichnet wurde, ob der vorherige Durchlauf ein P0/P1 gefunden hat, und einen Lens-Marker, wenn die Anfrage der L2-Judge ist — und das DSL-Rezept des Workspace-Routers mappt diese Header auf ein konkretes Modell. Das mitgelieferte Rezept setzt die Review standardmäßig auf DeepSeek V4 Flash und den Judge auf GLM-5.3 und routet die beiden absichtlich auf getrennte Modelle. Das Ändern des Modells, das deinen Code überprüft, ist eine Änderung an diesem Rezept in deinem eigenen Workspace: kein Action-Versions-Bump, kein YAML-Rewrite, kein Redeploy.

Der Schweregrad-Vertrag besteht aus zwei unabhängigen Einstellungen, nicht einer. Merge-Richtlinie entscheidet, was den Merge blockiert; Bericht-Schweregrade entscheiden, was im Diff veröffentlicht wird. Die mitgelieferten Standardeinstellungen lauten: P0/P1 blockieren, P2/P3 bestehen. Ein Schweregrad, der blockiert, wird immer veröffentlicht, egal was die Berichtseinstellung sagt – ein fehlgeschlagener Check, für den das Diff keine Erklärung liefert, ist schlimmer als einer, der Rauschen erzeugt. P0 bedeutet eine ausnutzbare Sicherheitslücke, Datenverlust, einen Absturz auf einem normalen Pfad oder einen defekten Build; P1 bedeutet einen echten, aber eingegrenzten Fehler; P2 bedeutet einen echten Defekt, der nur unter einer abnormalen Vorbedingung auslöst; P3 ist Stil. Wenn man zwischen zwei Stufen hin- und hergerissen ist, besagt das Regelwerk, die niedrigere zu wählen.

Was es kostet

Pro Token, nicht pro Sitzplatz. Sie wählen das Modell auf OrcaRouter, die Abrechnung erfolgt pro verbrauchtem Token, und der Zählermacht den Wert pro Durchlauf sichtbar, statt ihn im Unklaren zu lassen. Die GitHub-Mechanik, die nach Verbrauch abgerechnete Code-Review-Funktion von Copilot seit dem 1. Juni 2026 und wie sich Drittanbieter-Reviewer in diesen Workflow einfügen, werden in unserem GitHub-Code-Review-Leitfaden behandelt. Der vollständige Kostenvergleich Feld für Feld — Sitzplatzprodukte vs. Token-basierte Produkte, mit einem durchgerechneten Beispiel — findet sich in unserem Vergleich der KI-Code-Review-Tools, und die Frage, was ein einzelner Review-Durchlauf an Tokens kostet, wenn der Reviewer das Repository tatsächlich erkundet (die Unterscheidung Bot vs. Agent), wird in unserem Beitrag über Code-Review-Agenten behandelt. Der Punkt, den dieser Artikel hinzufügt, ist die Form der Rechnung: Sie skaliert mit dem Code, den Sie reviewen, nicht mit der Personenzahl, die den Review durchführt.

Zwei Ausgabenkontrollen sind am ersten Tag wichtig. In einem öffentlichen Repository gilt: pull_request_target umgeht das Fork-Genehmigungsgate von GitHub, und der Review-Schlüssel wird über das Wallet abgerechnet — ein Fremder kann eine PR eröffnen und kostenpflichtige Reviews auslösen. Legen Sie für den Schlüssel ein Wallet-Budget mit Benachrichtigungen fest und setzen Sie auto-review-authors auf etwas wie OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR, damit unbekannte Mitwirkende keine automatischen Reviews erhalten. Und der Diff-Schutz bedeutet, wie erwähnt, dass übermäßig große PRs überhaupt nichts kosten.

Was bricht?

Automatisiertes Review ist CI. Es bricht wie CI, und die Fehlermodi sind meistens nicht die Schuld des Modells:

• Der Workflow wird nie ausgeführt. Für pull_request_target wird der Workflow aus dem Basis-Branch gelesen — ein Workflow, der nur im PR-Branch hinzugefügt wurde, läuft erst, wenn er gemerged wird. Prüfe außerdem, ob die App aktiviert ist, auto_review eingeschaltet ist, der PR kein Entwurf ist (Entwürfe werden im ready_for_review-Modus übersprungen) und Actions im Repository aktiviert sind (bei Fork-Repos sind sie standardmäßig deaktiviert).

• /orcacode-review tut nichts. Der Kommentar-Trigger erfordert, dass der Kommentar mit einer von vier Schreibweisen beginnt — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — und der Kommentator ein OWNER, MEMBER oder COLLABORATOR sein muss. Ein führendes Leerzeichen bricht die Übereinstimmung. Der Befehl eines externen Mitwirkenden wird stillschweigend ignoriert, absichtlich: Der Befehl führt einen privilegierten Workflow aus, der den bezahlten Schlüssel enthält.

• Ein Authentifizierungsfehler. Das Secret ist falsch benannt oder fehlt, der Schlüssel ist widerrufen oder hat das Budget überschritten, oder der Workflow wurde umgestellt auf pull_request (das keine Secrets aus Forks lesen kann).

• Der Check ist rot mit einem Hinweis “Diff zu groß”. Das ist der Größenwächter, der wie konfiguriert funktioniert. Teile den PR auf, erhöhe die Limits oder setze on-oversized-diff: pass — und verstehe, dass bei einem erforderlichen Check pass bedeutet, dass ein ausreichend großer PR direkt ungeprüft durch das Gate geht.

• Der Review läuft, aber es erscheinen keine Kommentare. Drei Ursachen, alle harmlos oder konfigurationsbedingt: Ein sauberer Lauf veröffentlicht eine Zusammenfassung statt Inline-Kommentaren; der Quiet-Modus unterdrückt P2 beim Veröffentlichen (das Gate und der Bericht haben es trotzdem gezählt); oder der Präzisionsfilter hat die Befunde verworfen — L1 verwirft Befunde, deren Snippet nicht mit dem Commit übereinstimmt, L2 verwirft Cluster mit niedriger Konfidenz. Die Schweregrad-Zählungen im Job-Log verraten Ihnen, welche davon.

Die Sicherheitslage verdient eine klare Darstellung, denn sie ist es, die das gesamte Design sicher macht. Die Engine liest nur die Diff- und Repository-Dateien; sie führt niemals PR-Code aus. Der Reviewer hat keine Merge-Berechtigung — Befunde können einen Merge blockieren oder einen Kommentar hinzufügen, aber über keinen Codepfad kann die Modellausgabe das Repository genehmigen oder verändern. Ein nicht gekennzeichneter Befund wird sicherheitshalber als blockierend statt als empfehlend behandelt. Und der Laufbericht enthält weder Code noch Befundtexte. Das zweistufige Setup, das abfängt, was eine einmalige Durchsicht übersieht, ist Gegenstand unseres Artikels zur Sicherheit von KI-Code-Reviews; das obige Bedrohungsmodell ist in der SECURITY.md des Repositorys dokumentiert.

Wenn automatisierte Überprüfung das falsche Werkzeug ist

Es ist öfter falsch, als die Tooling-Anbieter zugeben. Lassen Sie dieses eine Mal aus, wenn:

• Das Problem ist der Kontext, nicht die Menge. Wenn Reviews langsam sind, weil die Reviewer verstehen müssen, warum der Code auf diese Weise geschrieben wurde, trägt ein LLM, das den Diff liest, wenig bei. Es hat keine Erinnerung an den Thread vom letzten Monat und kein Gespür für die Geschichte des Systems.

• Der Diff besteht hauptsächlich aus generiertem oder ausgeliefertem Code. Automatisch formatierte Ausgabe, Gerüstdateien, Abhängigkeits-Snapshots. Das Reviewen verbrennt Tokens und erzeugt Rauschen, und genau hier hilft die Konventionsrichtlinie am wenigsten — der Code entspricht nicht aus freier Wahl dem Stil des Projekts.

• Das Team macht bereits Pair-Reviews für alles. Automatisierte Überprüfung ist ein Volumenhebel. Wenn jede Änderung bereits von einem Menschen überprüft wird, der im Raum war, fügt die Maschine eine zweite Meinung hinzu, die in der Regel weniger informiert ist als die erste.

• Niemand liest die Ergebnisse. Ein Review, auf das niemand reagiert, ist ein Workflow, der für immer grün bleibt und trotzdem scheitert. Das ist der häufigste stille Fehler, und kein Präzisionsfilter behebt ihn.

• Das Review muss den Code ausführen. Wenn du eine Testsuite gegen den PR brauchst, ist ein LLM-Review das falsche Werkzeug. Es liest; es führt nicht aus. Ein Sicherheitsscan, der das Artefakt bauen und ausführen muss, gehört in einen separaten, sorgfältig abgegrenzten Job — denk daran: Der Review-Workflow darf niemals erweitert werden, um PR-kontrollierten Code auszuführen.

• Das Repository ist winzig oder wegwerfbar. Unterhalb einer bestimmten Änderungsrate ist das Review mehr Overhead als die Fehler, die es findet.

Falschpositive: Was Präzisionsfilterung behebt und was nicht.

Der Vorwurf gegenüber jedem KI-Prüfer ist, dass er falschen Alarm schlägt. Das Harness geht das auf zwei Ebenen an, und es hilft, präzise zu sein, welche Ebene welchen Fehler behebt.

Die deterministische Schicht (L1) beseitigt den Geisterfund: eine Engine verweist manchmal auf Code, den es gar nicht gibt — ein Snippet, das verrutscht ist, ein Finding, das in eine Schwesterdatei kopiert wurde. L1 gleicht das Snippet des vorhandenen Codes jedes Findings mit dem tatsächlich geprüften Commit ab und verlegt oder verwirft Abweichungen. Das behebt die Klasse von Fehlalarmen der Art „diese Zeile existiert gar nicht“, die mechanisch und verifizierbar ist.

Die Judge-Ebene (L2) eliminiert das Duplikat und die unbelegte Behauptung: Ein LLM-Judge gruppiert Erkenntnisse nach Grundursache und verwirft Cluster, deren Konfidenz unter dem Judge-Schwellenwert (Standard 0,5) liegt. Das behebt die “Meldung desselben Bugs auf drei Arten” und die spekulative Erkenntnis.

Es lohnt sich, laut auszusprechen, was keine der beiden Ebenen behebt. Ein falscher, aber selbstbewusster Befund überlebt den Richter — der Richter ist ein LLM, und ein LLM, das sicher klingt, ist nicht dasselbe wie ein Befund, der wahr ist. Ein Richter, der auf dem eigenen Modell des Reviewers läuft, stimmt mit sich selbst überein, und der Durchlauf wird wirkungslos, während er weiterhin Erfolg meldet. Deshalb leitet das ausgelieferte Rezept den Richter an ein anderes Modell weiter als an das des Reviewers. Und die Schweregrad-Rubrik ist absichtlich konservativ — „Wenn man zwischen zwei Stufen hin- und hergerissen ist, wähle die niedrigere“ — was bedeutet, dass ein echter, aber bedingter Fehler eher als P2-Hinweis denn als blockierender P1 eingestuft wird. Das ist die richtige Kalibrierung für ein Tool, das nicht alles blockieren darf, aber es ist eine Kalibrierung: Sie tauscht übersehene Blocker gegen weniger Fehlalarme. Die PR-Zusammenfassung führt immer jeden Befund auf, sodass die abgeschwächten P2s weiterhin zu lesen sind. Wenn der Kompromiss für Ihr Team falsch ist, sind die Rubrik und die Richter-Schwelle Konfiguration, kein Support-Ticket.

Das Fazit

Für ein Team, das bereits in GitHub Actions lebt, ist das Open-Source-Tooling der günstigste Weg, um bei jedem Pull Request automatisches Code-Review zu erhalten: eine Workflow-Datei, ein Secret, eine Token-Abrechnung, die mit dem überprüften Code skaliert, und eine Modellauswahl, die Sie selbst bestimmen. Kaufen Sie ein pro Benutzer lizenziertes Produkt, wenn Sie keinerlei Betriebsaufwand und einen Ansprechpartner beim Anbieter möchten – nicht weil das Review besser ist, sondern weil Sie das Problem von jemand anderem kaufen, anstatt sich um Ihr eigenes zu kümmern. Und bevor Sie irgendetwas davon einrichten, fragen Sie sich, ob das Review auch gelesen wird. Das Tooling kann das Review automatisch erstellen. Es kann aber niemanden dazu bringen, es zu lesen.

Möchten Sie denselben Reviewer nutzen, ohne ihn selbst auszuführen? OrcaCode Review führt genau diese Testumgebung als gehostete GitHub-App aus — dasselbe offene Rezept, dieselbe Abrechnung pro Token, keine Seats.