AI für Code Reviews einsetzen: Tipps aus echten Teams

Über AI, die Code schreibt, redet gerade jeder. Über die Kehrseite auch, nur fällt die Antwort dort meist weniger eindeutig aus. Denn je mehr Code eine KI produziert, desto mehr Code muss auch jemand reviewen. Wer mit einem Agenten das Zehnfache raushaut, erzeugt auch das Zehnfache an Review-Bedarf. Die naheliegende Antwort: das Review ebenfalls einer KI geben. Genau das führt bei vielen Teams aber zu Enttäuschung.

Ein AI-Review kann an ganz unterschiedlichen Stellen sitzen und unterschiedlich stark automatisiert sein: vor dem Commit, als automatisches Gate in der Pipeline, neben dem menschlichen Review, oder auf Zuruf. Wir zeigen das an zwei Setups aus der Praxis, die an unterschiedlichen Enden dieses Spektrums liegen. Michael Pehl, Senior Software Entwickler bei DevBoost, hat mit seinem Team in einem Kundenprojekt ein eigenes, schlankes AI-Review gebaut, das auf Zuruf läuft. Johannes Hense, ebenfalls Senior Software Entwickler bei DevBoost, arbeitet in einem Projekt mit einem automatisierten Review, das dauerhaft mitläuft und aus mehreren spezialisierten Reviewern besteht. Beide Wege funktionieren. Interessanter als die Frage, welcher besser ist, sind die Dinge, die in beiden über Erfolg oder Frust entscheiden.

In unseren Gesprächen mit 92 Tech Leads und Engineering Leads kam ein Muster immer wieder. Das AI-Review meldet zu viel, das meiste davon Kleinkram. Ein Tech Lead bringt es auf den Punkt: „Wir kriegen Hinweise, die wir nicht nutzen können, dann schalten wir es ab."

Der zweite Punkt geht tiefer. AI-Reviews setzen gern am Symptom an, nicht an der Ursache. „AI macht Vorschläge bei Fehlern, fixt aber das Symptom, nicht die Ursache", sagt ein anderes Team.

Beides führt zum selben Ende. Das Team verliert das Vertrauen und schaut irgendwann nicht mehr hin. Richtig eingesetzt ist ein AI-Review aber genau das Gegenteil. „Ist wie ein zweites Paar Augen", sagt ein drittes Team, und mehrere berichten, dass die KI ihnen die ungeliebten Aufgaben abnimmt: Testabdeckung, Security-Checks, den ersten Durchgang durch einen langen Diff. Ob es das eine oder das andere wird, entscheidet sich im Detail.

Es gibt viele verschiedene Setups, um KI Code-Reviews über generierten Code durchführen zu lassen. Wir zeigen euch zwei Ansätze aus unterschiedlichen Kundenprojekten, denn sie zeigen eine gute Bandbreite dessen, was möglich und sinnvoll ist.

Das Unternehmen, in dem Michael im Rahmen eines Kundenprojektes arbeitet, hostet GitHub selbst, ein fertiges AI-Review für Pull Requests gab es dafür nicht. Also haben sie selbst eins gebaut, direkt in die GitHub-Workflows integriert. Es läuft auf Anfrage: Wer ein Review will, schreibt /ai review als Kommentar an den Pull Request. Das Ergebnis ist ein Kommentar, der nichts blockiert, die Funde nach critical, medium und low sortiert und Feedback mit relevanten Verbesserungen gibt. Der Vorteil: Das Review drängt sich niemandem auf und wird als Hilfe wahrgenommen, nicht als Kontrolle. Und es wird genutzt, allein in den letzten 30 Tagen wurden von einem Team mit 5-10 Nutzern 216 Reviews angefragt, rund 90 Prozent der Funde wurden als hilfreich bewertet.

Johannes' Projekt geht den anderen Weg. Dort läuft das Review automatisch, niemand muss daran denken, und es besteht aus mehreren Reviewern statt einem. Neben GitHub Copilot, der von Haus aus schon viel mitbringt, gibt es einen selbstgebauten Schwarm aus Review-Agenten mit unterschiedlichem Fokus: einer schaut genauer auf Security, einer auf Wartbarkeit, und so weiter. Der Vorteil hier: Es läuft immer, nichts geht durch, und verschiedene Blickwinkel decken mehr ab als ein einzelner. Die Kommentare treffen dabei meist so, dass die Entwickler sie wirklich bearbeiten wollen.

