Unabhängiger Erfahrungsbericht zu CodeRabbit AI: Lohnt es sich für dein Team?

Seit einigen Wochen setzen wir bei einem Kunden CodeRabbit AI zur Unterstützung beim Code Review ein. Mein Zwischenfazit nach ausgiebigen Tests in zig Pull Requests: Der Nutzen des Tools hängt davon ab, wie sauber man arbeitet, und die Alternative zu CodeRabbit AI ist, wie so oft in diesen Tagen, der eigene Workflow.

Auf dem Papier sieht das Angebot von CodeRabbit sehr verlockend aus. Genau deshalb habe ich es auch bislang in meinem Workshop zur Einführung von KI in Entwicklungsteams empfohlen: Zahle ca. 20 € pro Entwickler pro Monat und erhalte automatisiert eine großzügige Menge an Pull Request Reviews in GitLab, GitHub und Co. Stell ein, worauf sich die KI konzentrieren soll und definiere eigene Regeln. Lass ihn durch Feedback lernen und gib ihm Wissen über dein Produkt mit, damit er die im Code abgebildete Logik besser beurteilen kann. Auch die Benchmarks sehen durchaus gut aus: Im Bericht eines Konkurrenztools landet CodeRabbit auf Platz zwei, direkt hinter der Konkurrenz, mit einer Fehlererkennungsrate (Bug Detection Rate), die nur wenige Prozentpunkte hinter Platz eins liegt. Meine konkrete Empfehlung war daher: „Der Nutzen des Tools hängt sicher von vielen Faktoren ab, aber ausprobieren könnt ihr’s auf jeden Fall mal.“

Jetzt kann ich sagen: Ich habe es selbst ausgiebig ausprobiert, und durch meine langfristige Betreuung eines Kunden habe ich die Experimente beobachten und gestalten können. Hier sind die Ergebnisse:

Das Gute vorweg

1. Die Reviews sind schnell

Sobald man einen Pull Request öffnet, erhält man einen Kommentar vom CodeRabbit-Bot, der einen darüber informiert, dass er den Code jetzt prüft. Einige Minuten später (je nach Größe der Änderungen) ist der fertige Review da. Die Geschwindigkeit ermöglicht es dem Autor, noch ein paar Minuten im Kontext des Pull Requests zu bleiben, statt sofort mit dem nächsten Thema zu starten. Da wir in der Softwareentwicklung generell versuchen, Kontextwechsel zu minimieren, ist das gut. Der Zeitverlust ist gering.

2. Die Integration in die Plattform ist ordentlich

CodeRabbit AI kann kommentieren, Kommentar-Threads „resolven“, separate Issues anlegen und natürlich auf Erwähnungen reagieren. Der Hase erkennt sogar, wenn aus einem seiner Kommentare eine Debatte zwischen zwei Engineers entsteht, und lässt die Beteiligten dann wissen, dass er sich „in den Bau verkriecht“, während die Menschen miteinander sprechen. Das ist witzig und bekommt deswegen einen Pluspunkt. (Unser Arbeitsalltag ist generell trockener, als er sein müsste.)

3. Die KI findet echte Fehler

Ein Engineer im Team sagte: „Es ist zwar kleinlich, aber es macht generell gute Anmerkungen und findet Edge Cases, die ich übersehen habe.“ (Die Kleinlichkeit ist eine Einstellung; dazu später mehr.) Den Eindruck kann ich bestätigen. In meinen Tests fand es am zuverlässigsten unsauberes State Handling in Frontend-Code, wie einen Ladezustand, der in einem Fehlerfall nicht sauber zurückgesetzt wurde. Größere Bugs konnte es bislang nicht finden.

In meiner Wahrnehmung hängt die Fehlererkennungsrate vor allem von zwei Faktoren ab:

1. Das Wissen über das Produkt und
2. die Gründlichkeit des Engineers in den Arbeitsschritten vor der Erstellung des Pull Requests.

Auch dazu später mehr.

An dieser Stelle möchte ich aber sagen, dass ich davon überzeugt bin, dass es auch grobe Schnitzer findet, wenn sie es in den Pull Request schaffen.

4. Ein paar Quality-of-Life-Features haben meinen Arbeitsalltag verbessert

