Reler e revisar código com um LLM local (revisão antes commit)

#Por que fazer revisão de código localmente

Colar um diff no ChatGPT para revisão é cômodo — até o dia em que esse diff contém uma chave de API, a lógica de negócio de um concorrente ou código coberto por um NDA. A revisão de código por um LLM local resolve esse problema pela raiz: o modelo roda na sua máquina, o código nunca sai da porta 11434.

Código proprietário

Algoritmos internos, lógica de negócio, segredos de arquitetura: nada é enviado a terceiros que possam registrar esses dados ou usá-los para treinamento.

NDA e cláusulas de confidencialidade

Muitos contratos de clientes proíbem explicitamente o envio do código-fonte para um serviço externo. O uso local costuma ser a única opção em conformidade com esses contratos.

Nenhum custo recorrente

Sem cobrança por token. Você pode revisar cada commit, cada ramificação, sem monitorar um contador.

Funciona offline

Em um trem, em um local isolado da rede (air-gap), atrás de um proxy corporativo restritivo: a revisão continua disponível.

#O que um LLM detecta bem (e o que deixa passar)

Antes de conectar qualquer coisa, é preciso ajustar suas expectativas. Um modelo de código local lida bem com erros locais identificáveis no diff, mas tem dificuldade com tudo o que exige conhecimento do restante do sistema.

Bom desempenho: bugs locais

Erro de uma unidade (off-by-one), condição invertida, variável não inicializada, recurso não fechado, falta de tratamento de erros.

Bom: falhas evidentes

Injeção SQL por concatenação, segredo fixado no código, caminho não validado, desserialização perigosa, XSS básico.

Bom desempenho: legibilidade

Nomes confusos, função muito longa, código morto, duplicação visível no diff.

Baixa: lógica entre arquivos

Ele só vê o diff. Um contrato de API quebrado em outro lugar, uma invariante global ou um efeito colateral distante passam despercebidos por ele.

Fraco: compreensão da intenção de negócio

Ele não sabe o que o código deveria fazer. Ele indica o plausível, não necessariamente o correto.

Risco: falsos positivos e alucinações

Pode inventar uma falha inexistente ou propor uma correção que comprometa o comportamento. Tudo deve ser verificado.

#Pré-requisitos

Ollama instalado

O daemon escuta por padrão em http://localhost:11434. Se você ainda não instalou o Ollama, consulte o guia de instalação do Ollama.

Um repositório Git

A revisão se baseia em git diff, portanto exige um projeto versionado com alterações a revisar.

Um modelo de código

Um modelo orientado para código baixado localmente (ver a seção seguinte para a escolha de acordo com sua VRAM).

GPU recomendada

Opcional, mas torna o uso mais confortável: uma RTX 3060 de 12 GB é suficiente para um modelo de 8-9B em Q4. Usar apenas a CPU também funciona, mas é mais lento.

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

#Quais modelos locais usar para revisar código

Para revisão de código, prefira um modelo especializado em código em vez de um generalista: ele entende melhor a sintaxe, os padrões idiomáticos e as armadilhas de cada linguagem. O tamanho é escolhido com base na sua VRAM, em Q4_K_M (o melhor equilíbrio entre qualidade e memória). As tags abaixo são da geração 2026, verificadas na biblioteca Ollama.

qwen3.5:9b — ~7 GB VRAM

A opção de entrada para 2026. Rápido, 256k de contexto, roda em uma RTX 3060 de 12 GB ou em um Mac de entrada da série M. Bom para revisar pequenos diffs.

devstral:24b — ~14 GB VRAM

O ponto ideal para a maioria das máquinas. Especialista em código e edição por agentes (Mistral AI, Apache 2.0), com melhor raciocínio sobre bugs sutis, cabe em uma RTX 4080 de 16 GB.

qwen3-coder:30b — ~19 GB VRAM

MoE de código (30B, 3B ativos), 256k de contexto, muito rápido. Qualidade significativamente superior no raciocínio entre funções. Exige uma RTX 4090 de 24 GB ou um Mac com ampla memória unificada.

Alternativas

gpt-oss:20b (da OpenAI, com pesos abertos, muito rápido) e glm-4.7-flash (MoE sob licença MIT, sólido em modo agente) são boas opções; mistral-small (24B, bom em francês) quebra um galho como generalista se você tiver apenas um modelo disponível.

#Revisão manual com um único comando

Antes de automatizar, comece com uma revisão manual sob demanda. A ideia: enviar o diff das suas alterações ainda não commitadas ao modelo pela API do Ollama e ler a resposta no terminal. Essa é a base do hook que configuraremos logo depois.

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