Kein Weg ist per se besser. Der eine passt, wenn das Review ein Angebot sein soll, das jeder bei Bedarf zieht. Der andere passt, wenn nichts durchrutschen darf. Was in beiden über Erfolg entscheidet, ist dasselbe.

Der häufigste Grund, warum ein KI-erzeugtes Code Review enttäuscht, ist fehlender Kontext. Ein generischer AI-Reviewer, der eure Konventionen, eure Architektur und eure Domäne nicht kennt, produziert genau das Rauschen, das Teams am Ende abschalten.

Ein Beispiel aus der Praxis: Michaels Team arbeitete mit einer Sprachversion, die so neu war, dass sie den Trainingsstand des Modells überholt hatte, und es lag keine AGENTS.md im Repo, die das dokumentiert hätte. Also meldete das Review korrekten Code als Fehler, mit der Begründung, das gebe es doch gar nicht. Kein Modellfehler, sondern fehlender Kontext.

Was hilft: eine AGENTS.md und dokumentierte Review-Kriterien, die festhalten, worauf euer Team wirklich Wert legt. Und ein Review, das nicht nur die geänderten Zeilen sieht, sondern das ganze Repository, erkennt auch Brüche im Zusammenhang, etwa wenn plötzlich eine Datei in einer anderen Sprache auftaucht als der Rest des Service.

Eine häufige Frage ist, ob es einen Unterschied macht, denselben Agenten reviewen zu lassen, der den Code geschrieben hat. Und die Antwort lautet ja, sogar auf zwei Ebenen.

Die erste ist der Kontext, also der Agent. Wer denselben Agenten den Code schreiben und danach bewerten lässt, bekommt öfter ein Review, das die eigenen Annahmen bestätigt, da der Kontext bereits eine Argumentation für eine bestimmte Lösung enthält. Startet das Review deshalb in einem frischen Kontext, der nur Aufgabe, Anforderungen, Code und Review-Kriterien kennt, nicht aber die Überlegungen aus dem Schreiben. So urteilt die KI unabhängiger von ihrem eigenen Denkweg.

Die zweite ist das Modell. Ihr könnt auch einen Schritt weiter gehen und nicht nur mit einem neuen Kontext, sondern auch einem anderen KI-Modell das Review erzeugen lassen. Modelle mögen ihren eigenen Code, dasselbe Modell fürs Schreiben und Bewerten findet oft weniger. Gebt den Code einem Modell aus einer anderen Familie oder von einem anderen Anbieter, dann kommen die Kleinigkeiten zum Vorschein, über die das erste hinweggesehen hat, und gemeinsame blinde Flecken sinken. Das muss nicht das teuerste Modell sein, aber beachtet: Kleine Open-Source-Modelle senken zwar die Kosten, sind als Bewerter aber nicht immer zuverlässig.

Das größte Risiko ist allerdings meist nicht, dass ein AI-Review zu wenig findet, sondern zu viel. Wenn jeder zweite Hinweis Kleinkram ist, schaltet das Team irgendwann auf Durchzug. Ein paar Dinge helfen zuverlässig dagegen.

Gib jedem Fund eine Kritikalität. Von Nitpick, das man schöner machen könnte, aber nicht muss, bis zum kritischen Security-Problem. Das eine überfliegt man, das andere behebt man sofort. Diese Einordnung macht den Unterschied zwischen einer Wand aus Kommentaren und einer Liste, die ihr ernst nehmt.

Und lass die Funde eine Confidence mitliefern. Confidence ist etwas anderes als Kritikalität: nicht wie wichtig ein Fund ist, sondern wie sicher sich der AI-Reviewer ist, dass er überhaupt stimmt. Funde, bei denen er unsicher ist, werden nicht prominent angezeigt, sondern nur in einer Zusammenfassung gesammelt, nach dem Motto: hier sind fünf Funde, bei denen der Reviewer sich nicht sicher ist, schau rein oder ignorier sie. So bleibt vorne nur, was belastbar ist.