Ein Beispiel ist die Möglichkeit, ein Finding aus dem Code Review direkt als Prompt für einen KI-Agenten zu kopieren. Der Prompt beinhaltet grundsätzlich den Hinweis, das Finding noch einmal anhand des Codes zu prüfen, statt den Fix blind umzusetzen, was die Bearbeitung der Findings mit dem lokalen Agenten reibungslos und recht unbedenklich macht.

Hier fangen die Probleme an

1. Das Rauschen ist manchmal schwer auszuhalten

CodeRabbit AI hat zwei Modi: Entspannt und kleinlich. Aus unterschiedlichen Gründen haben wir in der gesamten Testphase lediglich den kleinlichen Modus getestet und der produziert in einem großen Pull Request auch gerne mal 20 Kommentare oder mehr. Das gilt nicht nur dann, wenn es wirklich viele Probleme in dem neuen Code gibt, sondern auch dann, wenn sauber gearbeitet wurde und der Code vielleicht schon lokal durch einen Review-Agent gelaufen ist.

In dem Fall halluziniert die KI dann plötzlich und erfindet Regeln, die es im Code so nicht gibt. Zum Beispiel werden Verstöße gegen Linter angekreidet, die im Projekt nicht einmal definiert sind oder — und das ist schlimmer — der Bot findet kritische Probleme in der Business-Logik, die er aufgrund fehlenden Kontexts schlichtweg nicht kennen und damit auch nicht beurteilen kann. Der Grund für viele Kommentare in sauberen PRs liegt vermutlich in den Anweisungen, die die KI von CodeRabbit erhält (der System Prompt des Tools); wie würde es schließlich aussehen, wenn ein kleinlicher Reviewer in einem größeren PR nichts findet? (Der gleiche Mechanismus greift übrigens oft auch beim Menschen.)

2. Die Quality of Life ist begrenzt

Was ich oben als Pluspunkt vermerkt habe, hat leider seine Grenzen: Stört sich die KI an etwas, und dieses „Etwas“ findet sich fünfmal im Code, bekommt man fünf unzusammenhängende Kommentare. In dem Fall gibt es auch keinen Prompt, den man einfach kopieren kann, der diese fünf Fälle zusammenfasst. CodeRabbit AI erwähnt, dass sein Finding auch an anderen Stellen in der Datei auftritt, nicht jedoch, wenn das gleiche Finding auch in einer anderen Datei gefunden wurde. Dafür gibt es dann in besagter Datei einen separaten Kommentar.

Ein anderes Beispiel: Manchmal ist ein Kommentar durchaus gültig, soll aber nicht mehr im selben Pull Request behoben werden. In dem Fall teilt man das als Autor natürlich mit; nicht zuletzt auch, um transparent gegenüber menschlichen Reviewern und Teammitgliedern zu sein. CodeRabbit bietet dann netterweise an, für das Problem ein separates Issue anzulegen; auch dann, wenn die Plattform, auf der es läuft, vom Team überhaupt nicht für das Issue-Tracking verwendet wird. Eine Einstellung, um dieses Verhalten zu unterdrücken, gibt es meines Wissens nicht.

3. Das Learnings-Feature hat erwartbare Probleme

Vor einigen Monaten nannte ich das Memory-Feature von Claude Code eine Last. Wenn die KI entscheidet, was sie lernen soll und wieso, entstehen Fehler. Wie zwischen zwei Menschen auch gehen in der Kommunikation zwischen Mensch und Maschine Informationen verloren. Wenn ich dem Menschen A erkläre, kommt A' oder, schlimmer noch, B bei ihm an. So auch bei KI, und eben auch bei CodeRabbit: Das KI-Modell hinter dem Bot ist logischerweise kein GPT 5.6 Sol oder Fable 5, und so speichert sich CodeRabbit Learnings ab, die zu stark verallgemeinert oder schlichtweg falsch sind. Diese im Tool zu verwalten ist manueller Aufwand und kann bei größeren Teams den Effizienzgewinn durch den Einsatz des Tools vernichten.

