KI wird meistens zuerst als Werkzeug zum Schreiben von Code wahrgenommen.

Für mich ist aber ein anderer Einsatzbereich mindestens genauso spannend:

Code Review.

Denn wenn ein Coding-Agent Code erzeugen kann, sollte er idealerweise auch in der Lage sein, Änderungen kritisch zu prüfen.

Dabei geht es nicht nur um offensichtliche Bugs.

Ein guter Review sollte auch Dinge erkennen wie:

• Architekturverstöße
• falsches State Management
• unnötige Kopplung
• fehlende Tests
• Lifecycle-Probleme
• Accessibility-Lücken
• unnötige Komplexität
• inkonsistente Projektpatterns

Genau deshalb nutze ich Claude Code nicht nur als Implementierer, sondern auch bewusst als zweite Review-Instanz.

---

Warum KI-generierter Code trotzdem reviewed werden muss

Dass ein Sprachmodell Code erzeugt, bedeutet nicht automatisch, dass dieser Code gut in ein bestehendes Projekt passt.

Er kann technisch funktionieren und trotzdem problematisch sein.

Zum Beispiel:

• falsche Verantwortlichkeiten
• neue Architekturpatterns ohne Not
• unnötige Abstraktionen
• schlechte Fehlerbehandlung
• fehlende Tests
• schlechte Wartbarkeit
• inkonsistente Namensgebung

Gerade weil KI sehr schnell Code produziert, ist Review aus meiner Sicht eher wichtiger geworden – nicht weniger wichtig.

Denn Geschwindigkeit hilft nur, wenn nicht genauso schnell technische Schulden entstehen.

Review und automatische Korrektur bewusst trennen

Ein wichtiger Punkt in meinem Workflow ist deshalb:

Claude soll zunächst nur reviewen – noch nichts verändern.

Das klingt trivial, ist aber wichtig.

Wenn ein Agent direkt analysiert und gleichzeitig korrigiert, ist später kaum noch nachvollziehbar:

• was ursprünglich problematisch war
• welche Findings tatsächlich erkannt wurden
• welche Änderungen eigenständig vorgenommen wurden
• welche Kritik ich selbst überhaupt teile

Deshalb beginne ich mit einem reinen Review.

Zum Beispiel:

Führe ausschließlich ein Code Review durch.

Ändere noch keinen Code.

Analysiere den aktuellen Git-Diff gegen den letzten sauberen Stand.

Prüfe insbesondere:

- Architekturverstöße
- Reactive-State-Fehler
- ViewModel-Probleme
- Dependency Injection
- Networking
- Lifecycle und Coroutines
- Error Handling
- Accessibility
- fehlende Tests
- Wartbarkeit
- unnötige Komplexität
- mögliche Bugs oder Regressionen

Klassifiziere jedes Finding als:

- Critical
- Important
- Suggestion

Für jedes Finding:
1. Datei und Stelle
2. Problem
3. mögliche Auswirkung
4. empfohlene Lösung

Wichtig:
Nichts automatisch ändern.

Die KI soll aktiv nach Problemen suchen

Bei einem Review möchte ich kein höfliches:

„Sieht insgesamt gut aus.“

Deshalb formuliere ich die Aufgabe bewusst kritisch.

Zum Beispiel:

Gehe davon aus, dass ich absichtlich schlechten Code eingebaut habe. Versuche herauszufinden, wo.

Das verändert die Perspektive.

Der Agent soll nicht bestätigen.

Er soll versuchen, Schwächen zu finden.

---

Projektregeln machen den Review interessanter

Ein allgemeiner Code Review ist hilfreich.

Noch interessanter wird es aber, wenn Claude die konkreten Projektregeln kennt.

In meinem Projekt liegen diese direkt im Repository:

CLAUDE.md

docs/
├── philosophy.md
├── architecture.md
├── android-style.md
├── ios-style.md
└── review-guidelines.md

Dadurch prüft Claude nicht nur:

„Ist dieser Code grundsätzlich valide?“

sondern:

„Passt diese Änderung zu unserer Architektur und unserem Coding Style?“

Das ist für mich ein entscheidender Unterschied.

Ein technisch korrekter Codepfad kann damit trotzdem als Finding auftauchen, wenn er gegen Projektregeln verstößt.

---

Findings priorisieren

Ein Review mit zwanzig gleichwertigen Kommentaren ist kaum hilfreich.

Deshalb lasse ich Findings priorisieren.

Ich nutze dafür drei einfache Kategorien:

Critical

Probleme, die zu Bugs, Datenverlust, Sicherheitsproblemen oder gravierenden Fehlfunktionen führen können.

Important

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

Suggestion

Verbesserungen, die sinnvoll sind, aber keinen Merge blockieren müssen.

---

Mein Praxistest: bewusst schlechten Code einbauen

Um zu sehen, ob Claude wirklich kritisch reviewt, habe ich absichtlich eine fehlerhafte bzw. architektonisch schlechte Implementierung eingebaut.

Das war für mich deutlich aussagekräftiger als einfach zu fragen:

„Reviewe mal meinen Code.“

Denn ich wusste, dass konkrete Probleme vorhanden waren.

Claude bekam anschließend nur den aktuellen Diff und die Review-Regeln.

Das Ergebnis war überraschend brauchbar.

Die Findings beschränkten sich nicht nur auf Syntax oder Stil.

Claude erkannte auch Probleme bei Verantwortlichkeiten und Architektur.

Gerade an solchen Stellen wird deutlich, warum ein eigenes Engineering Handbook so wertvoll ist.

Denn der Agent konnte den Code gegen konkrete Projektentscheidungen prüfen.

Der Entwickler entscheidet, was wirklich behoben wird

Ein wichtiger Punkt bleibt:

