Code Review mit Claude Code: Kann KI wirklich als zweiter Senior-Entwickler taugen?

KI-generierter Code ist schnell erstellt. Genau deshalb halte ich einen anderen Schritt für mindestens genauso wichtig:

Code Review.

Denn nur weil eine KI Code erzeugen kann, bedeutet das nicht automatisch, dass dieser Code architektonisch sinnvoll, wartbar oder fehlerfrei ist.

In meinem aktuellen KI-gestützten App-Projekt wollte ich deshalb nicht nur testen, wie gut Claude Code Features implementiert.

Ich wollte wissen:

Kann Claude meinen Code genauso kritisch prüfen, wie es ein erfahrener Entwickler in einem Pull Request tun würde?

Um das herauszufinden, habe ich einen kleinen Test gemacht.

Ich habe bewusst Code eingebaut, von dem ich wusste, dass er mehrere Probleme enthält.

Dann habe ich Claude ausschließlich als Reviewer eingesetzt.

Das Experiment
Ich schreibe bewusst problematischen Code. Claude darf ihn zunächst nur analysieren – nicht verändern.

Warum ich Review und Fix voneinander trenne

Ein Punkt war mir dabei besonders wichtig:

Claude sollte den Code nicht direkt reparieren.

Denn wenn ein Agent gleichzeitig analysiert und verändert, ist später kaum noch nachvollziehbar, was er tatsächlich erkannt hat.

Deshalb bestand der erste Schritt ausschließlich aus Review.

Mein Prompt lautete sinngemäß:

Führe ausschließlich ein Code Review durch.

Ändere keinen Code.

Prüfe unter anderem:

- Architekturverstöße
- State Management
- ViewModel-Probleme
- Dependency Injection
- Networking
- Lifecycle und Coroutines
- Fehlerbehandlung
- Accessibility
- fehlende Tests
- Wartbarkeit
- unnötige Komplexität

Klassifiziere jedes Finding als:

- Critical
- Important
- Suggestion

Nenne zu jedem Finding:

1. Datei und Stelle
2. Problem
3. Auswirkung
4. empfohlene Lösung

Außerdem habe ich Claude ausdrücklich gesagt:

Gehe davon aus, dass ich absichtlich schlechten Code eingebaut habe. Suche aktiv danach.

Das klingt banal, verändert aber den Ton des Reviews deutlich.

Warum ein Engineering Handbook dabei wichtig ist

Der Review-Agent sollte nicht nur allgemeine Best Practices anwenden.

Er sollte nach meinen Projektregeln reviewen.

Deshalb verwendet Claude in meinem Projekt ein versioniertes Engineering Handbook mit Regeln zu:

  • Architektur
  • Android
  • iOS
  • Reactive State
  • Koin
  • Ktor
  • Testing
  • Accessibility
  • Review-Verhalten

Dadurch lautet die Frage nicht nur:

Ist dieser Code irgendwie okay?

Sondern:

Passt dieser Code zu diesem konkreten Projekt?

Das ist aus meiner Sicht ein großer Unterschied.

📐

Projektregeln

Architektur, Naming, Libraries und Coding Style bilden die Basis des Reviews.

🔍

Git-Diff

Claude untersucht gezielt die Änderungen statt wahllos das gesamte Projekt zu kommentieren.

🧠

Kritische Bewertung

Funktionierender Code darf trotzdem als problematisch markiert werden, wenn er architektonisch falsch ist.

Das Ergebnis

Claude hat die eingebauten Probleme tatsächlich erkannt und als Findings strukturiert aufgelistet.

Das fand ich vor allem deshalb interessant, weil sich die Kritik nicht nur auf offensichtliche Syntax- oder Stilprobleme beschränkt hat.

Auch Dinge wie falsche Verantwortlichkeiten, Architekturverletzungen und fehlende Absicherung durch Tests wurden angesprochen.

Das ist für mich der entscheidende Punkt:

Ein guter Review-Agent sollte nicht nur sagen:

„Der Code kompiliert.“

Er sollte sagen:

„Der Code funktioniert, passt aber trotzdem nicht zu unserer Architektur.“

Findings priorisieren

Ich lasse Claude Findings in drei Kategorien aufteilen:

Critical

Probleme, die Bugs, Datenverlust, Sicherheitsprobleme oder gravierende Architekturfehler verursachen können.

Important

Probleme, die Wartbarkeit, Testbarkeit oder Stabilität deutlich beeinträchtigen.

Suggestion

Verbesserungen, die sinnvoll sind, aber nicht zwingend vor einem Merge umgesetzt werden müssen.

Das hilft enorm.

Denn ein Review mit 25 gleichwertigen Kommentaren ist kaum besser als gar kein Review.

Critical
Fehler mit hohem Risiko oder gravierenden Auswirkungen.
Important
Probleme bei Architektur, Wartbarkeit oder Stabilität.
Suggestion
Sinnvolle Verbesserung, aber kein Merge-Blocker.

Erst reviewen, dann beheben

Nachdem ich die Findings geprüft hatte, durfte Claude sie beheben.

Das ist aus meiner Sicht der richtige Ablauf:

Code
↓
Review
↓
Findings
↓
menschliche Bewertung
↓
Fix
↓
erneutes Review

