KI-Code-Review, wenn Coding-Agenten einen wachsenden Teil Ihres Codes schreiben

Zwei Bedeutungen von KI-Code-Review

Hinter dem Begriff KI-Code-Review stecken zwei Aufgaben. Bei der einen prüft ein Modell einen Pull Request und kommentiert seine Befunde, wie es CodeRabbit, Qodo, GitHub Copilot Code Review und Bugbot tun. Bei der anderen prüfen Menschen Code, den ein Coding-Agent geschrieben hat. Teams, die Coding-Agenten einführen, brauchen beides.

Der Druck entsteht durch die Menge. Ein Engineer, der morgens drei Aufgaben an Agenten übergibt, kann mittags drei Pull Requests vor sich haben, und der Reviewer ist womöglich der erste Mensch, der sie genau liest. Automatisiertes Review kann einen großen Teil der zeilenweisen Prüfung übernehmen, aber es kann weder entscheiden, ob eine Änderung sinnvoll ist, noch nach dem Merge für sie geradestehen. In den Setups, die wir aufbauen, ist der KI-Reviewer der erste Durchgang, und eine namentlich benannte Person trifft die Entscheidung.

Was automatisiertes Code-Review mit KI gut kann und was es übersieht

Aktuelle KI-Reviewer lesen den Diff zusammen mit dem umgebenden Code, einige analysieren vorher das ganze Repository. Gut sind sie bei Problemen, die im Code sichtbar sind: unbehandelte Fehler und Null-Fälle, Off-by-one-Logik, nicht freigegebene Ressourcen, unsichere Verarbeitung von Eingaben, Secrets im Quellcode, Tests, die nichts prüfen, und Verstöße gegen Ihre schriftlichen Regeln. Dem vierzigsten Pull Request des Tages widmen sie dieselbe Aufmerksamkeit wie dem ersten.

Was ihnen entgeht, ist vor allem Wissen, das nicht im Repository steht. Für diese Punkte braucht es weiterhin jemanden, der die Aufgabe und die Systeme rund um den Code kennt.

• Absicht: ob die Änderung tut, was die Aufgabe verlangt hat
• Architektur: ob die Änderung in dieses Modul gehört oder etwas doppelt baut, das die Codebasis schon kann
• Fachliche Korrektheit: Verhalten, das im Code stimmig ist, für Nutzer, Preise, Berechtigungen oder Regulierung aber falsch
• Auswirkungen auf andere Services: API-Verträge, Nachrichtenformate, gemeinsame Konfiguration und Migrationen auf Live-Daten
• Betrieb: Reihenfolge des Rollouts, Feature Flags, Monitoring und Rollback

Auch die Abdeckung hat Lücken. Laut GitHub-Dokumentation prüft Copilot Code Review keine Dateien des Abhängigkeitsmanagements wie package.json und Gemfile.lock, ebenso wenig Log- und SVG-Dateien. Eine neue Abhängigkeit braucht also eine weitere Prüfung. Prüfen Sie auch die Ausschlüsse Ihres eigenen Tools.

Änderungen von Agenten wiederholen außerdem Muster, die Ihre Regeln benennen sollten. Typisch sind Tests, die so lange angepasst werden, bis sie grün sind, breite Exception-Behandlung, doppelte Hilfsfunktionen und Änderungen außerhalb der Aufgabe.

Einen KI-Reviewer einrichten

Die meisten dieser Tools werden als App mit Ihrem Git-Host verbunden oder laufen in der CI. Die eigentliche Arbeit liegt in der Entscheidung, was der Reviewer prüft und was geschieht, wenn er etwas findet.

1. 1

   Umfang festlegen

   Beginnen Sie mit ein oder zwei Repositories, in denen regelmäßig Pull Requests von Agenten eingehen, und nehmen Sie generierten Code, Lockfiles und eingebundene Fremdbibliotheken aus. Bei den meisten Tools wählen Sie, wann Reviews laufen, etwa beim Öffnen, bei jedem Push oder auf Anfrage, wobei ein Review bei jedem Push meist am teuersten ist.

2. 2

   Kurze Review-Regeln schreiben

   Geben Sie dem Reviewer die Regeln, die ein erfahrener Engineer in diesem Repository anwenden würde, angefangen damit, was hier als schwerwiegend gilt und was er ignorieren soll. Formatierung, Linting und Typfehler bleiben Sache der CI. Lange Regeldateien verwässern die wichtigen Regeln, ergänzen Sie eine Regel deshalb erst, wenn ein tatsächlich übersehener Fehler sie rechtfertigt.