Torne o script executável (chmod +x review.sh), coloque suas alterações na área de preparação com git add e depois execute ./review.sh. Você receberá uma lista de observações que pode ignorar ou seguir. Nada impede você de prosseguir nesta etapa — é uma revisão assistida, não um fiscal.

#Configurar um hook pre-commit com Ollama, passo a passo

A próxima etapa: acionar essa revisão automaticamente a cada git commit, por meio de um hook pre-commit. Duas abordagens — um hook Git nativo (sem dependências) ou o framework pre-commit. Detalhamos o hook nativo, mais simples de entender e de auditar.

1. 01
   1. Criar o arquivo de hook

   Os hooks Git estão em .git/hooks/. Crie .git/hooks/pre-commit (sem extensão). O Git executa esse arquivo automaticamente antes de finalizar cada commit; um código de saída diferente de zero cancela o commit.
2. 02
   2. Escrever o script de revisão

   O hook obtém o diff das alterações preparadas para o commit, envia esse diff ao Ollama e exibe a resposta. Escolha: um modo puramente informativo (que nunca cancela o commit) ou um modo que bloqueia o commit quando o modelo emite uma palavra-chave de gravidade.
3. 03
   3. Tornar o hook executável

   chmod +x .git/hooks/pre-commit — sem isso, o Git o ignora silenciosamente.
4. 04
   4. Testar

   Faça um git add de um arquivo com um bug intencional, depois git commit. O hook deve exibir a observação do modelo antes de commitar.
5. 05
   5. Compartilhar com a equipe (opcional)

   Os hooks no diretório .git/hooks/ não são versionados. Para compartilhá-los, versione um diretório .githooks/ e configure com 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

#Aprimorar o prompt de revisão

A qualidade da revisão de código por LLM depende principalmente do prompt. Um modelo mal orientado encobre o que importa com observações de estilo desnecessárias. Três princípios tornam a saída utilizável.

Restringir o escopo

Peça explicitamente para ignorar o estilo e relatar apenas bugs, vulnerabilidades e casos-limite. Caso contrário, você recebe dez observações cosméticas por diff.

Impor um formato

Um formato estrito (- arquivo:linha — problema) torna a saída fácil de examinar rapidamente e de analisar automaticamente se você quiser aproveitá-la mais tarde.

Pedir um julgamento explícito

Uma linha final do tipo 'VERDICT: OK/REVOIR' dá um sinal binário simples para testar em um hook bloqueador.

Informar a linguagem e o contexto

Especifique a linguagem e, se útil, a convenção do projeto. O modelo adapta suas verificações (por exemplo, gerenciamento de memória em C, promises em JS).

#Uma visão honesta dos limites em comparação com a revisão humana

Sejamos claros sobre o que um revisor de código baseado em um LLM local não faz, para evitar uma falsa sensação de segurança — o pior resultado seria fazer commits com menos cautela por acreditar que você está protegido.

Visão limitada ao diff

Ele não conhece o restante do repositório. Uma mudança que quebra um chamador em outro arquivo passa despercebida. Os testes de integração permanecem indispensáveis.

Sem compreensão de negócio

Ele não sabe se o código faz o que o ticket pede. Ele valida a forma, não a intenção. Uma pessoa que conhece o produto continua insubstituível.

Falsos positivos e alucinações

Ele pode inventar uma vulnerabilidade ou uma correção errada. Cada observação deve ser verificada antes de agir — nunca faça correções às cegas.

Não substitui os linters nem os testes

Um linter, um verificador de tipos e um conjunto de testes capturam classes de erros de forma determinística. O LLM os complementa, não os substitui.

Depende do modelo e do prompt

Um modelo de 7B com um prompt mal formulado deixa passar coisas que um modelo de 32B bem orientado perceberia. A qualidade não é garantida nem reproduzível token por token.

#Para se aprofundar

Para saber mais sobre a escolha do modelo, a integração com o IDE ou a memória necessária, estes guias relacionados do site complementam este:

Melhor LLM local para codar em 2026

Comparativo detalhado entre Devstral, Qwen3-Coder e alternativas, com VRAM e velocidade por modelo.

Copilot gratuito executado localmente no VS Code

Ir além da revisão via CLI: chat e refactoring no IDE com Cline, Tabby e CodeGeeX.

Escolher sua quantização (Q4, Q5, Q8, FP16)

Entender por que o Q4_K_M é recomendado e como fazer um 32B caber em uma GPU de 16 GB.