Intermedio 12 minDesarrollo

Releer y revisar código con un LLM local (revisión antes de commit)

La revisión de código con un LLM local te proporciona un primer revisor automático —errores, casos límite, vulnerabilidades evidentes— sin enviar nunca tu código propietario a la nube. Esta guía muestra cómo conectar un modelo Ollama a tu diff de Git, configurar un hook pre-commit que comente tus cambios antes de cada commit y, sobre todo, dónde están los límites de sus capacidades frente a una verdadera revisión humana.

Por Mohamed Meguedmi·Actualización 2026-08-27·Probado en Windows, macOS y Linux

#¿Por qué revisar el código localmente?

Pegar un diff en ChatGPT para que te lo revisen es cómodo, hasta el día en que ese diff contiene una clave de API, la lógica de negocio de un competidor o código cubierto por un NDA. La revisión de código con un LLM local soluciona este problema de raíz: el modelo se ejecuta en tu máquina y el código nunca abandona el puerto 11434.

Código propietario
Algoritmos propios, lógica de negocio, secretos de arquitectura: nada se envía a un tercero que podría registrarlo o utilizarlo para entrenar un modelo.
NDA y cláusulas de confidencialidad
Muchos contratos de clientes prohíben explícitamente enviar el código fuente a un servicio externo. La ejecución local suele ser la única opción que cumple esas condiciones.
Cero costo recurrente
Sin facturación por token. Puedes revisar cada commit, cada rama, sin tener que monitorear un contador.
Funciona offline
En un tren, en un sitio con aislamiento de red, detrás de un proxy empresarial cerrado: la revisión sigue disponible.
i
Un complemento, no un reemplazo
Un LLM local es excelente para una primera revisión: detecta los errores triviales antes de que lleguen a un compañero. No sustituye la revisión humana ni los linters; considéralo un filtro que ahorra tiempo a los revisores al detectar errores simples.

#Lo que un LLM detecta bien (y lo que se le escapa)

El kit de IA Local

Tu ChatGPT privado y gratuito en tu máquina en 1 hora — LM Studio, Ollama, Open WebUI, tus documentos, sin nube.

  • Espacio en línea de por vida
  • PDF + archivos
  • Reembolsado 30 j
El kit de IA Local →o todos los kits de por vida — 49 € →

Antes de conectar nada, hay que ajustar tus expectativas. Un modelo de código local detecta bien los errores locales que se aprecian en el diff, pero tiene dificultades con todo lo que requiere conocer el resto del sistema.

Bien: errores locales
Error de desfase de una unidad (off-by-one), condición invertida, variable no inicializada, recurso no cerrado, falta de gestión de errores.
Bien: vulnerabilidades evidentes
Inyección SQL por concatenación, secreto incrustado en el código, ruta no validada, deserialización peligrosa, XSS básico.
Bien: legibilidad
Nombres confusos, función demasiado larga, código muerto, duplicación visible en el diff.
Baja: lógica entre archivos
Solo ve el diff. Un contrato de API roto en otro lugar, un invariante global, un efecto secundario lejano le escapan.
Bajo: intención empresarial
No sabe qué debe hacer el código. Indica lo plausible, no necesariamente lo correcto.
Riesgo: falsos positivos y alucinaciones
Puede inventar una vulnerabilidad inexistente o proponer un parche que altere el comportamiento y provoque fallos. Todo debe verificarse.

#Prerrequisitos

Ollama instalado
El daemon escucha por defecto en http://localhost:11434. Si aún no está instalado, consultar la guía de instalación de Ollama.
Un repositorio de Git
La revisión se basa en git diff, por lo que requiere un proyecto bajo control de versiones con cambios que revisar.
Un modelo de código
Un modelo orientado al código descargado localmente (ver la sección siguiente para elegir según tu VRAM).
GPU recomendado
Opcional, pero cómodo: una RTX 3060 de 12 GB es suficiente para un modelo de 8-9B en Q4. También funciona solo con CPU, aunque más despacio.
Terminal — verificar la pila
# 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"

