KI-Code-Review-Tools lernen Review-Regeln aus der Pull-Request-Historie
Die echten Code-Review-Standards eines Teams stecken meist in PR-Kommentaren, waehrend Dateien wie CLAUDE.md nur erfassen, was jemand zufaellig dokumentiert hat. Neue AI-Tools sollen diese Regeln automatisch aus der Historie ableiten.
Ich schreibe darueber, wie Engineering-Teams Review-Standards aufbauen und aufrechterhalten, zuletzt darueber, was eine base-branch REVIEW.md ueber Agenten-Standards lehrt. Die echten Code-Review-Regeln Ihres Teams leben in Pull-Request-Kommentaren (PR), waehrend CLAUDE.md und AGENTS.md nur enthalten, woran sich jemand zu dokumentieren erinnert hat. Ich habe acht AI-Code-Review-Tools danach gerankt, wie jedes einzelne Review-Historie in Regeln umwandelt: welche Signale das Tool zaehlt, ob jede Regel ihre Quelle anzeigt und wie ungenutzte Regeln ausgemustert werden.
Ein Regelbuch lebt in CLAUDE.md, AGENTS.md oder REVIEW.md. Das andere lebt in den Kommentaren, die erfahrene Reviewer ueber PR nach PR hinterlassen, und niemand schreibt es auf.
Das echte Regelbuch veraendert sich staendig in Review-Threads, und neue Mitarbeitende sowie Coding-Agenten wiederholen Fehler, die das Team schon vor einem Jahr behoben hat.
Ein Tool kann die Wiederholungen in der Review-Historie finden, und die Regeln, die funktionieren, sind kurz, stammen aus echten Korrekturen und bleiben unter menschlicher Beurteilung.
Die Wiederholungen sind auffindbar. Eines der Muster bei Stationwise war die Verwendung von parseISO aus date-fns statt new Date() fuer Datumsstrings, markiert in mehr als 25 unterschiedlichen PRs (Stationwise Engineering, Februar 2026).
Stationwise endgueltige Datei blieb schlank, sodass im Diff noch Platz im Kontext bleibt. Die Maschine fand die Wiederholungen, und die Menschen entschieden, welche davon behaltenswuerdig waren.
Repository-Normen verbessern den Output von Agenten messbar. Agenten, die auf die expliziten und impliziten Normen eines Repos zurueckgriffen und bei Bedarf dessen Git-Historie konsultierten, zeigten eine relative Verbesserung der Norm-Einhaltung von 31,64 bis 45,44 Prozent gegenueber einer Baseline ohne Anleitung, ueber 121 Aufgaben und drei Coding-Modelle hinweg (RepoNorm, Oktober 2026).
Die Liste, die funktioniert, ist kurz und stammt aus echten Korrekturen. Als jeder akzeptierte Review-Kommentar zu einer persistenten Regel fuer einen Coding-Agenten auf einer Plattform mit mehr als 35 Services wurde, wuchs die Liste auf lediglich 18 Regeln an, und die Fehlerklassen, die diese Regeln abdeckten, traten ueber 11 aufgezeichnete Sessions nicht erneut auf, was ein frueher Beleg ist (arXiv, Juli 2026).
Ein Reviewer hat in vielen PRs dieselbe Datums-Korrektur eingefordert (illustrativ).
// Im Review erneut markiert const due = new Date ( invoice. dueDate ); // "2026-11-08" wird als Mitternacht UTC (Coordinated Universal Time) geparst // Was der Reviewer verlangt import { parseISO } from " date-fns "; const due = parseISO ( invoice. dueDate ); Enter fullscreen mode Exit fullscreen mode Was eine geminte Code-Review-Regel vertrauenswuerdig macht Vertrauen in eine geminte Regel laesst sich auf drei Fragen reduzieren.
Der Trichter engt alle Review-Kommentare auf Kommentare ein, die zusammen mit einer Code-Aenderung akzeptiert wurden, dann auf owner-gewichtetes, wiederkehrendes Feedback und schliesslich auf eine einzige Regel mit Geltungsbereich web/**.
Die Regelkarte zeigt drei Zustaende: aktiv mit einem Source-Link zu drei PRs, deaktiviert, nachdem das Team ihre Funde selten umsetzte, und gesperrt, sodass die Regel aktiv bleibt.
Geminte Regeln entfalten den groessten Nutzen, wenn das Review, das sie anwendet, ausserhalb des Agenten liegt, der den Code schreibt, denn man sollte Code nicht mit demselben Tool reviewen, das ihn geschrieben hat.
Ich habe Signal, Quelle und Ausmusterung fuer jedes Tool geprueft, das eigene Review-Regeln aufbaut, und dabei jeweils die eigene Dokumentation der Anbieter stand Oktober 2026 herangezogen.
Qodo liefert Ihnen Regeln, die Ihr Team im Review bereits bewiesen hat, denn Qodos Rule Miner lernt nur aus Kommentaren, die Code veraendert haben. Qodo erstellt Qodo Rules aus Ihren Regel-Dateien, Regeln, die Sie schreiben, und Ihrer PR-Historie und prueft jeden PR mit Rule enforcement gegen diese Regeln.
Qodo eignet sich am besten fuer Plattform- und Staff-Engineers, die Regeln aus echten Korrekturen wollen, bis zu ihren Quell-PRs nachverfolgbar und danach ausgemustert werden, wie oft das Team die Funde umsetzt.
Qodo zaehlt nur akzeptierte Kommentare, die Code veraendert haben, verlinkt jede Regel mit allen beitragenden PRs und mustert Regeln nach Fix-Rate aus, sofern man sie nicht sperrt. Im parseISO-Fall schlaegt der Rule Miner eine Regel mit Geltungsbereich web/** vor, wobei die Quell-PRs nur einen Klick entfernt sind.
CodeRabbit ist ein AI-PR-Reviewer fuer GitHub, GitLab, Azure DevOps und Bitbucket. CodeRabbit erstellt seine Regeln aus Konfiguration, Guideline-Dateien, im Chat geaeusserten Praeferenzen und Learnings, die CodeRabbit waehrend des Reviews ableitet.
CodeRabbit eignet sich am besten fuer Reviewer, die dem Bot Praeferenzen im Chat mitteilen.
Chat-basierte Learnings greifen standardmaessig sofort, mit einer optionalen Freigabeverzoegerung von bis zu 30 Tagen, und abgeleitete Learnings greifen sofort fuer ihren Quell-PR. Nichts mustert ein Learning automatisch aus, und das Dashboard kennzeichnet nie genutzte Learnings. Im parseISO-Fall kommt die Regel ueber Chat, Konfiguration oder ein waehrend des Reviews abgeleitetes Learning.
Greptile ist ein AI-PR-Reviewer fuer GitHub, GitLab, Bitbucket und Cursor Origin, zum Preis von 1 Dollar pro Credit. Greptile lernt aus Team-Kommentaren und ob diese adressiert werden.
Greptile eignet sich am besten fuer Teams, die moechten, dass alltägliche Kommentare und Reaktionen das Review praegen.
Greptile zaehlt, ob Kommentare adressiert wurden, und unterdrueckt ignorierte Kommentartypen. Im parseISO-Fall sind die wiederholten, umgesetzten Anforderungen dokumentierte Inputs, waehrend Greptiles Dokumentation nicht sagt, ob eine gelernte Regel auf ihre Quell-PRs verlinkt (Oktober 2026).
Cursor Bugbot ist Cursors PR-Reviewer, abgerechnet ueber einen Cursor-Plan. Bugbot lernt aus Repository-Aktivitaeten und aus einem expliziten @cursor remember-Kommentar im PR.
Cursor Bugbot eignet sich am besten fuer Engineering-Gruppen, die Regeln mit einem remember-Kommentar im PR hinzufuegen.
Bugbot aktiviert oder deaktiviert gelernte Regeln, je mehr er lernt, und Akzeptanzraten pro Regel zeigen deren Wert. Im parseISO-Fall kommt die Regel ueber aktivitaetsgenerierte Regeln oder einen einzigen @cursor remember-Kommentar.
cubic ist ein AI-PR-Reviewer fuer GitHub, mit Team zum Preis von 40 Dollar pro Entwickler im Monat. cubic lernt aus Antworten und Reaktionen aller Personen und fuegt die Historie von bis zu fuenf Reviewern hinzu, die ein Lead auswaehlt, bis zu vier Jahre zurueck.
cubic eignet sich am besten fuer Leads, die auswaehlen, wessen Reviewer-Historie die Regeln praegt.
cubic verlinkt Kommentare mit dem Learning, das dahintersteht, und eine woechentliche Bereinigung archiviert Learnings, die nicht mehr helfen. Im parseISO-Fall werden die Anforderungen zu einem Input durch Antworten, oder durch die Historie, wenn der Reviewer, der die Korrektur verlangte, beim Onboarding ausgewaehlt wurde.
Kodus ist ein AI-PR-Reviewer fuer GitHub, GitLab, Bitbucket, Azure Repos und Forgejo, mit einem kostenlosen Community-Plan und Teams zum Preis von 10 Dollar pro Entwickler im Monat plus Modell-Tokens.
Kodus eignet sich am besten fuer Teams, die woechentliche Regelvorschlaege aus aktuellen PRs moechten.
Kodus' Dokumentation beschreibt nicht, wie Regeln ausgemustert werden (Oktober 2026). Im parseISO-Fall koennen die Anforderungen zu einer Kandidatenregel werden, wenn sie innerhalb des 3-Monats-Fensters liegen, wobei die Anforderung eines menschlichen Reviewers unter Umstaenden nicht gezaehlt wird.
Bito ist ein AI-PR-Reviewer fuer GitHub, GitLab und Bitbucket, mit eigenen Guidelines im Professional-Plan. Bito lernt daraus, wie Personen auf Bitos eigene Kommentare reagieren.
Bito eignet sich am besten fuer Teams, die den Bot durch Reaktionen auf seine Kommentare korrigieren.
Bito dokumentiert keine automatische Ausmusterung, daher werden Regeln von Hand abgeschaltet. Im parseISO-Fall wird die Anforderung eines menschlichen Reviewers zu einer Regel, sobald jemand sie in eine Guideline schreibt.
Copilot code review ist Copilots PR-Reviewer auf GitHub.com und in Azure DevOps, in kostenpflichtigen Copilot-Plaenen, bei denen Reviews AI-Credits nutzen. Copilot code review folgt den Instruction-Dateien und Skills, die Ihr Team schreibt.
Copilot code review eignet sich am besten fuer Teams, die bereits Instruction-Dateien in ihren GitHub-Repos pflegen.
Instructions greifen so, wie sie geschrieben sind, bis jemand sie aendert, und die Quelle jeder Regel ist die Datei, die man selbst geschrieben hat. Im parseISO-Fall kommt die Regel, sobald jemand sie in eine Instruction-Datei schreibt.
Ihre Code-Review-Regeln existieren bereits in Review-Threads, in denen ein Senior-Engineer immer wieder dieselbe Korrektur eingefordert hat. Bugbot, cubic und Greptile mustern gelerntes Feedback ebenfalls aus, archivieren oder unterdruecken es, und Qodo mustert eine Regel danach aus, wie oft Ihr Team ihre Funde umsetzt, wobei jede geminte Regel mit ihren Quell-PRs verlinkt ist.
Im parseISO-Fall erhaelt Qodo am Ende eine auf das Frontend begrenzte Regel, bis zu ihren Quell-PRs nachverfolgbar und ausgemustert, wenn das Team sie nicht mehr anwendet. Behalten Sie AGENTS.md und CLAUDE.md als Ausgangspunkt bei, denn statische Regel-Dateien versagen, wenn niemand sie aktualisiert (Qodo Blog).
Review-Regeln können aus Ihren AGENTS.md- und CLAUDE.md-Dateien stammen, aus Regeln, die Qodo automatisch ermittelt, oder aus Regeln, die Sie selbst schreiben. Qodos Rule Enforcement importiert Regeln aus diesen Dateien, übernimmt selbst verfasste Regeln und ergänzt Regeln, die der Rule Miner im PR-Verlauf findet.
Qodos Rule Miner liest die etwa 1.000 zuletzt gemergten PRs und zählt nur Kommentare, die Entwickler akzeptiert haben und die zu Codeänderungen geführt haben. Beim ersten Durchlauf werden bis zu 10 Regeln pro Repository hinzugefügt, und alle zwei Wochen können bis zu 5 weitere dazukommen.
Regeln schreiben Sie im Qodo-Portal mit Kategorie, Schweregrad und Geltungsbereich, auch ausgehend von einem Punkt aus einem Review. Die Regeln von Teammitgliedern landen zunächst unter Pending Rules bei einem Admin. Stammt ein Finding von einer Regel, verlinkt der PR-Thread auf die Regel, sodass Sie die Regel prüfen oder den Code korrigieren können.
Qodo-Regeln lassen sich staffeln: Standardmäßig global gültig oder auf Git-Organisationen, Repositories und Pfadmuster eingegrenzt. Eine Regel, die aus src/payments/AGENTS.md importiert wurde, gilt beispielsweise nur unterhalb dieses Ordners. Ein Geltungsbereich kann bis zu 25 Organisationen und Repositories umfassen.
Geben Sie dem Agenten die Regeln, bevor er schreibt, und prüfen Sie das Ergebnis anschließend im Review. Qodos Get-Rules-Skill lädt Ihre Qodo Rules in einen Coding-Agenten, und das PR-Review gleicht jede Änderung mit denselben Regeln ab.
Mehrere AI-Code-Review-Tools lesen diese Dateien ein, und Copilot code review liest.github/copilot-instructions.md sowie pfadspezifische Instruction-Dateien. Qodo importiert copilot-instructions.md als Regeln neben AGENTS.md, CLAUDE.md und.cursor/rules/ und prüft jeden PR dagegen, unabhängig davon, welcher Agent den Code geschrieben hat.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
I write about how engineering teams build and keep review standards, most recently on what a base-branch REVIEW.md teaches about agent standards. Your team's real code review rules live in pull request (PR) comments, while CLAUDE.md and AGENTS.md hold only what someone remembered to write down. I ranked eight AI code review tools by how each one turns review history into rules: which signal the tool counts, whether each rule shows its source, and how unused rules retire.
One rulebook lives in CLAUDE.md, AGENTS.md or REVIEW.md. The other lives in the comments senior reviewers leave on PR after PR, and nobody writes it down.
The real rulebook keeps changing in review threads, and new hires and coding agents repeat mistakes the team fixed a year ago.
A tool can find the repeats in review history, and the rules that work are short, come from real fixes and stay under human judgment.
The repeats are findable. One of Stationwise's patterns was to use parseISO from date-fns instead of new Date() for date strings, flagged in 25+ distinct PRs ( Stationwise engineering, February 2026).
Stationwise's final file stayed lean, so the diff still has room in context. The machine found the repeats, and people decided which ones were worth keeping.
Repository norms measurably improve agent output. Agents that drew on a repo's explicit and implicit norms, consulting its Git history when needed, showed a 31.64% to 45.44% relative improvement in norm compliance over a no-guidance baseline, across 121 tasks and three coding models ( RepoNorm, October 2026).
The list that works is short and comes from real fixes. When every accepted review comment became a persistent rule for a coding agent on a 35+ service platform, the list grew to just 18 rules, and the error classes those rules covered didn't come back across 11 recorded sessions, which is early evidence ( arXiv, July 2026).
A reviewer has asked for the same date fix in many PRs (illustrative).
// Flagged in review, again const due = new Date ( invoice. dueDate ); // "2026-11-08" parses as midnight UTC (Coordinated Universal Time) // What the reviewer asks for import { parseISO } from " date-fns "; const due = parseISO ( invoice. dueDate ); Enter fullscreen mode Exit fullscreen mode What Makes a Mined Code Review Rule Worth Trusting Trust in a mined rule comes down to three questions.
The funnel narrows all review comments to comments accepted with a code change, then to owner-weighted, recurring feedback, and finally to one rule scoped to web/**.
The rule card shows three states: active with a Source link to three PRs, deactivated after the team rarely fixed its findings, and locked so the rule stays active.
Mined rules do the most good when the review that applies them sits outside the agent writing the code, because you shouldn't review code with the same tool that wrote it.
I checked signal, source and retirement for every tool that builds custom review rules, using each vendor's own docs as of October 2026.
Qodo gives you rules your team already proved in review, because Qodo's Rule Miner learns only from comments that changed code. Qodo builds Qodo Rules from your rule files, rules you write and your PR history, checks each PR against those rules with Rule enforcement.
Qodo is best for platform and staff engineers who want rules mined from real fixes, traceable to their source PRs and retired by how often the team fixes them.
Qodo counts only accepted comments that changed code, links each rule to every contributing PR, and retires rules by fix rate unless you lock them. In the parseISO case, Rule Miner proposes a rule scoped to web/**, with the source PRs one click away.
CodeRabbit is an AI PR reviewer on GitHub, GitLab, Azure DevOps and Bitbucket. CodeRabbit builds its rules from config, guideline files, preferences stated in chat and learnings CodeRabbit infers during review.
CodeRabbit is best for reviewers who state preferences to the bot in chat.
Chat-sourced learnings apply at once by default, with an optional approval delay of up to 30 days, and inferred learnings apply right away to their source PR. Nothing retires a learning automatically, and the dashboard flags never-used learnings. In the parseISO case, the rule arrives through chat, config or a learning inferred during review.
Greptile is an AI PR reviewer on GitHub, GitLab, Bitbucket and Cursor Origin, priced at $1 per credit. Greptile learns from team comments and whether they get addressed.
Greptile is best for teams who want everyday comments and reactions to shape review.
Greptile counts whether comments were addressed and suppresses ignored comment types. In the parseISO case, the repeated, applied requests are documented inputs, while Greptile's docs don't say whether a learned rule links back to its source PRs (October 2026).
Cursor Bugbot is Cursor's PR reviewer, billed through a Cursor plan. Bugbot learns from repository activity and from an explicit @cursor remember comment in the PR.
Cursor Bugbot is best for engineering groups who add rules with a remember comment in the PR.
Bugbot enables or disables learned rules as it learns more, and per-rule acceptance rates show their value. In the parseISO case, the rule arrives through activity-generated rules or one @cursor remember comment.
cubic is an AI PR reviewer on GitHub, with Team at $40 per developer a month. cubic learns from replies and reactions from anyone, and adds the history of up to five reviewers a lead picks, going back up to four years.
cubic is best for leads who pick which reviewers' history shapes the rules.
cubic links comments to the learning behind them, and a weekly cleanup archives learnings that stop helping. In the parseISO case, the requests become an input through replies, or through history if the reviewer asking for the fix was picked at onboarding.
Kodus is an AI PR reviewer on GitHub, GitLab, Bitbucket, Azure Repos and Forgejo, with a free Community plan and Teams at $10 per developer a month plus model tokens.
Kodus is best for teams who want weekly rule suggestions from recent PRs.
Kodus's docs don't describe how rules retire (October 2026). In the parseISO case, the requests may become a candidate rule if they fall inside the 3-month window, though a human reviewer's request may not count.
Bito is an AI PR reviewer on GitHub, GitLab and Bitbucket, with custom guidelines on the Professional plan. Bito learns from how people react to Bito's own comments.
Bito is best for teams who correct the bot by reacting to its comments.
Bito documents no automatic retirement, so rules are switched off by hand. In the parseISO case, a human reviewer's request becomes a rule once someone writes it into a guideline.
Copilot code review is Copilot's PR reviewer on GitHub.com and in Azure DevOps, on paid Copilot plans where reviews use AI credits. Copilot code review follows the instruction files and skills your team writes.
Copilot code review is best for teams that already keep instruction files in their GitHub repos.
Instructions apply as written until someone edits them, and each rule's source is the file you wrote. In the parseISO case, the rule arrives once someone writes it into an instruction file.
Your code review rules already exist in review threads where a senior engineer asked for the same fix again and again. Bugbot, cubic and Greptile retire, archive or suppress learned feedback too, and Qodo retires a rule by how often your team fixes its findings, with every mined rule linked to its source PRs.
In the parseISO case, Qodo ends up with a frontend-scoped rule, traceable to its source PRs and retired if the team stops applying it. Keep AGENTS.md and CLAUDE.md as the starting point, because static rule files fail when nobody updates them ( Qodo blog ).
Review rules can come from your AGENTS.md and CLAUDE.md files and from rules Qodo mines or you write. Qodo's Rule enforcement imports rules from those files, takes rules you write, and adds rules Rule Miner finds in PR history.
Qodo's Rule Miner reads about the 1,000 most recently merged PRs and counts only comments that developers accepted and that led to code changes. The first run adds up to 10 rules per repository, and runs every two weeks add up to 5 more.
You write rules in the Qodo portal with a category, severity and scope, including from a point raised in review, and members' rules wait in Pending rules for an admin. When a finding comes from a rule, the PR thread links to the rule, so you can check the rule or fix the code.
Qodo rules can be layered: global by default or scoped to Git organizations, repositories and path patterns, and a rule imported from src/payments/AGENTS.md applies only under that folder. One scope can list up to 25 organizations and repositories.
Give the agent the rules before it writes, then check the result in review. Qodo's Get Rules skill loads your Qodo Rules into a coding agent, and the PR review checks every change against the same rules.
Several AI code review tools read them, and Copilot code review reads.github/copilot-instructions.md and path-specific instruction files. Qodo imports copilot-instructions.md as rules next to AGENTS.md, CLAUDE.md and.cursor/rules/, and checks every PR against them whichever agent wrote the code.