3. 3

   Festlegen, welche Befunde blockieren

   Mehrere Reviewer arbeiten standardmäßig nur beratend, und das ist ein vernünftiger Anfang. Soll eine Art von Befund einen Merge stoppen, etwa eine fehlende Autorisierungsprüfung, setzen Sie das über einen erforderlichen Check durch, den Sie selbst kontrollieren. Den Status des Reviewers als erforderlich zu markieren reicht nicht, denn GitHub wertet ein neutrales Ergebnis als bestanden, und sowohl der Review-Check von Claude Code als auch Bugbot in der Standardeinstellung melden Befunde als neutral.

4. 4

   Rauschen und False Positives begrenzen

   Begrenzen Sie kleinere Befunde pro Review und unterdrücken Sie neue beim erneuten Review, damit ein einzeiliger Fix keine weitere Runde auslöst. Markieren Sie im ersten Monat jede Woche eine Stichprobe von Befunden als nützlich, falsch oder Rauschen, passen Sie dann die Regeln an und bewahren Sie die Markierungen als Baseline auf. Regeln, die Tools aus den Antworten Ihres Teams lernen, brauchen einen Owner, der sie ausdünnt.

# Review rules: payments-service

## Treat as blocking
- Endpoint added or changed without an authorisation check
- Query not scoped to the caller's tenant
- Migration that cannot be rolled back
- Test changed to match new behaviour without a stated reason

## Do not report
- Formatting, lint and type errors (CI enforces them)
- Generated code under src/gen/ and lockfiles
- More than five minor findings per review

Copilot Code Review liest seine Anweisungen aus dem Head-Branch des Pull Requests, sodass die Änderung eines Agenten die Regeln für ihr eigenes Review bearbeiten kann. Bugbot dagegen liest seine Konfigurationsdatei aus dem Base-Branch. Stellen Sie Dateien mit Review-Regeln unter CODEOWNERS und behandeln Sie Änderungen daran wie Änderungen an der CI.

Review innerhalb von Agenten-Workflows

Am günstigsten ist ein Befund, bevor es einen Pull Request gibt. Ein Agenten-Workflow kann einen Review-Schritt enthalten, in dem ein zweiter Agent mit frischem Kontext oder ein anderes Modell den Diff gegen die Aufgabe prüft, frei von den Annahmen, die der schreibende Agent mitbringt. Der lokale Befehl /code-review von Claude Code etwa läuft als Subagent im Hintergrund mit eigenem Kontextfenster.

Das Cursor-Plugin pstack enthält den Skill interrogate, der denselben Diff mit denselben Bewertungskriterien an je einen schreibgeschützten Reviewer pro konfiguriertem Modell schickt und die Befunde sortiert, ohne Code zu ändern, wobei Übereinstimmung zwischen Modellen als stärkstes Signal gilt. Sein Shipping-Playbook mergt einen Pull Request nur mit dem Urteil eines Agenten, der den Code nicht geschrieben hat, und hält fest, dass grüne CI und ein zustimmendes Bot-Review kein Urteil sind.

Runmill, ein Open-Source-Projekt unseres Gründers, wendet dieselbe Regel in einer Pipeline an. Genau der Commit, der als Kandidat ansteht, muss die erforderlichen Checks und ein Review in frischem Kontext bestehen, bevor ein Pull Request auf GitHub geöffnet wird, und über Pushes, Pull Requests und Merges entscheidet deterministischer Code, nie der Agent. Runmill ist eine Developer Preview, der automatische Merge ist experimentell.

Nichts davon ersetzt das menschliche Review am Ende. Skills, Playbooks und Review-Prompts geben einem Agenten Anweisungen, können aber nichts durchsetzen. Das leisten Branch Protection, erforderliche Checks und die Berechtigungen des Agenten.

Leitfaden zu pstack-Workflows in CursorDas Cursor-Plugin pstack einführenRunmill-Quellcode auf GitHub

Abnahmekriterien für Pull Requests von Agenten

Reviewer arbeiten schneller, wenn sie wissen, was ein Pull Request eines Agenten enthalten muss. Halten Sie den Standard schriftlich fest, schicken Sie Pull Requests, die ihn verfehlen, zurück, bevor jemand den Code liest, und nehmen Sie denselben Standard in die Anweisungen Ihrer Agenten auf.

• Eine Aufgabe pro Pull Request, klein genug für ein Review in einem Durchgang, mechanische Änderungen getrennt von Verhaltensänderungen
• Ein Link auf das Issue, die Spezifikation oder den Prompt, mit dem der Agent gearbeitet hat
• Tests für neues Verhalten und eine Begründung für jeden geänderten oder gelöschten Test
• Eine Beschreibung, was sich geändert hat, was ausgelassen wurde, wo der Agent unsicher war und wie geprüft wurde
• Keine fachfremden Dateien und keine neuen Abhängigkeiten, sofern die Aufgabe sie nicht verlangt
• Agent und Modell, die die Änderung erzeugt haben