#¿Qué modelos locales usar para revisar código?

Para la revisión de código, opta por un modelo especializado en código en lugar de uno generalista: entiende mejor la sintaxis, los patrones idiomáticos y las trampas de cada lenguaje. El tamaño se elige según tu VRAM, en Q4_K_M (el mejor equilibrio entre calidad y memoria). Las etiquetas que aparecen a continuación corresponden a la generación 2026, verificada en la biblioteca de Ollama.

qwen3.5:9b — ~7 GB VRAM
El punto de entrada 2026. Rápido, 256k de contexto, funciona en una RTX 3060 de 12 GB o en un Mac M-series de entrada. Bueno para revisar pequeños diffs.
devstral:24b — ~14 GB VRAM
La opción ideal para la mayoría de los equipos. Especialista en código y edición mediante agentes (Mistral AI, Apache 2.0), con mejor razonamiento sobre errores sutiles; cabe en una RTX 4080 de 16 GB.
qwen3-coder:30b — ~19 GB VRAM
MoE para código (30B, 3B activos), 256k de contexto, muy rápido. Calidad claramente superior en el razonamiento entre funciones. Requiere una RTX 4090 de 24 GB o un Mac con una amplia capacidad de memoria unificada.
Alternativas
gpt-oss:20b (de OpenAI, con pesos abiertos, muy rápido) y glm-4.7-flash (MoE con licencia MIT, sólido en modo agente) son buenas opciones; mistral-small (24B, bueno en francés) sirve como generalista si solo tienes un modelo disponible.
→
Empieza con un modelo pequeño y pasa a uno más grande si hace falta
Un modelo de 9B ya detecta el 80 % de los errores obvios en una fracción de segundo. Elige un modelo de 30B solo si observas que el modelo pequeño no detecta errores que habrías querido que señalara.

#Revisión manual con un solo comando

Antes de automatizar, comienza por una revisión manual bajo demanda. La idea: enviar el diff de tus cambios aún no registrados en un commit al modelo a través de la API de Ollama y leer su respuesta en el terminal. Es la pieza básica del hook que instalaremos justo después.

Terminal — revisar el diff actual
#!/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'

Haz que el script sea ejecutable (chmod +x review.sh), añade tus cambios al área de preparación con git add y luego ejecuta ./review.sh. Obtienes una lista de comentarios que puedes ignorar o seguir. Nada bloquea el proceso en esta fase: es una revisión asistida, no un guardián.

#Instalar un hook pre-commit con Ollama, paso a paso

El siguiente paso: activar esta revisión automáticamente con cada git commit, mediante un hook pre-commit. Dos enfoques: un hook Git nativo (sin dependencias) o el framework pre-commit. Explicamos en detalle el hook nativo, más sencillo de entender y de auditar.

  1. 01
    1. Crear el archivo de hook
    Los hooks de Git están en .git/hooks/. Crea .git/hooks/pre-commit (sin extensión). Git lo ejecuta automáticamente antes de finalizar cada commit; un código de salida distinto de cero cancela el commit.
  2. 02
    2. Escribir el script de revisión
    El hook obtiene el diff de los cambios preparados para el commit, lo envía a Ollama y muestra la respuesta. Elige: que sea puramente informativo (nunca cancela el commit) o que bloquee el commit cuando el modelo emita una palabra clave que indique gravedad.
  3. 03
    3. Hacer ejecutable el hook
    chmod +x .git/hooks/pre-commit — sin esto, Git lo ignora silenciosamente.
  4. 04
    4. Probar
    Haz un git add de un archivo con un error intencional y luego git commit. El hook debe mostrar la observación del modelo antes de crear el commit.
  5. 05
    5. Compartir con el equipo (opcional)
    Los hooks en .git/hooks/ no están versionados. Para compartirlos, versiona un directorio .githooks/ y haz que Git apunte a él con git config core.hooksPath .githooks.