Jetzt kann man argumentieren: „Dann schalte das Learnings-Feature doch aus.“ Das kann man machen, nur dann hat man auch keine gute Möglichkeit mehr, die wenigen Learnings, die wichtig sind, sauber abzuspeichern. In unserem Fall wanderten kleinere Regeln und Guidelines in die AGENTS.md des jeweiligen Repositories. Diese Datei soll nach Möglichkeit schlank gehalten werden. Wenn meine Coding Agents die Information nicht benötigen, die Review-KI jedoch schon, weil sie sonst keine guten Ergebnisse erzielt, geht das am Ziel vorbei.

4. Die UI von CodeRabbit ist zu kaputt

Bleiben wir beim Thema Learnings und Konfiguration: Zusätzlich zu den gerade genannten Problemen und parallel zum Learnings-Feature hat CodeRabbit ebenfalls ein „Coding-Guidelines“-Feature: Auch hier speichert sich die KI Regeln ab, die beispielsweise aus der AGENTS.md gezogen und separat im Tool abgespeichert werden. Das ist ein Design-Fehler, denn das Tool könnte diese Informationen ebenso gut direkt aus dem Repository lesen. Das hätte zwei wesentliche Vorteile:

1. Als Maintainer könnte ich die Anweisungen an einer Stelle pflegen und müsste Anpassungen daran nicht zusätzlich zum Repository auch in einem externen Tool vornehmen.
2. Die Basis für den Review wäre exakt die gleiche wie für die Agenten, die den Code programmiert haben.

Als Nutzer soll ich diese Regeln auch in CodeRabbit bearbeiten, erweitern und löschen können. Zum Zeitpunkt des Schreibens dieses Berichts kann ich das nur leider nicht, da die UI dafür seit Wochen kaputt ist. Ich kann nichts bearbeiten oder löschen, und das Tool aktualisiert die Regeln auch nicht anhand von Änderungen in der AGENTS.md des Repositories. Der Effekt: CodeRabbit referenziert in seinen Reviews munter die veralteten Regeln und bevorzugt diese gegenüber neueren Regeln in der aktuellen AGENTS.md, die den alten Regeln direkt widersprechen. Es ist ein Trauerspiel und zerstört jeden Produktivitätsgewinn.

An diesem Punkt meines Erfahrungsberichts kommt natürlich die Frage auf: Lohnt sich CodeRabbit AI denn überhaupt? Im Falle meines Kunden und in den allermeisten anderen Fällen, die mir bekannt sind, lautet die Antwort: Nein, nicht wirklich. Und der Hauptgrund folgt jetzt.

5. Das Modell ist schlicht und ergreifend nicht gut genug

Die Nutzungslimits von CodeRabbit sind hoch und der Preis erstaunlich niedrig: Im Monat zahlt man in der einfachsten Variante pro Entwickler in etwa so viel wie für einen einzigen „großen“ Claude Code Review, den Anthropic als separaten Flow vor einigen Monaten veröffentlicht hat und mit 15–25 $ pro Review bepreist (offizieller Näherungswert, Abrechnung erfolgt anhand von API-Preisen). Genau das macht das Ausprobieren so reizvoll: Ist das Tool gut genug, ist die Investition trivial. Als jemand, der selbst an einer Software arbeitet, die LLMs einbindet, weiß ich: Diesen günstigen Preis kannst du nur dann anbieten, wenn dein Produkt auf Kosten optimiert ist und nicht auf Qualität. Lange Denkprozesse und große Kontextfenster sind eben teuer.

Das Prüfen von Pull Requests ist eine der kognitiv aufwändigsten Aufgaben unseres Berufs und erfordert viel Nachdenken, das Durchspielen verschiedener Szenarien und insbesondere auch das Lesen des Codes über die Grenzen der veränderten Stellen hinaus: Seiteneffekte können an Stellen auftreten, die in der Diff so nicht sichtbar sind, was ein erhöhtes Maß an Exploration beim Reviewer erfordert; unabhängig davon, ob es sich dabei um einen Menschen oder eine KI handelt. Nach vielen Wochen intensiver Tests in unterschiedlichen Technologien kann ich mit Sicherheit sagen: CodeRabbit AI kann das schlichtweg nicht leisten; zumindest nicht in einem Maße, das dem Qualitätsanspruch des Kunden und vieler Engineers, die ich kenne, gerecht werden würde.

Eine bessere Alternative