Legen Sie fest, wovon der Reviewer ausgehen darf: dass die CI genau den geprüften Commit gebaut und getestet hat und dass KI-Befunde behoben oder mit Begründung verworfen wurden. Nicht ausgehen sollte er davon, dass die Zusammenfassung des Agenten stimmt, dass die Tests die Änderung abdecken oder dass der KI-Reviewer Absicht und Auswirkungen auf andere Services geprüft hat.

Leitfaden zu Spec-Driven Development

Für jeden Merge bleibt eine Person verantwortlich

Ein Review-Kommentar eines Modells ist ein Hinweis. Eine Freigabe ist eine Entscheidung, für die jemand geradesteht, und bei Code von Agenten muss es diese Person geben. Standardmäßig zählen die Reviews von Copilot nicht zu den erforderlichen Freigaben, und Code Review von Claude Code gibt Pull Requests weder frei, noch blockiert es sie. OpenAI hält in der Dokumentation zu Codex fest, dass Review-Regeln weder Tests noch Branch Protection oder erforderliche Freigaben ersetzen.

Einige Tools können inzwischen freigeben. Sind Copilot Approvals, derzeit in der Public Preview, in den Einstellungen von Repository, Organisation und Enterprise aktiviert, kann Copilot ein zustimmendes Review abgeben, das die Regel für erforderliche Freigaben erfüllt. Der optionale Request-Changes-Workflow von CodeRabbit gibt frei, sobald seine eigenen Bedingungen erfüllt sind. Entscheiden Sie ausdrücklich, ob eine automatisierte Freigabe für Ihre Merge-Regeln zählen darf, und wenn ja, nur auf risikoarmen Pfaden.

Behandeln Sie den Engineer, der eine Aufgabe delegiert hat, als Autor der Änderung, und lassen Sie jemand anderen freigeben. GitHub hat das in den eigenen Agenten eingebaut: Wer Copilot Cloud Agent beauftragt, einen Pull Request zu erstellen, kann ihn nicht freigeben. Prüfen Sie bei anderen Agenten, ob die Person, die den Lauf gestartet hat, das Ergebnis freigeben kann, und schließen Sie diese Lücke gegebenenfalls mit einer Teamregel oder einem erforderlichen Check.

Branch-Protection-Einstellungen, die das durchsetzen

• Vor dem Merge einen Pull Request mit mindestens einem zustimmenden Review verlangen
• Review durch Code Owners verlangen und in CODEOWNERS Personen oder Teams für Agenten-Konfiguration und Review-Regeln eintragen
• Veraltete Freigaben verwerfen, wenn neue Commits den Diff ändern
• Freigabe des letzten Pushs durch jemand anderen als die Person verlangen, die ihn gepusht hat
• Vor dem Merge bestandene Status-Checks für Build und Tests verlangen

Leitfaden zur Sicherheit von Coding-Agenten

Review-Aufwand messen, ohne Personen zu bewerten

Kommen durch Agenten schneller Pull Requests hinzu, als die Review-Kapazität wächst, wird entweder die Warteschlange länger oder das Review oberflächlicher, und welches von beiden passiert, zeigen nur Daten. Messen Sie das Review-System nach Team, Repository, Aufgabentyp und Tool, verglichen mit einer Baseline aus der Zeit vor den Agenten oder vor dem neuen Reviewer.

• Zeit bis zum ersten menschlichen Review, ab dem Moment, in dem ein Pull Request bereit ist
• Menschliche Review-Zeit pro Änderung, im Verhältnis zur Größe des Diffs
• Kommentare und Review-Runden pro Änderung
• Anteil umgesetzter KI-Befunde, also Fälle, in denen der markierte Code geändert oder der Thread mit einem Fix geschlossen wurde
• Nacharbeit und Reverts gemergter Änderungen innerhalb eines vereinbarten Zeitraums
• Durchgerutschte Fehler, die auf gemergte Änderungen zurückgehen, getrennt nach Arbeit von Agenten und von Menschen

Der Anteil umgesetzter Befunde ist das direkteste Maß für Rauschen. Berechnen Sie ihn aus der Historie der Pull Requests, denn Reaktionen auf Review-Kommentare hängen davon ab, dass jemand daran denkt, sie zu klicken. Kennzeichnen Sie Pull Requests von Agenten einheitlich, damit sich jede Kennzahl danach aufteilen lässt, wer oder was die Änderung geschrieben hat.