.git/hooks/pre-commit
#!/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
!
Bloqueante = fricción
Un hook que rechaza el commit ante cualquier observación del modelo pronto acabará eludiéndose con --no-verify, o incluso desinstalándose. Mantenlo informativo por defecto. Si haces que bloquee los commits, limita el bloqueo a categorías graves (secretos incrustados en el código, inyección), nunca a cuestiones de estilo.
i
Versión con el framework pre-commit
Si tu equipo ya utiliza la herramienta pre-commit (archivo .pre-commit-config.yaml), puedes declarar un hook local de tipo 'system' que llame al mismo script. Ventaja: configuración versionada y compartida. Desventaja: una dependencia adicional.
.pre-commit-config.yaml (extracto)
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

#Mejorar el prompt de revisión

La calidad de la revisión de código con un LLM depende sobre todo del prompt. Si no recibe instrucciones bien delimitadas, el modelo oculta lo relevante bajo comentarios de estilo innecesarios. Tres principios permiten obtener una salida aprovechable.

Restringir el alcance
Pide explícitamente que se ignore el estilo y que solo se señalen errores, vulnerabilidades y casos límite. De lo contrario, obtienes diez comentarios cosméticos por diff.
Imponer un formato
Un formato estricto (- archivo:línea — problema) permite leer la salida de un vistazo y procesarla automáticamente si quieres aprovecharla más adelante.
Pedir un veredicto explícito
Una línea final del tipo 'VERDICT: OK/REVOIR' proporciona una señal binaria fácil de comprobar en un hook bloqueante.
Indicar el lenguaje y el contexto
Especifica el lenguaje y, si resulta útil, la convención del proyecto. El modelo adapta sus comprobaciones (por ejemplo, gestión de memoria en C, promesas en JS).
→
Reducir falsos positivos
Añade al prompt: «En caso de duda, no señales nada». Esto orienta al modelo hacia la precisión en lugar de la exhaustividad, algo preferible para una herramienta que quieres que dé la alarma pocas veces, pero con motivo.

#Una visión honesta de las limitaciones frente a la revisión humana

Seamos claros sobre lo que no hace un revisor de código basado en un LLM local, para evitar una falsa sensación de seguridad: lo peor sería hacer commits con menos cuidado creyendo que estás protegido.

Visión limitada al diff
No conoce el resto del repositorio. Un cambio que rompe el código que hace una llamada desde otro archivo pasa desapercibido. Las pruebas de integración siguen siendo indispensables.
Sin comprensión de la lógica de negocio
No sabe si el código hace lo que pide el ticket. Valida la forma, no la intención. Un humano que conoce el producto sigue siendo irremplazable.
Falsos positivos y alucinaciones
Puede inventar una vulnerabilidad o una corrección errónea. Cada observación debe verificarse antes de actuar: nunca corrijas a ciegas.
No sustituye a los linters ni a los tests
Un linter, un verificador de tipos y un conjunto de pruebas detectan clases de errores de forma determinista. El LLM los complementa, no los sustituye.
Depende del modelo y del prompt
Un 7B con un prompt mal planteado pasa por alto cosas que un 32B bien orientado detectaría. La calidad no está garantizada ni es reproducible token por token.
!
No relajes la vigilancia
Un visto bueno del modelo no quiere decir «código correcto». Quiere decir «no se ha detectado nada evidente en este diff». Mantén la revisión humana en todo lo que concierne a seguridad, pagos, datos personales o lógica crítica.

#Para ir más allá

Para profundizar en la elección del modelo, la integración con el IDE o la memoria necesaria, estas guías relacionadas del sitio complementan esta guía:

Mejor LLM local para programar en 2026
Comparativa detallada entre Devstral, Qwen3-Coder y otras alternativas, con VRAM y velocidad por modelo.
Copilot gratuito en local en VS Code
Ir más allá de la revisión en CLI: chat y refactorización en el IDE con Cline, Tabby y CodeGeeX.
Elegir tu cuantización (Q4, Q5, Q8, FP16)
Entender por qué se recomienda Q4_K_M y cómo hacer que un modelo de 32B quepa en una GPU de 16 GB.
¿Esta guía te ha ayudado?

¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.