Eingangs sagte ich: Eine bessere Alternative zu CodeRabbit ist der eigene Workflow. Konkret nutze ich einen schlanken, selbst geschriebenen Review-Skill, den ich über die Monate weiter verfeinert habe und in den auch ein Quality-of-Life-Feature eingeflossen ist, das ich bei CodeRabbit zum ersten Mal gesehen habe. Wie du sehen wirst, ist der Skill nicht wirklich ausgeklügelt oder komplex; er stützt sich schlichtweg auf die guten Modelle, die ihn nutzen, und gibt mir den Output, den ich brauche. Das ist alles.

Der Review-Skill ist der Hauptgrund dafür, dass CodeRabbit im Fall meiner eigenen Pull Requests kaum etwas finden konnte: Zu dem Zeitpunkt, zu dem CodeRabbit meinen Code sehen konnte, hatte eine schlauere KI den Code bereits gründlich reviewt und ich hatte eine erste Runde Fixes bereits eingespielt. Zusätzlich bin ich selbst bereits über die Diff gegangen und habe die Änderungen lokal getestet.

Eine KI wie CodeRabbit kann an dem Punkt kaum noch Mehrwert liefern. Muss sie aber auch nicht, denn der Review-Skill ist simpel und kann auch autonom laufen.

Meine alte Empfehlung war, CodeRabbit (oder ein vergleichbares Tool) mal auszuprobieren. Meine neue Empfehlung ist: Verwende einen Review-Skill, der zu deinem Arbeitsablauf passt, und nutze dafür dein bestehendes KI-Abo, z. B. von Claude Code oder Codex. Wenn du fancy werden willst, baust du dir daraus eine eigene CI-Action für GitHub oder GitLab; oder du lässt sie einfach in einem neuen Kontextfenster bei dir lokal laufen und holst dir in der Zeit eine neue Tasse Kaffee.

Ab da gilt wie immer: Ausprobieren, iterieren, verfeinern, bis es passt.

Wie sieht mein Review Skill aus?

Hier der Skill zum Rauskopieren und Ausprobieren:

---
name: basic-review
description: Review the changes of this branch.
---

Review the changes of this branch. Assume `main` as the base branch unless specified otherwise.

## Steps

1. Explore the changes and surrounding codebase.
2. Explain the feature or bugfix to me in 3-4 sentences.
3. Review the changes:
    **Look for:**
    a. Programming bugs
    b. Completeness issues
    c. Code smells
    d. Bad practices
    e. Newly added generic utility functions that must **either** be moved to a shared location **or** replaced with an existing utility function in the codebase
4. Categorize your findings into the following severities:
    - **Blocker (B)**: Must be fixed before merge
    - **Major (M)**: Should be fixed before merge
    - **Minor (m)**: Can be fixed before merge or in a follow-up
    - **Trivial (t)**: Nitpicks
5. Return findings sorted by severity (blockers first), each with a referenceable label numbered within its severity (e.g. `B1`, `B2`, `M1`, `M2`, `M3`, `m1`, `m2`, `t1`).

## Output

Complete the full review before composing the output. Do not change, remove, or limit findings to fit the output format.

Start the response with the feature or bugfix explanation from step 2. Then output the findings in the two forms below.

### Individual findings

Put each finding in its own fenced `markdown` block:

```markdown
Before making changes, you MUST verify this finding against the current state of the code.

## M1: <finding title>

**Severity:** Major (M)

<finding text>

**References:**

- `<file and line reference>`

You MUST ignore work-in-progress changes on this branch that are unrelated to this finding. Other agents are likely fixing other findings on the same branch.
```

Use the finding's real label and full severity name. Keep the findings sorted as required by step 5.

### All findings

Below the individual finding blocks, put all findings in one fenced `markdown` block:

```markdown
Before making changes, you MUST verify each finding against the current state of the code.

## B1: <finding title>

**Severity:** Blocker (B)

<finding text>

**References:**

- `<file and line reference>`

## M1: <finding title>

**Severity:** Major (M)

<finding text>

**References:**

- `<file and line reference>`
```

For every finding, copy the label, title, severity line, finding text, and code references from its individual block. They must be exactly the same in both places. Do not rewrite or shorten them.

Zwei wichtige Anmerkungen:

