Cómo automatizamos el code review con worktrees, un .sh y MCPs — 95% de accuracy - 09/03/2026
Cómo combinamos git worktrees, un script de shell y servidores MCP de Jira y GitLab para automatizar el flujo de code review y lograr un 95% de accuracy.
En mi equipo logramos algo que muchos consideran difícil: hacer que el code review sea rápido, consistente y casi completamente automatizable, sin perder profundidad técnica. La clave fue combinar tres herramientas que, juntas, transformaron por completo cómo revisamos código.
El problema que teníamos
El flujo clásico de code review tiene fricciones que se acumulan:
- Cambiar de rama interrumpe el trabajo en curso.
- El contexto del reviewer se pierde cuando revisa múltiples MRs.
- Las revisiones manuales son inconsistentes: cada desarrollador prioriza cosas distintas.
- El tiempo entre “MR abierto” y “revisión completada” era demasiado largo.
El resultado: los code reviews se convertían en un cuello de botella, y los desarrolladores los evitaban o los aprobaban sin profundidad real.
La solución: Worktrees + Script .sh + MCPs especializados
1. Git Worktrees: espacios aislados sin cambiar de rama
La primera pieza fue adoptar git worktrees. En vez de hacer git checkout y perder el contexto del trabajo actual, creamos un directorio de trabajo paralelo para cada MR a revisar:
# Crear un worktree aislado para revisar un MR
git worktree add ../review-PCF-1539 feature/PCF-1539
# Revisar en ese directorio sin tocar el trabajo actual
cd ../review-PCF-1539
# Al terminar, limpiar
git worktree remove ../review-PCF-1539
Cada revisión ocurre en su propio espacio, completamente aislado. Sin stash, sin conflictos, sin interrupciones.
2. El script .sh: automatizar la preparación del contexto
Creamos un script de shell que, dado el número de MR o la rama, prepara automáticamente el entorno de revisión:
#!/bin/bash
# dod-review.sh — Prepara el entorno para revisar un MR
MR_BRANCH=$1
WORKTREE_PATH="../review-$(echo $MR_BRANCH | tr '/' '-')"
echo "🔧 Creando worktree para $MR_BRANCH..."
git worktree add "$WORKTREE_PATH" "$MR_BRANCH"
echo "📦 Instalando dependencias..."
cd "$WORKTREE_PATH" && npm install --silent
echo "✅ Entorno listo en $WORKTREE_PATH"
echo "🤖 Iniciando análisis con IA..."
En segundos, el reviewer tiene un entorno limpio con dependencias instaladas y listo para que la IA lo analice.
3. MCPs especializados: Jira y GitLab como fuentes de verdad
La pieza que lo cambió todo fueron los Model Context Protocol (MCP) servers de Jira y GitLab.
Con el MCP de GitLab, la IA puede:
- Leer el diff completo del MR
- Ver los comentarios existentes
- Consultar el historial de commits y su contexto
- Publicar comentarios de revisión directamente en el MR
Con el MCP de Jira, la IA puede:
- Leer los criterios de aceptación del ticket asociado
- Verificar que el código implementa exactamente lo especificado
- Detectar discrepancias entre el ticket y la implementación
// Ejemplo de flujo automatizado
1. Script detecta MR → crea worktree
2. IA lee ticket de Jira (via MCP) → extrae criterios de aceptación
3. IA lee diff de GitLab (via MCP) → analiza cambios
4. IA aplica skills de review → genera reporte
5. IA publica comentarios en el MR (via MCP)
Skills enfocadas en nuestro stack
Lo que hace que el 95% de accuracy sea posible son las skills especializadas. No usamos un prompt genérico de “revisa este código”. Tenemos skills definidas para nuestras tecnologías específicas:
- NestJS: revisa estructura de módulos, inyección de dependencias, validación de DTOs, manejo de excepciones.
- React + TypeScript: revisa tipos, composición de componentes, hooks personalizados, performance.
- Definition of Done del equipo: valida cobertura de tests, documentación, convenciones de naming, seguridad OWASP.
Cada skill es un conjunto de instrucciones precisas que la IA aplica sistemáticamente. Sin variabilidad humana. Sin olvidar chequear algo importante.
El resultado: qué cambió
| Antes | Después |
|---|---|
| Cambio de contexto al revisar | Worktree aislado, sin interrupciones |
| Reviews inconsistentes | Skills sistemáticas, mismo estándar siempre |
| Mucho tiempo en review manual | IA cubre el 95% en minutos |
| Developers evitaban revisar | Review es una tarea de minutos, no horas |
| Criterios subjetivos | Criterios objetivos del ticket de Jira |
El impacto más importante: el equipo se libera para concentrarse en lo que realmente importa — construir nuevas funcionalidades y resolver bugs reales — en vez de perder horas en revisiones mecánicas.
El 95% de accuracy no significa que la IA reemplaza al desarrollador. Significa que llega al 95% del análisis de forma automática y consistente, y el humano aporta el criterio final en el 5% que requiere juicio de dominio.
Muchas gracias por llegar hasta aquí y leer este artículo. Espero que te haya dado ideas para mejorar el flujo de code review en tu equipo.