Code mit einem lokalen LLM prüfen und überarbeiten (Review vor commit)

#Warum Code-Reviews lokal durchführen

Einen Diff zur Codeprüfung in ChatGPT einzufügen, ist bequem — bis dieser Diff eines Tages einen API-Schlüssel, die Geschäftslogik eines Konkurrenten oder Code enthält, der einer Geheimhaltungsvereinbarung (NDA) unterliegt. Die Codeprüfung mit einem lokalen LLM löst dieses Problem an der Wurzel: Das Modell läuft auf Ihrem Rechner, der Code verlässt niemals den Port 11434.

Proprietärer Code

Eigene Algorithmen, Geschäftslogik, Architektur-Geheimnisse: Nichts davon gelangt an Dritte, die es protokollieren oder zum Training verwenden könnten.

NDA und Vertraulichkeitsklauseln

Viele Kundenverträge verbieten explizit die Übermittlung des Quellcodes an einen externen Dienst. Der lokale Betrieb ist oft der einzige zulässige Ansatz.

Keine laufenden Kosten

Keine Abrechnung pro Token. Sie können jeden Commit und jeden Branch prüfen, ohne einen Zähler im Blick behalten zu müssen.

Offline-Funktionalität

Im Zug, an einem vom Netz isolierten Standort, hinter einem abgeschotteten Unternehmensproxy: Die Codeprüfung bleibt verfügbar.

#Was ein LLM gut erkennen kann (und was es verpasst)

Bevor Sie irgendetwas anbinden, sollten Sie Ihre Erwartungen realistisch einschätzen. Ein lokales Codemodell ist gut darin, lokale Fehler zu erkennen, die im Diff sichtbar sind, aber schwach bei allem, was Kenntnisse über den Rest des Systems erfordert.

Gut: lokale Bugs

Off-by-one, umgekehrte Bedingung, nicht initialisierte Variable, Ressource nicht geschlossen, Fehlerbehandlung vergessen.

Gut: offensichtliche Schwachstellen

SQL-Injection durch Verkettung, ein fest im Code hinterlegtes Geheimnis, ein nicht validierter Pfad, gefährliche Deserialisierung, einfache XSS-Angriffe.

Gut: Lesbarkeit

Unklare Benennung, zu lange Funktion, toter Code, im Diff sichtbare Duplikation.

Schwach: dateiübergreifende Logik

Er sieht nur den Diff. Ein an anderer Stelle verletzter API-Vertrag, eine globale Invariante und ein entfernter Nebeneffekt entgehen ihm.

Schwach: fachliche Zielsetzung

Er weiß nicht, was der Code tun soll. Er meldet Plausibles, nicht unbedingt Richtiges.

Risiko: Falschpositive und Halluzinationen

Es kann eine nicht vorhandene Sicherheitslücke erfinden oder eine Korrektur vorschlagen, die das Verhalten des Codes fehlerhaft verändert. Alles muss überprüft werden.

#Voraussetzungen

Ollama installiert

Der Daemon lauscht standardmäßig auf http://localhost:11434. Falls Ollama noch nicht installiert ist, siehe den Leitfaden zur Installation von Ollama.

Ein Git-Repository

Die Codeprüfung basiert auf git diff und setzt daher ein versioniertes Projekt mit Änderungen voraus, die geprüft werden sollen.

Ein Code-Modell

Ein auf Code ausgerichtetes Modell, das lokal heruntergeladen wurde (zur Auswahl entsprechend Ihrem VRAM siehe den folgenden Abschnitt).

GPU empfohlen

Optional, aber komfortabel: Eine RTX 3060 mit 12 GB reicht für ein 8–9B-Modell in Q4 aus. Der Betrieb allein auf der CPU funktioniert ebenfalls, ist aber langsamer.

# Le daemon répond ?
curl http://localhost:11434/api/tags

# Télécharger un modèle récent (exemple 9B)
ollama pull qwen3.5:9b

# Test rapide
ollama run qwen3.5:9b "Relis ce code : def add(a,b): return a-b"

#Welche lokalen Modelle eignen sich zur Codeprüfung?

Bevorzugen Sie für die Codeüberprüfung ein auf Code spezialisiertes Modell gegenüber einem allgemeinen Modell: Es versteht die Syntax, Idiome und Fallstricke der jeweiligen Sprache besser. Wählen Sie die Größe passend zu Ihrem VRAM, mit Q4_K_M als Quantisierung (der beste Kompromiss zwischen Qualität und Speicherbedarf). Die folgenden Tags gehören zur Generation 2026 und wurden anhand der Ollama-Modellbibliothek überprüft.

qwen3.5:9b — ~7 GB VRAM

Der Einstieg für 2026. Schnell, 256k Kontext, läuft auf einer RTX 3060 mit 12 GB oder einem Einstiegs-Mac der M-Serie. Gut für die Prüfung kleiner Diffs.

