Automatisierung von Code-Reviews mit Tactic Remote

Code-Review ist essentiell für Softwarequalität, aber auch zeitaufwändig. Entwickler verbringen geschätzt 6-8 Stunden pro Woche mit der Überprüfung von Code der Kollegen — Zeit, die für den Bau von Features genutzt werden könnte. KI-gestütztes Code-Review ersetzt keine menschlichen Reviewer, aber es übernimmt die mechanischen Aspekte (Bugs finden, Stilverletzungen, fehlende Fehlerbehandlung), damit menschliche Reviewer sich auf Architektur, Design und Geschäftslogik konzentrieren können.

Dieses Tutorial zeigt, wie du einen KI-gestützten Code-Review-Workflow mit Tactic Remote einrichtest.

Der Review-Workflow

Hier ist der Workflow, den wir einrichten:

1. Ein Entwickler schließt die Arbeit an einem Feature-Branch ab.
2. Vor dem Erstellen eines Pull Requests startet er eine Claude Code-Review-Sitzung von seinem Telefon.
3. Claude Code analysiert den Diff gegen den Hauptbranch und erstellt ein umfassendes Review.
4. Der Entwickler behandelt die Befunde von seinem Telefon aus (genehmigt Korrekturen oder notiert Ausnahmen).
5. Der bereinigte Code wird gepusht und ein PR wird mit der KI-Review-Zusammenfassung erstellt.

Dies fängt 60-80% der Probleme ab, die sonst erst im menschlichen Review gefunden würden, und reduziert die Review-Zykluszeit dramatisch.

Schritt 1: Review-Prompt vorbereiten

Erstelle eine Datei namens .claude-review-prompt.md im Stammverzeichnis deines Projekts. Diese dient als Anweisungssatz für KI-Reviews:

# Code Review Instructions
 
Review all changes on the current branch compared to the `main` branch.
 
## What to Check
 
### Critical Issues (must fix before merge)
 
- **Logic errors**: Code that doesn't do what it claims
- **Security vulnerabilities**: SQL injection, XSS, auth bypasses, credential exposure
- **Data loss risks**: Missing transactions, incorrect cascade deletes, race conditions
- **Breaking changes**: API contract violations, backwards-incompatible modifications
 
### Warnings (should fix, but not blocking)
 
- **Missing error handling**: Uncaught exceptions, unhandled promise rejections
- **Performance concerns**: N+1 queries, unnecessary re-renders, missing memoization
- **Missing validation**: User input not validated before processing
- **Test coverage gaps**: New code paths without corresponding tests
 
### Suggestions (nice to have)
 
- **Readability improvements**: Unclear variable names, complex logic that could be simplified
- **Documentation gaps**: Public APIs without JSDoc/TSDoc comments
- **Potential refactoring**: Duplicated logic, overly long functions
 
## Output Format
 
For each finding, provide:
 
1. **Severity**: CRITICAL / WARNING / SUGGESTION
2. **File**: Exact file path and line numbers
3. **Description**: What the issue is, in one sentence
4. **Explanation**: Why it matters, with context
5. **Fix**: Concrete code suggestion to resolve the issue
 
At the end, provide:
 
- Summary: X critical, Y warnings, Z suggestions
- Overall assessment: Is this branch ready for human review?
 
## What NOT to Flag
 
- Style preferences covered by our linter (ESLint/Prettier handle this)
- Import ordering (automated)
- Whitespace or formatting (automated)
- Type annotations that TypeScript can infer

Dieser Prompt ist absichtlich spezifisch. Vage Review-Anweisungen produzieren vage Reviews. Spezifische Anweisungen produzieren umsetzbare Befunde.

Schritt 2: Review vom Telefon ausführen

Wenn du bereit bist, einen Branch zu reviewen, öffne Tactic Remote und starte eine Sitzung, die auf das Projektverzeichnis zeigt. Sende:

Checkout branch feature/user-dashboard.
Follow the review instructions in .claude-review-prompt.md.

Claude Code wird:

1. Den Branch auschecken
2. Den Diff gegen main berechnen
3. Jede geänderte Datei gemäß deiner Review-Kriterien analysieren
4. Einen strukturierten Review-Bericht ausgeben

Dies dauert typischerweise 3-8 Minuten je nach Größe des Diffs. Du erhältst eine Benachrichtigung, wenn es abgeschlossen ist.

Schritt 3: Befunde überprüfen

Die Review-Ausgabe erscheint in deiner Terminal-Ansicht. So sieht ein typischer Befund aus:

🔴 CRITICAL — src/api/routes/users.ts:47-52

Description: SQL query constructed with string concatenation, vulnerable to injection.

Explanation: The search query parameter is interpolated directly into the SQL
string without parameterization. An attacker could craft a search input that
modifies the query logic, potentially extracting or modifying data.

