Guía práctica: integrar un LLM en tu pipeline de CI/CD para revisión de código y generación de tests

Integrar un LLM en tu CI/CD no se trata de “reemplazar” revisores o QA: se trata de reducir tiempo de ciclo y aumentar cobertura con guardrails. Esta guía aterriza un enfoque práctico para (1) revisión de PR/MR y (2) generación de tests, sin romper el principio de seguridad: el modelo sugiere, tu pipeline decide.

1) Arquitectura recomendada: “LLM como asesor”

En lugar de darle al LLM llaves del repo o acceso directo a despliegues, úsalo como un paso de análisis que produce artefactos: comentarios de revisión, diffs sugeridos (no aplicados) y archivos de tests propuestos. Luego, validas con herramientas determinísticas (linters, SAST, tests, type-checking).

• Entrada mínima: diff + contexto acotado (archivos tocados, convenciones del repo, reglas de estilo).
• Salida controlada: JSON con findings + severidad + ubicaciones + sugerencias.
• Decisión: gates automáticos (falla si hay vulnerabilidades críticas o tests insuficientes).

2) Qué enviarle al modelo (y qué no)

Un LLM es sensible al contexto: demasiada info aumenta costo y riesgo; muy poca reduce calidad. Una plantilla de contexto útil incluye:

✅ Enviar
- Diff del PR/MR
- Lenguaje + framework (p.ej., Node + NestJS)
- Estándares: naming, lint, patrones del repo
- Objetivo del cambio (resumen del PR)

⛔ No enviar
- Secretos (tokens, claves)
- Archivos completos innecesarios
- Datos personales / logs con PII

Consejo: genera el “paquete de contexto” en el job del pipeline (script) y guárdalo como artefacto para auditoría.

3) Revisión automática de código: checklist y salida estructurada

Pídele al LLM revisar con un checklist que puedas mapear a severidad. Ejemplos:

• Correctitud: edge cases, nulos, errores, concurrencia.
• Seguridad: inyección, SSRF, authz, manejo de secretos, validación de entradas.
• Mantenibilidad: complejidad, duplicación, cohesión, nombres.
• Performance: N+1, loops, consultas, caché.

Para automatizar decisiones, pide una salida JSON (sin prosa) con campos fijos. Ejemplo de esquema:

{
  "summary": "...",
  "findings": [
    {
      "severity": "low|medium|high|critical",
      "type": "security|bug|maintainability|perf",
      "file": "src/...",
      "line_start": 10,
      "line_end": 24,
      "message": "...",
      "suggestion": "..."
    }
  ]
}

Luego, tu pipeline evalúa: si hay critical, falla el job; si hay high, requiere aprobación humana explícita.

4) Generación de tests: enfoque incremental

La forma más efectiva es pedir tests para el diff, no para todo el sistema. El prompt debería exigir:

• Tests unitarios de lógica nueva/alterada.
• Al menos 1 caso happy path y 1 caso edge/error.
• Mocks/stubs acordes al stack (sin inventar APIs).

Importante: el LLM puede proponer tests que compilan pero no asertan lo correcto. Por eso la regla de oro es: “tests generados deben fallar si el bug existe”. Puedes reforzarlo pidiendo aserciones específicas y nombres de test descriptivos.

5) CI/CD: ejemplo de gates (agnóstico al proveedor)

Un flujo típico con LLM queda así:

1. Build + lint + type-check (rápido, determinístico).
2. LLM review (produce JSON con findings).
3. LLM tests (genera archivos de test en un directorio temporal/artefacto).
4. Run tests (incluyendo los nuevos si decides aplicarlos vía patch controlado).
5. SAST/Dependency scan como backstop.

Para evitar que el modelo “rompa” la base de código, separa sugerencia de aplicación: el LLM produce un patch (diff) que se aplica solo si pasa validaciones (y preferiblemente en un job aislado).

6) Seguridad y riesgos: lo que debes cubrir sí o sí

7) Métricas para demostrar valor (y evitar hype)

• Lead time de PR: mediana y p95 antes/después.
• Defect leakage: bugs en producción por sprint.
• Cobertura efectiva: cobertura + tests útiles (mutación/branch).
• Costo: tokens/tiempo por PR, comparado con horas humanas ahorradas.

8) Plan de implementación en 2 semanas