devstral:24b — ~14 GB VRAM

Die optimale Wahl für die meisten Rechner. Spezialist für Code und agentengestützte Bearbeitung (Mistral AI, Apache 2.0), besseres Schlussfolgern bei subtilen Bugs, passt auf eine RTX 4080 mit 16 GB.

qwen3-coder:30b — ~19 GB VRAM

MoE-Modell für Code (30B, davon 3B aktiv), 256k Kontext, sehr schnell. Deutlich höhere Qualität beim Schlussfolgern über mehrere Funktionen hinweg. Erfordert eine RTX 4090 mit 24 GB oder einen Mac mit reichlich gemeinsamem Arbeitsspeicher.

Alternativen

gpt-oss:20b (OpenAI open-weight, sehr schnell) und glm-4.7-flash (MoE MIT, solide im Agentenmodus) sind gute Optionen; mistral-small (24B, gut auf Französisch) dient als Generalist, wenn nur ein Modell zur Verfügung steht.

#Manuelle Codeprüfung mit einem einzigen Befehl

Bevor Sie automatisieren, beginnen Sie mit einer manuellen Prüfung bei Bedarf. Die Idee: den Diff Ihrer noch nicht committeten Änderungen über die Ollama-API an das Modell senden und dessen Rückmeldung im Terminal lesen. Das ist der Grundbaustein des Hooks, den wir unmittelbar danach einrichten.

#!/usr/bin/env bash
# review.sh — relit les changements indexés (staged)
set -euo pipefail

DIFF=$(git diff --cached)
if [ -z "$DIFF" ]; then
  echo "Rien d'indexé à relire (git add d'abord)."
  exit 0
fi

PROMPT="Tu es un relecteur de code senior. Analyse ce diff Git et liste \
UNIQUEMENT les vrais problèmes (bugs, failles, cas limites). Format : \
- [gravité] fichier:ligne — problème puis correctif suggéré. \
Si le diff est correct, réponds 'RAS'. Diff :\n\n$DIFF"

jq -n --arg m "devstral:24b" --arg p "$PROMPT" \
  '{model:$m, prompt:$p, stream:false}' \
| curl -s http://localhost:11434/api/generate -d @- \
| jq -r '.response'

Machen Sie das Skript ausführbar (chmod +x review.sh), nehmen Sie Ihre Änderungen mit git add in den Index auf und führen Sie anschließend ./review.sh aus. Sie erhalten eine Liste von Anmerkungen, die Sie nach Belieben ignorieren oder berücksichtigen können. In dieser Phase wird nichts blockiert – es handelt sich um eine assistierte Code-Review, nicht um einen Wächter.

#Einen pre-commit-Hook mit Ollama Schritt für Schritt einrichten

Der nächste Schritt: Diese Überprüfung bei jedem git commit automatisch über einen pre-commit-Hook auslösen. Es gibt zwei Ansätze – einen nativen Git-Hook (ohne Abhängigkeiten) oder das Framework pre-commit. Wir erläutern den nativen Hook, der einfacher zu verstehen und zu prüfen ist.

1. 01
   1. Die Hook-Datei erstellen

   Git-Hooks befinden sich in .git/hooks/. Erstellen Sie .git/hooks/pre-commit (ohne Dateiendung). Git führt diesen Hook automatisch aus, bevor ein Commit abgeschlossen wird; ein Exit-Code ungleich null bricht den Commit ab.
2. 02
   2. Das Skript für die Code-Review schreiben

   Der Hook ruft den Diff der Änderungen im Git-Index ab, sendet ihn an Ollama und zeigt die Rückmeldung an. Wählen Sie: entweder rein informativ (verhindert niemals den Commit) oder blockierend, wenn das Modell ein Schlüsselwort ausgibt, das den Schweregrad angibt.
3. 03
   3. Den Hook ausführbar machen

   chmod +x .git/hooks/pre-commit — andernfalls ignoriert Git das Skript ohne Meldung.
4. 04
   4. Testen

   Fügen Sie mit git add eine Datei mit einem absichtlich eingebauten Bug hinzu und führen Sie anschließend git commit aus. Der Hook muss den Hinweis des Modells anzeigen, bevor der Commit erfolgt.
5. 05
   5. Mit dem Team teilen (optional)

   Die Hooks in .git/hooks/ werden nicht versioniert. Um sie zu teilen, versionieren Sie einen Ordner .githooks/ und verweisen Sie mit git config core.hooksPath .githooks darauf.

#!/usr/bin/env bash
# Revue LLM locale avant commit. Informatif par défaut.
set -euo pipefail

MODEL="devstral:24b"
DIFF=$(git diff --cached --diff-filter=ACM)
[ -z "$DIFF" ] && exit 0