Fix: Use parameterized query:
  // Before (vulnerable)
  const results = db.query(`SELECT * FROM users WHERE name LIKE '%${search}%'`)

  // After (safe)
  const results = db.query('SELECT * FROM users WHERE name LIKE ?', [`%${search}%`])

Für jeden Befund hast du drei Optionen von deinem Telefon:

Korrektur anwenden: Weise Claude Code an, die vorgeschlagene Korrektur umzusetzen:

Apply the fix for the SQL injection issue in users.ts:47.

Überspringen: Wenn du mit dem Befund nicht einverstanden bist oder es ein False Positive ist, notiere es für später und mache weiter.

Diskutieren: Wenn du unsicher bist, frage Claude Code nach mehr Kontext:

Explain the SQL injection risk in more detail. Is this exploitable given
our authentication middleware that runs before this route?

Schritt 4: Automatisierte Korrekturanwendung

Bei Reviews mit vielen Befunden kannst du Korrekturen gebündelt anwenden:

Apply fixes for all CRITICAL and WARNING findings from the review.
For each fix, run the relevant tests to verify the fix doesn't break anything.
Report which fixes were applied and which tests passed.

Claude Code arbeitet die Befunde systematisch durch, wendet Korrekturen an und führt Tests aus. Das ist eine weitere Aufgabe, bei der du dein Telefon weglegen und auf die Benachrichtigung warten kannst.

Wichtig: Überprüfe die angewandten Korrekturen vor dem Commit. KI-generierte Korrekturen sind normalerweise korrekt, aber „normalerweise" reicht nicht für Produktionscode. Nutze die Terminal-Ansicht, um den Diff zu prüfen:

Show me the complete git diff of all changes made during this review.

Schritt 5: PR-Zusammenfassung generieren

Wenn Korrekturen angewendet und verifiziert sind, generiere eine PR-fertige Zusammenfassung:

Create a pull request description that includes:
1. What this branch does (based on the commit history)
2. Summary of the AI review findings and how they were addressed
3. Any remaining suggestions that were intentionally deferred
4. Test results

Füge dies in deine PR-Beschreibung ein. Es gibt menschlichen Reviewern das Vertrauen, dass der Code vorgeprüft wurde, und sagt ihnen, worauf sie sich konzentrieren sollen.

Fortgeschritten: Kontinuierliche Review-Sitzungen

Für langlebige Feature-Branches führe Reviews regelmäßig durch, nicht nur zum PR-Zeitpunkt:

Review all commits since the last review marker.
After completing the review, create a git tag 'last-ai-review' at HEAD.

Durch tägliche Reviews erkennst du Probleme näher am Zeitpunkt ihrer Entstehung. Das ist einfacher zu beheben als Probleme nach einer Woche Entwicklung zu entdecken.

Integration mit CI/CD

Für Teams, die KI-Review formalisieren möchten, kannst du eine Review-Sitzung automatisch auslösen, wenn ein Branch gepusht wird. Der Workflow:

1. CI-Webhook löst die Tactic Remote Mac-Begleit-App aus.
2. Die Begleit-App startet eine Claude Code-Sitzung auf dem aktualisierten Branch.
3. Claude Code führt den Review-Prompt aus.
4. Die Ergebnisse werden als Kommentar auf dem Pull Request gepostet.

Dies erfordert Scripting auf der Mac-Seite (die Begleit-App stellt eine API für Sitzungsverwaltung bereit) und wird in unserer fortgeschrittenen Integrationsdokumentation beschrieben.

Auswirkungsmessung

Nach der Einführung von KI-Code-Review verfolge diese Metriken:

• Zeit im Review: Sollte um 30-50% sinken, da menschliche Reviewer weniger Zeit für mechanische Prüfungen aufwenden.
• Im Review vs. in Produktion gefundene Probleme: Sollte sich nach links verschieben — mehr Probleme im KI-Review gefunden, weniger gelangen in die Produktion.
• Review-Zykluszeit: Die Zeit von PR-Erstellung bis Genehmigung sollte sinken, da PRs vorgeprüft ankommen.
• Entwicklerzufriedenheit: Reviewer sollten weniger Monotonie und mehr Fokus auf bedeutungsvolles architektonisches Feedback berichten.

KI-Code-Review geht nicht darum, menschliches Urteilsvermögen zu ersetzen. Es geht darum sicherzustellen, dass menschliches Urteilsvermögen für die Probleme eingesetzt wird, die am meisten zählen — Architektur, Design und Geschäftslogik — anstatt Tippfehler und fehlende Null-Checks zu finden.

Beginne mit einem einzelnen Projekt, verfeinere deinen Review-Prompt basierend auf Ergebnissen und erweitere auf das Team, sobald du den Ansatz kalibriert hast. Die Investition in einen guten Review-Prompt zahlt sich bei jedem Review aus, der ihn nutzt.