Rileggere e revisionare il codice con un LLM locale (revisione prima del commit)

#Perché fare la revisione del codice localmente

Incollare un diff in ChatGPT per farlo revisionare è comodo — fino al giorno in cui quel diff contiene una chiave API, la logica di business di un concorrente o del codice coperto da un NDA. La revisione del codice con un LLM locale risolve questo problema alla radice: il modello gira sulla tua macchina, il codice non esce mai dalla porta 11434.

Codice proprietario

Algoritmi interni, logica aziendale, segreti dell'architettura: nulla viene inviato a terzi che potrebbero registrarlo o usarlo per addestrare un modello.

NDA e clausole di riservatezza

Molti contratti con i clienti vietano esplicitamente di inviare il codice sorgente a un servizio esterno. L'esecuzione in locale è spesso l'unica scelta conforme.

Nessun costo ricorrente

Nessuna fatturazione per token. Puoi rileggere ogni commit, ogni ramo, senza monitorare un contatore.

Funziona offline

In treno, in un sito isolato dalla rete (air-gap), dietro un proxy aziendale con restrizioni di accesso: la revisione resta disponibile.

#Cosa rileva bene un LLM (e cosa gli sfugge)

Prima di collegare qualsiasi cosa, bisogna stabilire le aspettative. Un modello di codice locale funziona bene sugli errori locali e leggibili nel diff, ma è debole su tutto ciò che richiede di conoscere il resto del sistema.

Buoni risultati: bug locali

Off-by-one, condizione invertita, variabile non inizializzata, risorsa non chiusa, gestione degli errori dimenticata.

Bene: vulnerabilità evidenti

Iniezione SQL tramite concatenazione, segreto scritto direttamente nel codice, percorso non validato, deserializzazione pericolosa, XSS di base.

Bene: leggibilità

Nomi poco chiari, funzione troppo lunga, codice morto, duplicazione visibile nel diff.

Punto debole: logica tra file

Vede solo il diff. Un contratto API violato altrove, un'invariante globale o un effetto collaterale in un'altra parte del codice gli sfuggono.

Basso: intento di business

Non sa cosa il codice dovrebbe fare. Segnala elementi plausibili, non necessariamente corretti.

Rischio: falsi positivi e allucinazioni

Può inventare una vulnerabilità inesistente o proporre una correzione che compromette il comportamento del codice. Tutto deve essere verificato.

#Prerequisiti

Ollama installato

Il daemon è in ascolto per impostazione predefinita su http://localhost:11434. Se l'installazione non è ancora stata effettuata, consultare la guida all'installazione di Ollama.

Un repository Git

La revisione si basa su git diff: serve quindi un progetto sotto controllo di versione con modifiche da esaminare.

Un modello per il codice

Un modello orientato al codice scaricato in locale (vedi la sezione successiva per la scelta in base alla tua VRAM).

GPU consigliata

Opzionale ma comodo: una RTX 3060 da 12 GB basta per un modello 8-9B in Q4. Funziona anche con la sola CPU, ma più lentamente.

# 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"

#Quali modelli locali per rileggere del codice

Per la revisione del codice, preferisci un modello specializzato nel codice a uno generalista: comprende meglio la sintassi, gli idiomi e le insidie specifiche di ciascun linguaggio. Scegli la dimensione in base alla tua VRAM, in Q4_K_M (il miglior compromesso tra qualità e memoria). I tag qui sotto appartengono alla generazione 2026, verificata nella libreria Ollama.

qwen3.5:9b — ~7 GB VRAM

Il punto di partenza nel 2026. Veloce, 256k di contesto, funziona su una RTX 3060 da 12 GB o su un Mac M-series di base. Adatto alla revisione di piccoli diff.

devstral:24b — ~14 GB VRAM

Il miglior compromesso per la maggior parte delle postazioni. Specialista del codice e dell'editing tramite agenti (Mistral AI, Apache 2.0), ragiona meglio sui bug difficili da individuare e rientra nella memoria di una RTX 4080 da 16 GB.

qwen3-coder:30b — ~19 GB VRAM

MoE per il codice (30B, 3B attivi), 256k di contesto, molto veloce. Qualità nettamente superiore nel ragionamento tra funzioni. Richiede una RTX 4090 da 24 GB o un Mac con abbondante memoria unificata.

Alternative

gpt-oss:20b (open-weight di OpenAI, molto veloce) e glm-4.7-flash (MoE MIT, solido in modalità agente) sono buone opzioni; mistral-small (24B, buono in francese) può essere utile come modello generale se hai solo un modello a disposizione.

#Revisione manuale con un solo comando

Prima di automatizzare, inizia con una revisione manuale su richiesta. L'idea: inviare al modello, tramite l'API di Ollama, il diff delle tue modifiche non ancora incluse in un commit e leggere la sua risposta nel terminale. È l'elemento di base dell'hook che configureremo subito dopo.