PROMPT="Relecteur senior. Liste seulement les vrais bugs, failles ou cas \
limites de ce diff, format '- fichier:ligne — souci'. Termine par la ligne \
'VERDICT: OK' si rien de bloquant, sinon 'VERDICT: REVOIR'. Diff:\n\n$DIFF"

OUT=$(jq -n --arg m "$MODEL" --arg p "$PROMPT" \
  '{model:$m, prompt:$p, stream:false}' \
  | curl -s http://localhost:11434/api/generate -d @- \
  | jq -r '.response')

echo "────── Revue LLM locale ──────"
echo "$OUT"
echo "──────────────────────────────"

# Mode bloquant optionnel : décommentez pour refuser le commit
# if echo "$OUT" | grep -q 'VERDICT: REVOIR'; then
#   echo "Commit bloqué. Corrigez ou 'git commit --no-verify' pour forcer."
#   exit 1
# fi
exit 0

repos:
  - repo: local
    hooks:
      - id: revue-llm-locale
        name: Revue de code LLM locale (Ollama)
        entry: ./scripts/review.sh
        language: system
        stages: [pre-commit]
        pass_filenames: false

#Den Review-Prompt sorgfältig formulieren

Die Qualität einer Codeüberprüfung durch ein LLM hängt vor allem vom Prompt ab. Ein Modell mit unklaren Vorgaben lässt die wichtigen Hinweise in unnötigen Anmerkungen zum Stil untergehen. Drei Prinzipien machen die Ausgabe nutzbar.

Den Umfang eingrenzen

Bitten Sie ausdrücklich darum, den Stil zu ignorieren und nur Bugs, Sicherheitslücken und Grenzfälle zu melden. Andernfalls erhalten Sie zehn kosmetische Anmerkungen pro Diff.

Format festlegen

Ein striktes Format (- Datei:Zeile — Problem) macht die Ausgabe leicht überfliegbar und maschinell auswertbar, falls Sie sie später weiterverwenden möchten.

Ein explizites Urteil anfordern

Eine letzte Zeile im Format 'VERDICT: OK/REVOIR' liefert ein einfaches binäres Signal, das in einem blockierenden Hook getestet werden kann.

Sprache und Kontext angeben

Geben Sie die Sprache und gegebenenfalls die Projektkonvention an. Das Modell passt seine Prüfungen an (z. B. Speichermanagement in C, Promises in JS).

#Grenzen im Vergleich zur menschlichen Codeprüfung – ehrlich betrachtet

Machen wir uns klar, was ein lokales LLM bei der Codeprüfung nicht leistet, um ein falsches Sicherheitsgefühl zu vermeiden – das schlimmste Ergebnis wäre, beim Committen weniger vorsichtig zu sein, weil man glaubt, abgesichert zu sein.

Einblick auf den Diff beschränkt

Es kennt den Rest des Repositorys nicht. Eine Änderung, durch die aufrufender Code in einer anderen Datei nicht mehr funktioniert, bleibt unbemerkt. Integrationstests bleiben unverzichtbar.

Kein Verständnis der fachlichen Anforderungen

Er weiß nicht, ob der Code das tut, was das Ticket verlangt. Er prüft die Form, nicht die Absicht. Ein Mensch, der das Produkt kennt, bleibt unersetzbar.

Falschpositive und Halluzinationen

Es kann eine Schwachstelle erfinden oder einen fehlerhaften Fix vorschlagen. Jeder Hinweis muss überprüft werden, bevor Sie handeln — nehmen Sie niemals blind Korrekturen vor.

Ersetzt weder Linter noch Tests

Ein Linter, ein Typ-Checker und eine Testsuite erkennen bestimmte Fehlerklassen deterministisch. Das LLM ergänzt sie, ersetzt sie aber nicht.

Abhängig vom Modell und vom Prompt

Ein 7B-Modell mit einem schlechten Prompt übersieht Dinge, die ein 32B-Modell mit klaren Vorgaben erkennen würde. Die Qualität ist weder garantiert noch bis auf das einzelne Token reproduzierbar.

#Weiterführende Informationen

Diese weiterführenden Leitfäden der Website ergänzen den vorliegenden Leitfaden und vertiefen die Modellwahl, die IDE-Integration oder den benötigten Speicher:

Bestes lokales LLM zum Coden 2026

Detaillierter Vergleich zwischen Devstral, Qwen3-Coder und Alternativen, mit VRAM und Geschwindigkeit pro Modell.

Kostenloser Copilot lokal in VS Code

Über die Codeprüfung in der CLI hinausgehen: Chat und Refactoring in der IDE mit Cline, Tabby und CodeGeeX.

Quantisierung wählen (Q4, Q5, Q8, FP16)

Verstehen, warum Q4_K_M empfohlen wird und wie sich ein 32B-Modell auf einer GPU mit 16 GB unterbringen lässt.