KCT
Zurück zum Journal
code-reviewki-agentopencodeautomationqualitaetssicherung

KI-gestütztes Code-Review: Der Agent, der meine Pull Requests prüft

Ich habe einen Coding Agent so konfiguriert, dass er automatisch meine PRs reviewed - komplett lokal, kein Code verlässt meine Maschine.

KI-gestütztes Code-Review: Der Agent, der meine Pull Requests prüft

Code-Review ist wichtig. Code-Review ist aber auch anstrengend. Besonders wenn du allein an einem Projekt arbeitest und niemanden hast, der über deinen Code schaut, bevor du ihn committest.

Ich habe einen Coding Agent so konfiguriert, dass er diese Lücke füllt. (Warum ich mich für

<a href="https://github.com/opencode-ai/opencode↗" target="_blank" rel="noopener noreferrer"

OpenCode ↗ und nicht Cursor ↗ ↗ oder Claude Code ↗ ↗ entschieden habe, zeige ich im Coding-Agents-Duell.)

Die Idee

Wenn ich einen Branch pushe, triggert ein Hook meinen lokalen Coding Agent (OpenCode mit Qwen3 – wie der Agent funktioniert, beschreibe ich in OpenCode: Der lokale Coding-Agent). Der Agent:

  1. Liest den Diff zwischen Branch und main
  2. Analysiert jede geänderte Datei
  3. Schreibt ein Review mit Kommentaren, Verbesserungsvorschlägen und potentiellen Bugs

Das ganze lauft lokal. Kein Code verlasst meine Maschine.

Die Konfiguration

Der Hook ist ein einfaches Git-Skript, das bei jedem Push den Agenten startet. Die Konfiguration des Agenten sagt ihm, dass er sich wie ein Senior Developer verhalten soll, der einen Junior reviewed: konstruktiv, spezifisch, nicht arrogant.

Was funktioniert

Syntax-Fehler: Der Agent findet sie fast immer. Vor allem in Python und

<a href="https://www.typescriptlang.org↗" target="_blank" rel="noopener noreferrer"

TypeScript ↗, wo er die Typen prüfen kann.

Fehlende Fehlerbehandlung: Das ist seine stärkste Kategorie. Er erkennt, wenn ich einen API-Aufruf nicht auf Fehler prüfe oder eine Datenbankabfrage ohne Try-Check lasse.

Inkonsistente Benennung: Einmal hatte ich in derselben Datei drei verschiedene Bezeichnungen für denselben Begriff. Der Agent hat alle drei gefunden.

Wo er daneben liegt

False Positives bei Architekturentscheidungen: Manchmal kritisiert er Muster, die bewusst gewählt sind (z.B. einen schnellen Fix statt der sauberen Lösung). Das muss ich dann ignorieren.

Zu oberflächlich bei komplexen Änderungen: Wenn ich eine große Refactoring-Struktur ändere, versteht er den Gesamtkontext nicht immer. Er sieht die Bäume, aber nicht den Wald.

Manchmal zu wortlich: Er hat schon "Bitte Kommentar hinzufügen" gesagt, obwohl die Stelle selbsterklarend war.

Das Fazit nach drei Monaten

Der Agent reviewed nicht wie ein menschlicher Kollege. Aber er reviewed besser als nichts. Und da ich keine menschlichen Kollegen habe, die meine Code-Reviews machen konnten, ist er ein Gewinn.

Ich schätze, dass er mir etwa 70% der Review-Arbeit abnimmt. Die restlichen 30% – die Architekturentscheidungen, die Abwägungen, den gesunden Menschenverstand – muss ich immer noch selbst machen.

Aber das ist okay. Der Agent ist nicht da, um mich zu ersetzen. Er ist da, um mir den Rücken freizuhalten für die Dinge, die menschliches Urteilsvermögen brauchen.

Übrigens: Der Code-Review-Server ist auch als MCP-Server realisiert – welche drei MCP-Server meinen Alltag verändert haben, zeige ich in Drei MCP-Server, die meinen Workflow verändert haben.