#!/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'

Rendi eseguibile lo script (chmod +x review.sh), aggiungi le tue modifiche all'area di staging con git add, poi esegui ./review.sh. Ottieni un elenco di osservazioni che sei libero di ignorare o seguire. A questo punto nulla è bloccante — è una revisione assistita, non un controllo che impedisce di procedere.

#Configurare un hook pre-commit con Ollama, passo dopo passo

Il passo successivo: attivare automaticamente questa revisione a ogni git commit, tramite un hook pre-commit. Due approcci: un hook Git nativo (zero dipendenze) oppure il framework pre-commit. Descriviamo in dettaglio l'hook nativo, più semplice da capire e da verificare.

1. 01
   1. Creare il file di hook

   Gli hook di Git si trovano in .git/hooks/. Crea .git/hooks/pre-commit (senza estensione). Git lo esegue automaticamente prima di completare ogni commit; un codice di uscita diverso da zero annulla il commit.
2. 02
   2. Scrivere lo script di revisione

   L'hook recupera il diff delle modifiche nell'area di staging, lo invia a Ollama e mostra la risposta. Scegli: può essere puramente informativo (non annulla mai il commit) oppure bloccare il commit in base a una parola chiave di gravità emessa dal modello.
3. 03
   3. Rendere il hook eseguibile

   chmod +x .git/hooks/pre-commit — altrimenti Git lo ignora in silenzio.
4. 04
   4. Testare

   Esegui git add su un file con un bug inserito intenzionalmente, poi git commit. L'hook deve mostrare l'osservazione del modello prima di effettuare il commit.
5. 05
   5. Condividere con il team (opzionale)

   Gli hook nella cartella .git/hooks/ non sono versionati. Per condividerli, metti sotto controllo di versione una cartella .githooks/ e configura Git affinché la utilizzi con git config core.hooksPath .githooks.

#!/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

#Curare il prompt di revisione

La qualità della revisione del codice con un LLM dipende soprattutto dal prompt. Un modello a cui non vengono date indicazioni adeguate sommerge le informazioni rilevanti sotto osservazioni di stile inutili. Tre principi rendono l'output utilizzabile.

Restringere l'ambito

Chiedi esplicitamente di ignorare lo stile e di segnalare solo bug, vulnerabilità e casi limite. Altrimenti ottieni dieci osservazioni cosmetiche per diff.

Imporre un formato

Un formato rigoroso (- file:riga — problema) rende l'output facile da scorrere e analizzabile automaticamente, se vuoi utilizzarlo in seguito.

Chiedere un giudizio esplicito

Una riga finale del tipo 'VERDICT: OK/REVOIR' fornisce un segnale binario semplice da testare in un hook bloccante.

Indicare il linguaggio e il contesto

Specifica il linguaggio e, se utile, la convenzione del progetto. Il modello adatta le sue verifiche (ad es. gestione della memoria in C, promise in JS).

#Limiti rispetto alla revisione umana: una valutazione onesta

Chiariamo ciò che un LLM locale usato per la revisione del codice non fa, per evitare un falso senso di sicurezza — il risultato peggiore sarebbe effettuare commit con meno prudenza credendo di essere tutelati.

Visione limitata al diff

Non conosce il resto del repository. Un cambiamento che rompe un chiamante in un altro file passa inosservato. I test di integrazione rimangono indispensabili.

Nessuna comprensione del contesto aziendale

Non sa se il codice fa ciò che chiede il ticket. Controlla la forma, non l'intenzione. Una persona che conosce il prodotto rimane insostituibile.

Falsi positivi e allucinazioni

Può inventare una vulnerabilità o una correzione errata. Ogni osservazione deve essere verificata prima di agire — non correggere mai alla cieca.

Non sostituisce i linter e i test

Un linter, un type-checker e una suite di test individuano categorie di errori in modo deterministico. L'LLM integra questi strumenti, non li sostituisce.

Dipende dal modello e dal prompt

Un modello 7B con un prompt formulato male non coglie aspetti che un modello 32B ben guidato individuerebbe. La qualità non è garantita né riproducibile token per token.

#Per approfondire

Per approfondire la scelta del modello, l'integrazione con l'IDE o la memoria necessaria, queste guide correlate del sito completano questa guida:

Miglior LLM locale per la programmazione nel 2026

Confronto dettagliato tra Devstral, Qwen3-Coder e alternative, con VRAM e velocità per modello.

Copilot gratuito in locale in VS Code

Andare oltre la revisione in CLI: chat e refactoring nell'IDE con Cline, Tabby e CodeGeeX.

Scegliere la quantizzazione (Q4, Q5, Q8, FP16)

Capire perché il Q4_K_M è consigliato e come far stare un 32B su una GPU da 16 GB.