Halten Sie diese Zahlen aus der Leistungsbeurteilung Einzelner heraus. Sobald eine Kennzahl Engineers bewertet, passt sich das Verhalten an sie an: Änderungen werden aufgeteilt, um schnell zu wirken, und Freigaben kommen vor dem Lesen. Berichten Sie nach Team, Aufgabentyp und Tool.

Die wichtigsten KI-Code-Review-Tools

Die folgenden Beschreibungen stützen sich auf die Dokumentation der Anbieter mit Stand Oktober 2026 und stehen in keiner Rangfolge. Prüfen Sie vor einer Entscheidung die aktuelle Dokumentation.

Eigenständige Review-Produkte

CodeRabbit prüft Pull Requests und wird über eine Datei .coderabbit.yaml oder seine Weboberfläche konfiguriert. Standardmäßig nutzt es verbreitete Anweisungsdateien für Agenten wie AGENTS.md und CLAUDE.md als Review-Kriterien, und ein optionaler Request-Changes-Workflow kann Änderungen anfordern und freigeben, sobald seine Bedingungen erfüllt sind.

Qodo führt in Pull Requests ein Review mit mehreren Agenten durch, bei dem ein Judge-Agent die Befunde zusammenführt, Duplikate entfernt und unsichere Befunde aussortiert. Es leitet Review-Standards aus Ihrer Codebasis, der Historie Ihrer Pull Requests und Ihren Anforderungen ab, und sein Rule Miner macht aus wiederkehrenden Mustern früherer Pull Requests durchgesetzte Regeln.

Review in Plattformen für Coding-Agenten

GitHub Copilot Code Review prüft Pull Requests auf GitHub auf Anfrage oder automatisch und kann dafür den Kontext des gesamten Repositorys analysieren. Es liest Repository-Anweisungen, pfadspezifische Anweisungsdateien und AGENTS.md. Die Freigabefunktion befindet sich in der Public Preview.

Bugbot ist der Pull-Request-Reviewer von Cursor für GitHub, GitLab, Bitbucket und Azure DevOps. Seine Regeln stehen in Dateien unter .cursor/BUGBOT.md, während die allgemeinen Projektregeln von Cursor für ihn nicht gelten. Ein optionaler Autofix startet einen Cloud Agent von Cursor, der das Gefundene behebt.

Claude Code bietet für GitHub ein verwaltetes Code Review an, als Research Preview für Team- und Enterprise-Abonnements. Mehrere Agenten prüfen den Diff parallel, ein Verifikationsschritt filtert False Positives heraus, und eine Datei REVIEW.md steuert, was gemeldet wird. Teams können Claude auch in eigenen Pipelines mit GitHub Actions oder GitLab CI/CD betreiben.

Codex Code Review von OpenAI veröffentlicht ein reguläres GitHub-Review, wenn jemand @codex review kommentiert, oder nach Aktivierung automatisch. Auf GitHub meldet es nur Befunde der Stufen P0 und P1 und wendet Review-Regeln aus AGENTS.md-Dateien auf die Dateien an, für die sie gelten.

Vergleichen Sie bei der Auswahl, wohin Code zu welchen Bedingungen übertragen wird, welche Anweisungsdateien ein Tool liest und wie seine Freigaben und Checks zu Ihren Merge-Regeln passen. Testen Sie die Kandidaten dann an Ihren eigenen gemergten Änderungen.

Wie Cloudsail unterstützt

Wir bewerten Review-Setups an Ihren eigenen gemergten Änderungen. Dafür lassen wir frühere Pull Requests, auch solche, die später einen Fix oder Revert brauchten, durch die Reviewer und Konfigurationen laufen, die Sie in Betracht ziehen, und vergleichen die Befunde mit dem, was tatsächlich schiefging. Sie sehen, welche Fehler jedes Setup gefunden hätte und wie viel Rauschen und Kosten es pro geprüfter Änderung verursacht.

Die Review-Regeln schreiben wir mit Ihren Engineers, zusammen mit den Repository-Anweisungen, CODEOWNERS-Einträgen und der Branch Protection, von denen sie abhängen, jeweils mit einem Owner. Außerdem richten wir die Messung des Review-Aufwands auf Ebene von Team und Tool ein.

Trainings für Reviewer finden als Team-Sessions in Ihren eigenen Repositories statt, remote oder vor Ort in Deutschland und Polen, auf Englisch, Deutsch oder Polnisch. Im Mittelpunkt steht das Lesen von Pull Requests von Agenten: die Absicht gegen die Aufgabe prüfen, wiederkehrende Muster erkennen und entscheiden, wann eine Änderung zurückgeht. Öffentliche Kurse oder Zertifikate bieten wir nicht an.

Evaluierungen auf Ihren RepositoriesHarness EngineeringGitHub Copilot Implementierung