Wisse, wann Schluss ist. Wer nach dem Einarbeiten den Reviewer wieder losschickt, bekommt neue Funde, und noch mal, und noch mal. Spätestens ab der zweiten oder dritten Runde wird es albern, dann sind es Vorschläge, die niemand braucht. Ein gutes Review erkennt das teils selbst und sagt, dass nichts Wesentliches mehr offen ist. Wo es das nicht tut, zieht ihr die Grenze.

Liefere den Fix gleich mit. Findet das Review etwas, ist es viel wert, wenn es dazu einen fertigen Prompt mitgibt, mit dem der eigene Agent es beheben kann. Aus „hier ist ein Problem" wird so in einem Schritt „und so machst du es weg". Michaels Team hat den Reviewer genau so aufgesetzt, das hat die Akzeptanz spürbar erhöht.

In Michaels Projekt gibt es neben /ai review den zweiten Befehl /ai response. Damit stellt man dem Pull Request eine konkrete Frage, begrenzt auf das Repository. Zum Beispiel: „Passt die PR-Beschreibung zu dem, was geändert wurde?" oder „Diese CI-Jobs sind durchgelaufen, die Logs sind endlos, was ist schiefgegangen und was muss ich tun?" Statt sich selbst durch die Logs zu wühlen, fragt man einfach.

Praktisch daran: Der Workflow hängt an den Repositories, nicht an einzelnen Personen. So kann auch jeder, der selbst keine AI-Tools in seiner Entwicklungsumgebung eingerichtet hat, seinen Code prüfen lassen. Das holt genau die Leute ab, die sonst außen vor blieben.

Bisher ging es um das AI-Review. Das menschliche Review verschwindet damit nicht, aber sein Fokus verschiebt sich. Wo ein Team ein klares System für agentisches Arbeiten aufgebaut hat, mit sauberer Architektur, guten Tests und vielen automatischen Checks, liest man den generierten Code oft gar nicht mehr Zeile für Zeile, der passt meist schon. Stattdessen schaut man auf die Tests: Gibt es sie, sind sie nachvollziehbar, beweisen sie, was der Code tun soll? Das trägt aber nur mit genau diesem Fundament. Wie ihr das aufbaut, beschreiben wir im Beitrag zu Agentic Coding.

Ob ein AI-Review hilft oder nervt, entscheiden ein paar konkrete Dinge, egal ob es auf Zuruf oder automatisch läuft:

• Gebt ihm Kontext. Eine AGENTS.md und dokumentierte Review-Kriterien machen aus einem generischen Reviewer einen, der euer Projekt kennt.
• Lasst ein anderes Modell reviewen als das, das den Code geschrieben hat.
• Bändigt das Rauschen. Kritikalität und Confidence an jedem Fund trennen das Wichtige vom Nitpick und das Sichere vom Unsicheren, und irgendwann ist Schluss.
• Ein Tipp für saubere Pull Requests: Lasst eure Code-Änderungen vor dem Öffnen des PRs auf dem eigenen Rechner agentisch reviewen. Räumt die gefundenen Punkte direkt auf, und der PR bleibt frei von klopapierrollenlangen KI-Kommentaren.

Eine Frage solltet ihr klären, bevor das erste Review läuft. Sie kam in fast jedem unserer Interviews auf: Wer ist verantwortlich, wenn KI-generierter Code schlecht ist und trotzdem gemergt wird? Das ist keine technische Frage. Aber sie entscheidet, ob euer Team dem Review vertraut oder es umgeht.

Wie sieht euer AI-Review-Prozess aus? Bei DevBoost kennen wir das AI-Code-Review-Setup vieler Teams und haben gesehen, was gut funktioniert und was nicht, vom Review auf Anfrage bis zum stärker automatisierten Prozess. Gerne schauen wir uns euren Review-Prozess an und überlegen mit euch, wie ihr ihn verlässlich und sicher aufsetzt.