Code-Review durch KI: Das n+2-Augenprinzip
Wenn Claude den eigenen Code auseinandernimmt
Vor ein paar Wochen habe ich meinen MCP-Server für Shell-Tools veröffentlicht. Funktioniert, nutze ich täglich.
Dann kam mir die Idee, den Code von Claude Code reviewen zu lassen. Nicht von mir selbst, nicht von einem Kollegen - von der KI, mit der ich sowieso arbeite.
Das Setup
Claude Code (CC) in ein Projektverzeichnis schicken und bitten, den Code auf Qualität, Stabilität und Vollständigkeit zu prüfen. Keine Vorgaben, keine Einschränkungen. Einfach: “Schau dir das an und sag mir, was du findest.”
Der Befund
CC lieferte einen strukturierten Report:
| Kategorie | Bewertung | Kommentar |
|---|---|---|
| Codequalität | 4/5 | Saubere Struktur, gutes Type-Hinting |
| Vollständigkeit | 4/5 | Alle Features implementiert |
| Stabilität | 4/5 | Gutes Error-Handling, aber… |
4/5 ist ordentlich. Aber da waren auch noch ein paar Stellen, die meiner Aufmerksamkeit bedurften.
Problem 1: Tests laufen nicht
“Tests importieren
workstation_mcp.*aber Package-Struktur istcode/- Tests aktuell nicht lauffähig.”
Ich hatte die Package-Struktur umgebaut und die Import-Pfade in den Tests nicht angepasst. Die Tests existierten, sahen gut aus - liefen nur nicht. Klassiker.
Problem 2: Sicherheitslücken
Die Blocklist für gefährliche Shell-Befehle hatte Lücken. Patterns wie rm -rf / waren geblockt, aber Varianten wie rm -rf // nicht. Fünf Patterns, mehrere Umgehungsmöglichkeiten. Bei einem Tool mit Shell-Zugriff nicht ideal.
Problem 3: Naming-Chaos
Das Projekt hieß mal workstation_mcp, dann mcp_shell_tools. Aber überall im Code, in Docstrings, in Pfaden stand noch der alte Name. Das Config-Verzeichnis? ~/.workstation_mcp. Der Server-Name? workstation_mcp. Gewachsener Code halt.
Die Fixes
Sieben Commits später:
| Commit | Änderung |
|---|---|
| ad25057 | Tests gefixt (Import-Pfade) |
| db51eeb | Security-Patterns erweitert (5→14) |
| 56421e9 | Stabilität (File-Locking, Throttling) |
| 50f3f53 | Slash-Kommandos (/verbose, /log, /status) |
| c56af14 | Python Logging |
| 9de2f75 | Config-Dir umbenannt |
| a61a532 | Konsistente Namensgebung |
Vorher: 5 Security-Patterns, kaputte Tests, Naming-Chaos. Nachher: 14 Security-Patterns, 70 Tests (alle grün), konsistente Namen.
Und ein paar neue Features obendrauf: Slash-Kommandos für /verbose, /log und /status. Wollte ich eh schon länger haben.
Das n+2-Augenprinzip
Das klassische Vier-Augen-Prinzip: Zwei Menschen schauen auf den Code. Gut, aber nicht immer verfügbar. Nicht jeder hat einen Kollegen, der Zeit für Reviews hat.
Mein Vorschlag: n+2.
- n ist die KI - sie findet strukturelle Probleme, Inkonsistenzen, offensichtliche Lücken
- +2 bin ich - ich entscheide, was davon relevant ist und was umgesetzt wird
Das ersetzt kein menschliches Review. Aber es filtert vor. Wenn ein Kollege dann draufschaut, kann er sich auf die interessanten Fragen konzentrieren: Architektur, Designentscheidungen, Wartbarkeit. Nicht auf kaputte Imports.
Wer das professioneller haben will: Es gibt dedizierte Tools dafür. CodeRabbit zum Beispiel integriert sich direkt in GitHub/GitLab und reviewt Pull Requests automatisch. Für Teams ist das vermutlich der bessere Weg als manuelles Prompting.
Für mich reicht erstmal Claude Code mit einem klaren Auftrag. Der Code ist jetzt besser, die Tests laufen, die Security ist robuster. Und nebenbei sind ein paar neue Features entstanden.
Disclaimer: Der Code ist ein Proof of Concept. Wer einen MCP-Server mit Shell-Zugriff betreibt, sollte wissen, was er tut.
GitHub: cuber-it/mcp_shell_tools
Tag vor den Fixes: v1.0-pre-review - für alle, die den Vorher-Nachher-Vergleich selbst machen wollen.