Wie wir AI-generierten Code prüfen, ohne das Team auszubremsen

Vor einem Jahr war AI-generierter Code in Pull Requests noch eine Kuriosität. Heute ist er in vielen der Codebasen, an denen wir arbeiten, zur Normalität geworden.

Was damit nicht Schritt gehalten hat, ist die Art und Weise, wie Teams diesen Code reviewen. Wir beobachten dabei zwei Fehlermuster – und beide funktionieren nicht.

Das erste ist „Review-Theater“: Ein Reviewer scrollt durch einen Diff mit 400 Zeilen, sieht, dass der Code kompiliert und die Tests bestehen, und klickt auf „LGTM“, ohne wirklich zu verstehen, was sich geändert hat. Die Annahme lautet: Wenn das Modell den Code geschrieben hat und nichts fehlgeschlagen ist, wird es schon passen.

Das zweite ist das gegenteilige Extrem: Over-Review. Teams reagieren auf die Risiken von AI-generiertem Code, indem sie jede einzelne Zeile unter die Lupe nehmen. Naming, Formatting, Struktur – alles wird diskutiert. Reviews dauern länger, der Durchsatz sinkt und das Team kommt fast zum Stillstand.

Keiner der beiden Ansätze ist skalierbar. Und keiner entspricht dem eigentlichen Zweck eines Code Reviews.

Das Modell, das für uns funktioniert – und auf das wir uns in unseren Embedded-Projekten geeinigt haben –, behandelt Code Review als ein mehrstufiges System.

Maschinen kümmern sich um die Form. Menschen schützen die Absicht.

Was automatisiert werden sollte, bevor ein Mensch überhaupt hinschaut

Die meisten Teams haben die Grundlagen bereits etabliert: Linting, Type Checking und eine Testsuite. Das ist die Grundvoraussetzung. Bei AI-generiertem Code reicht sie jedoch nicht aus. Wir erweitern die automatisierte Ebene in drei Richtungen:

1. Standard Quality Gates – Linting, Formatting, Type Safety und Testausführung –, damit der Code grundlegende Qualitätsanforderungen erfüllt, bevor ein Reviewer ihn überhaupt sieht.
2. Security- und Compliance-Checks – Static Application Security Testing (SAST) sowie Dependency- und License-Scanning, um bekannte Schwachstellen zu erkennen und problematische Abhängigkeiten aus der Codebasis fernzuhalten.
3. AI-spezifische Checks – und genau hier haben viele Teams noch Lücken.

Diese dritte Ebene ist darauf ausgelegt, Fehlermuster zu erkennen, die klassische Tools häufig übersehen:

• Halluzinierte API-Aufrufe: Das Modell verweist auf eine Methode, die in der tatsächlich verwendeten Version des SDK gar nicht existiert. Der Code sieht korrekt aus, kann sogar Type Checks bestehen, schlägt aber zur Laufzeit fehl.
• Veraltete oder nicht passende Abhängigkeiten: Code, der auf Basis veralteter Dokumentation generiert wurde.
• Lizenzproblematische Code-Snippets: Code, der möglicherweise aus Quellen stammt, die mit Ihrem Lizenzmodell nicht vereinbar sind.

Keines dieser Probleme wird von Standard-CI-Pipelines zuverlässig erkannt. Gleichzeitig treten alle relativ häufig in AI-generiertem Code auf.

Die gute Nachricht: Solche Checks müssen nicht komplex sein. Eine kleine Zahl projektspezifischer Regeln – oft innerhalb eines Tages umgesetzt – kann ganze Risikokategorien eliminieren. Und sobald sie eingerichtet sind, skalieren sie automatisch mit.

Bis ein menschlicher Reviewer den Pull Request sieht, ist die „Form“ des Codes – Syntax, Struktur und grundlegende Security – bereits abgesichert.

Was menschliche Aufmerksamkeit braucht – und was nicht

Sobald Maschinen sich um die Form kümmern, können sich menschliche Reviewer auf das konzentrieren, was wirklich zählt: die Absicht. Genau hier schaffen erfahrene Engineers echten Mehrwert. Die wichtigsten Bereiche, die wir bewusst menschlich reviewen lassen, sind:

• Architektonische Passung: Gehört diese Änderung an diese Stelle? Passt sie zur Struktur und zu den Grenzen des Systems?
• Absicht beim Error Handling: Werden Fehler so behandelt, wie es den Erwartungen des Teams entspricht, oder werden sie stillschweigend ignoriert?
• Security-relevante Abläufe: Alles, was Authentifizierung, Autorisierung oder personenbezogene Daten (PII) betrifft.
• Plausible, aber subtil falsche Logik: Code, der korrekt aussieht, das im Ticket beschriebene Problem aber nicht tatsächlich löst.

AI ist sehr gut darin, plausiblen Code zu erzeugen. Deutlich weniger zuverlässig ist sie dabei, im jeweiligen Kontext tatsächlich korrekten Code zu erzeugen.

Ebenso wichtig ist die Frage, was keine menschliche Aufmerksamkeit benötigt:

• Formatting
• Naming Conventions
• Kleinere stilistische Präferenzen