Claude entscheidet nicht automatisch, welche Findings umgesetzt werden.

Ich sehe mir die Kritik an und entscheide selbst:

• Ist das Finding korrekt?
• Ist es relevant?
• Ist die vorgeschlagene Lösung sinnvoll?
• Gibt es fachliche Gründe, die Claude nicht kennt?

Erst danach bekommt Claude beispielsweise den Auftrag:

„Behebe die Findings 1, 3 und 4. Finding 2 bleibt bewusst unverändert.“

Das ist für mich deutlich näher an einem echten Review-Prozess.

---

Nach dem Fix folgt der nächste Review

Nachdem Claude die akzeptierten Findings behoben hat, ist der Prozess für mich noch nicht abgeschlossen.

Denn auch der Fix selbst kann neue Probleme erzeugen.

Deshalb lasse ich anschließend erneut reviewen.

Diesmal ausdrücklich:

„Reviewe ausschließlich deine eigenen Änderungen. Gehe davon aus, dass auch deine Lösung neue Fehler enthalten könnte.“

Dabei achte ich insbesondere auf:

• Regressionen
• unnötige Komplexität
• neue Architekturverstöße
• inkonsistente Patterns
• fehlende Tests

So entsteht ein zweistufiger Prozess:

Review → Fix → Self Review

---

Auch mein eigener Code kann so reviewed werden

Das ist für mich fast noch interessanter als die Kontrolle von KI-generiertem Code.

Ich arbeite weiterhin selbst in Android Studio und Xcode.

Wenn ich eine Implementierung ändere, kann Claude anschließend einfach den aktuellen Git-Diff analysieren.

Damit funktioniert derselbe Review-Prozess unabhängig davon, wer den Code geschrieben hat.

Also:

KI-Code → Review

genauso wie:

mein Code → Review

Das ist wichtig, weil der Coding-Agent dadurch nicht nur zum Generator wird, sondern zu einer zusätzlichen Qualitätsschicht im normalen Entwicklungsprozess.

Wo KI-Code-Reviews besonders hilfreich sind

Ich sehe mehrere Situationen, in denen dieser Workflow gut passt.

Vor einem Pull Request

Ein KI-Review kann offensichtliche Probleme herausfiltern, bevor ein Kollege Zeit in den Review investiert.

Nach größeren Refactorings

Gerade wenn viele Dateien betroffen sind, kann Claude gezielt nach Inkonsistenzen und möglichen Regressionen suchen.

Bei Architekturänderungen

Wenn Projektregeln dokumentiert sind, kann Claude überprüfen, ob neue Änderungen diese tatsächlich einhalten.

Bei eigenem Code

Ein zweites Paar Augen ist besonders hilfreich, wenn man selbst lange an derselben Implementierung gearbeitet hat.

Bei KI-generiertem Code

Hier halte ich Review sogar für Pflicht.

Die Tatsache, dass der Agent den Code geschrieben hat, ist kein Qualitätsnachweis.

Wo die Grenzen liegen

Ein KI-Reviewer ersetzt trotzdem keinen erfahrenen Entwickler.

Claude kennt zwar den Quellcode und dokumentierte Projektregeln.

Aber er kennt nicht automatisch:

• alle Produktentscheidungen
• historische Hintergründe
• implizite Kundenanforderungen
• organisatorische Absprachen
• reale Nutzerprobleme

Außerdem kann ein KI-Review:

• False Positives erzeugen
• legitime Entscheidungen infrage stellen
• zu viel abstrahieren wollen
• Probleme übersehen
• fachliche Zusammenhänge falsch interpretieren

Deshalb ist Claude für mich kein Gatekeeper.

Es ist eine zusätzliche Review-Ebene.

---

Damit verändert sich die Rolle von KI.

Vom reinen Codegenerator hin zu einem Engineering-Assistenten, der mehrere Phasen eines normalen Entwicklungsprozesses unterstützen kann.

Reviews werden besser, wenn das Projekt besser dokumentiert ist

Dieser Punkt verbindet Code Review direkt mit dem Engineering Handbook.

Je klarer die Projektregeln dokumentiert sind, desto konkreter kann Claude prüfen.

Statt:

„Ist das guter Code?“

kann Claude Fragen beantworten wie:

„Verstößt dieser ViewModel-State gegen unsere Architektur?“

„Wurde eine neue Dependency eingeführt, obwohl das laut Engineering Contract vorher abgestimmt werden muss?“

„Ist diese Compose-Komponente nach unseren Regeln zu stark mit Businesslogik gekoppelt?“

Damit wird aus einem allgemeinen KI-Review ein projektspezifischer Review.

---

Fazit: KI als zweites Paar Augen

Code Review ist für mich aktuell einer der sinnvollsten Einsatzbereiche von Claude Code.

Nicht weil der Agent unfehlbar wäre.

Sondern weil Review eine Aufgabe ist, bei der ein zusätzliches systematisches Paar Augen sehr wertvoll sein kann.

Besonders stark wird der Workflow, wenn:

1. Projektregeln dokumentiert sind.
2. Review und Änderungen bewusst getrennt werden.
3. Findings priorisiert werden.
4. der Entwickler weiterhin entscheidet.
5. auch die anschließenden Fixes erneut geprüft werden.

Dann entsteht ein relativ einfacher, aber wirkungsvoller Prozess:

Implementieren → reviewen → entscheiden → korrigieren → erneut prüfen

Für mich ist das ein deutlich interessanterer Einsatz von KI als bloß:

„Schreib mir diese Funktion.“

Denn damit wird KI zu einem Bestandteil der Qualitätssicherung.

Und genau dort kann sie meiner Meinung nach langfristig genauso wertvoll werden wie bei der eigentlichen Implementierung.