1. Die Kategorisierung der Findings folgt keinem offiziellen Standard; hier nutze ich einfach das, was man mir in meinem ersten Job beigebracht hat. Die Kategorien sind nicht starr definiert, aber gut genug. Sie funktionieren.
2. Der Output des Review-Agents liefert jedes Finding als einzelnen Markdown-Block sowie alle Findings noch einmal gebündelt als separaten Markdown-Block. Damit kann ich entscheiden, ob ich einzelne Probleme beheben möchte, oder alle Probleme in einem Schritt, z. B. wenn es wenige sind oder alle gültig.

Wie verwende ich einen solchen Skill effektiv?

1. Unterschiedliche Modelle führen die Anweisungen unterschiedlich aus. Opus 5 und Fable 5 sind wesentlich gründlicher als Codex 5.6 Sol xhigh. Seit der Veröffentlichung von Opus 5 ist mein Review-Agent fast ausschließlich Opus 5 und ich bin von dem Output wirklich begeistert. Wer nur die gröbsten Schnitzer finden will, kann sicher auch auf Codex 5.6 Sol xhigh setzen. Ein kleineres Modell empfehle ich für diesen wichtigen Schritt in unserer täglichen Arbeit ausdrücklich nicht.
2. Möchte ich nur einzelne Findings beheben, kopiere ich jedes davon in eine neue Session. Das hat den Vorteil, dass ein weiteres schlaues Modell das Finding erneut prüft, bevor es behoben wird. Behebt man die Findings in der gleichen Session, in der auch der Review stattgefunden hat, unterliegt der Fix einem Confirmation Bias. Das möchte ich verhindern. Ganz nett: Der Prompt für jedes Finding beinhaltet ebenfalls einen Hinweis darauf, dass parallel stattfindende Arbeit ignoriert werden soll; das ermöglicht es, mehrere Sessions mit einzelnen Fixes problemlos parallel laufen zu lassen.
3. Möchte ich alle Findings beheben, nehme ich den gebündelten Prompt am Ende des Outputs und gebe auch diesen in eine neue Session. Auch hier gilt wieder: Jedes Finding wird erneut durch den Agenten geprüft, bevor er es behebt.

Ein Einwand, den ich aus dem Weg räumen möchte: Es ist meiner Erfahrung nach nicht mehr wahr, dass die Review-KI eine andere sein muss als die KI, die den Code erzeugt hat: Mein Opus 5 findet auch im Code, den Opus 5 generiert hat, manchmal Blocker. Die Modelle haben sicherlich Eigenschaften, die sie selbst nicht kritisch hinterfragen können, aber je schlauer sie werden, umso weniger spielt das eine Rolle. Die KI hat kein Wissen darüber, dass das gleiche Modell den Code erzeugt hat. Ebenso kennt sie nicht den Prompt, mit dem er erzeugt wurde. Claude Code könnte in seinen Session-Logs nach der Session suchen, die den Code erzeugt hat, hat aber schlichtweg keinen guten Grund dazu.

In meinen Augen ist diese Sicht also „extern genug“, sodass man im August 2026 nicht mit zwei verschiedenen KI-Agenten jonglieren muss, um effektive lokale Code Reviews zu haben.

Schlusswort

CodeRabbit AI (und ähnliche Code-Review-Tools) sind verlockend. Auch nach meinem ausgiebigen Test würde ich niemanden aktiv davon abhalten, es für sein eigenes Team auszuprobieren. Wie immer gilt: Meine Erfahrungen sind nur das, meine Erfahrungen, und „your mileage may vary“. Wenn der Qualitätsanspruch in deinem Team jedoch ohnehin hoch ist und ihr alle mit guten KI-Modellen ausgestattet seid, lohnt es sich, sich an einem Freitagnachmittag mal zusammenzusetzen und zu überlegen:

• „Welche Probleme haben wir im Code-Review-Prozess, und wie kann uns eine KI dort helfen?“
• „Wie würde unser optimaler Workflow aussehen, und können wir uns diesen selbst bauen?“

Ich bin mir sicher, dass in einem Raum voller kluger Köpfe eine Lösung entsteht, die besser zu deinem Team und deiner Mission passt, als es ein generisches Tool könnte. Wenn du eine externe Sicht benötigst, helfe ich dir gerne weiter. Schreib mir einfach eine E-Mail an hi@martinzoeller.com oder vernetze dich mit mir auf LinkedIn.