Nicht:

Code
↓
KI ändert irgendetwas
↓
wird schon passen

Dieser Zwischenschritt ist wichtig, weil ich weiterhin entscheiden möchte, welche Kritik ich überhaupt teile.

Eine KI kann schließlich auch vollkommen legitimen Code unnötig kompliziert machen.

Claude reviewt danach seinen eigenen Fix

Nach der Korrektur lasse ich Claude noch einmal auf den eigenen Diff schauen.

Nicht mit der Erwartung:

„Bestätige, dass jetzt alles gut ist.“

Sondern:

Gehe davon aus, dass auch deine eigene Lösung neue Fehler enthalten kann.

Ein möglicher Prompt:

Reviewe ausschließlich deine eigenen Änderungen.

Suche aktiv nach:

- neuen Bugs
- Regressionen
- unnötiger Komplexität
- Architekturverstößen
- Inkonsistenzen
- fehlenden Tests

Ändere zunächst nichts.

Das klingt vielleicht redundant.

Aber gerade bei größeren Änderungen ist ein zusätzlicher Self-Review erstaunlich sinnvoll.

Mein aktueller Review-Workflow
Implementierung → KI Review → Findings prüfen → Fix → Self Review → Merge

Wo ich Code Reviews mit KI besonders sinnvoll finde

Ich sehe aktuell mehrere interessante Einsatzbereiche.

Eigene Änderungen reviewen

Ich implementiere selbst in Android Studio oder Xcode und lasse anschließend den Git-Diff überprüfen.

Gerade dabei ist KI interessant, weil man für den eigenen Code häufig betriebsblind wird.

KI-generierten Code reviewen

Noch wichtiger.

Nur weil Claude selbst einen Feature-Branch geschrieben hat, sollte er nicht automatisch als korrekt gelten.

Größere Refactorings

Wenn viele Dateien verändert werden, kann Claude gezielt nach Regressionen und inkonsistenten Patterns suchen.

Pull Requests vorbereiten

Vor einem menschlichen Review kann ein KI-Review offensichtliche Probleme herausfiltern.

Dadurch bleibt im eigentlichen Review mehr Zeit für Architektur und Produktlogik.

Wo die Grenzen liegen

Ich würde KI-Code-Reviews trotzdem nicht mit einem menschlichen Review gleichsetzen.

Claude kennt zwar Code und Projektregeln, aber nicht automatisch:

  • alle Business-Zusammenhänge
  • versteckte Produktanforderungen
  • historische Entscheidungen
  • organisatorische Absprachen
  • reale Nutzerprobleme

Außerdem kann auch ein KI-Reviewer:

  • False Positives erzeugen
  • unnötige Abstraktionen vorschlagen
  • wichtige Probleme übersehen
  • funktionierenden Code überoptimieren

Deshalb sehe ich Claude nicht als Ersatz für Reviews.

Sondern als zusätzliche Review-Ebene.

Warum ich diesen Workflow interessant finde

Der spannendste Effekt ist für mich gar nicht, dass Claude Fehler findet.

Es ist die Tatsache, dass derselbe Agent verschiedene Rollen übernehmen kann.

Zum Beispiel:

Claude als Entwickler
↓
Claude als Reviewer
↓
Claude als Refactoring-Partner
↓
Claude als Test-Autor

Entscheidend ist, diese Rollen klar voneinander zu trennen.

Ich sage Claude deshalb ausdrücklich:

Reviewe. Ändere nichts.

Oder später:

Behebe ausschließlich die akzeptierten Findings.

Das verhindert, dass der Agent eigenmächtig den halben Code umbaut.

KI als zweiter Senior-Entwickler?

So weit würde ich heute noch nicht vollständig gehen.

Aber der Gedanke kommt dem tatsächlichen Nutzen inzwischen ziemlich nahe.

Claude Code ist für mich weniger interessant als reiner Codegenerator.

Viel spannender wird es, wenn die KI:

  • bestehende Architektur versteht
  • Projektregeln kennt
  • Änderungen plant
  • Code schreibt
  • Code kritisch hinterfragt
  • Tests ergänzt
  • eigene Fehler wieder sucht

Dann entsteht eher eine Art Pair-Programming-Workflow.

Mein bisheriges Learning
Der größte Nutzen von Claude Code entsteht für mich nicht beim Schreiben von Code – sondern beim Zusammenspiel aus Implementierung, Review, Korrektur und erneutem Review.

Mein Fazit

Mein erster Test mit Code Reviews durch Claude Code war überraschend positiv.

Besonders gut funktioniert es aus meiner Sicht, wenn drei Voraussetzungen erfüllt sind:

  1. Die KI kennt die Architektur und Coding Standards des Projekts.
  2. Review und automatische Änderungen werden bewusst voneinander getrennt.
  3. Die Findings werden weiterhin von einem Entwickler bewertet.

Dann kann KI eine wertvolle zusätzliche Qualitätsschicht sein.

Nicht als unfehlbarer Prüfer.

Sondern als zweites Paar Augen, das jederzeit verfügbar ist und den gesamten Git-Diff noch einmal systematisch hinterfragt.

Und genau darin sehe ich aktuell einen der praktischsten Anwendungsfälle für KI in der professionellen App-Entwicklung.