Das sind Formfragen – und Formfragen sollten von Tools gelöst werden, nicht in Reviews diskutiert werden. Wenn Menschen ihre Zeit damit verbringen, werden sie nicht nur ineffizient eingesetzt, sondern auch von den tatsächlich relevanten Risiken abgelenkt.

Wo AI-Reviewer helfen – und wo sie den Prozess verschlechtern

AI generiert nicht nur Code, sondern wird zunehmend auch für dessen Review eingesetzt. Richtig eingesetzt, können AI-Reviewer den Prozess beschleunigen. Besonders hilfreich sind sie bei:

• Zusammenfassungen von Diffs: Sie liefern schnell einen Überblick darüber, was sich geändert hat.
• Wiederkehrenden Mustern: Sie erkennen doppelte Logik oder Inkonsistenzen.
• Riskanten Konstrukten: Sie weisen auf bekannte Anti-Patterns oder verdächtige Strukturen hin.

In diesen Bereichen skaliert AI Aufgaben, die Menschen bereits gut beherrschen. Es gibt jedoch auch klare Schwächen. AI-Reviewer neigen dazu:

• Zu viele irrelevante Kommentare zu erzeugen: Das führt schnell zu Review Fatigue und lenkt vom Wesentlichen ab.
• Falsche Sicherheit zu schaffen: Reviewer gehen davon aus, dass der AI-Reviewer „alles abgedeckt hat“.
• Kontext über mehrere Dateien oder Systeme hinweg zu übersehen: insbesondere dann, wenn sich die eigentliche Absicht über mehrere Komponenten erstreckt.

Das Ergebnis ist häufig ein Review-Prozess, der gründlich wirkt, es aber nicht ist. Unsere Faustregel ist deshalb einfach:

AI-Reviewer sind gut darin, Aufgaben zu skalieren, die Menschen bereits gut beherrschen. Sie ersetzen jedoch nicht die Aufgaben, bei denen menschliches Urteilsvermögen entscheidend ist.

Die Checkliste, die wir tatsächlich verwenden

Um dieses Modell im Alltag umzusetzen, nutzen wir eine kurze Checkliste, die Reviews fokussiert und konsistent hält. Eine Version davon können Sie direkt übernehmen:

1. Verweist ein Funktionsaufruf auf eine API, von der unser System gar nicht abhängig ist?
2. Gibt es Fehlerpfade, die stillschweigend scheitern oder Exceptions unterdrücken?
3. Werden Eingaben an Trust Boundaries ordnungsgemäss validiert?
4. Passt diese Änderung zur Architektur des umgebenden Codes?
5. Werden Security-relevante Abläufe wie Authentifizierung, Autorisierung oder personenbezogene Daten korrekt behandelt?
6. Prüfen die Tests das tatsächliche Verhalten und nicht nur die Struktur?
7. Ist Code enthalten, dessen Herkunft wir aus lizenzrechtlicher Sicht nicht nachvollziehen können?
8. Konzentriert sich der Diff auf einen klar abgegrenzten Aspekt oder vermischt er mehrere Verantwortlichkeiten?
9. Erklärt die Pull-Request-Beschreibung die Absicht hinter der Änderung und nicht nur, was geändert wurde?
10. Gibt es etwas, das korrekt aussieht, aber möglicherweise nicht der ursprünglichen Anforderung entspricht?

Diese Checkliste ist bewusst kurz gehalten. Sie soll nicht alles abdecken – sondern die Aufmerksamkeit auf die Punkte lenken, die wirklich relevant sind.

Entscheidend ist die Struktur – nicht das Tooling

Teams fragen uns häufig, welche Tools sie einsetzen sollten, um Code Reviews in AI-intensiven Umgebungen zu verbessern. Die Antwort ist: Das Tooling ist zweitrangig.

Die entscheidende Frage ist, wie der Review-Prozess strukturiert ist.

Sobald ein mehrstufiges Modell etabliert ist – Maschinen kümmern sich um die Form, Menschen schützen die Absicht –, ergibt sich die Tool-Auswahl weitgehend von selbst und bleibt vergleichsweise überschaubar. Ohne diese Struktur hilft auch die fortschrittlichste Toolchain nicht. Dann landet das Team weiterhin in einem der beiden problematischen Extreme:

• „Review-Theater“, bei dem kaum etwas Wesentliches entdeckt wird.
• „Over-Review“, bei dem das Team so stark ausgebremst wird, dass Delivery darunter leidet.

Review-Geschwindigkeit ist kein Tooling-Problem. Sie ist eine Frage der richtigen Struktur.

Fazit

In AI-intensiven Codebasen nimmt das Code-Volumen zu und das Risikoprofil verändert sich. Das Ziel eines Code Reviews bleibt jedoch dasselbe: die Integrität des Systems zu schützen, ohne den Fortschritt zu blockieren.

Erfolgreiche Teams reviewen nicht einfach mehr oder weniger – sie reviewen anders. Sie lassen Maschinen für Konsistenz sorgen, verlassen sich bei der Absicht auf menschliches Urteilsvermögen und gestalten den Prozess so, dass beide ihre jeweiligen Stärken ausspielen können.