Un loop autocorrectivo de agente en CI es el flujo donde una falla verificable vuelve a Codex, Claude Code u otro agente de código con contexto mínimo, alcance corto y regla de parada. El objetivo no es dejar que el agente mande en el pipeline. Es hacer que CI devuelva evidencia suficiente para una reparación pequeña y revisable.

En 2026, GitLab informó que 85% de los encuestados ve la revisión y la validación como el nuevo cuello de botella del código generado por IA (GitLab, "AI Accountability Report", 2026, consultado en 2026-07-08). Si el agente crea PRs más rápido, el pipeline necesita responder con evidencia, no con más conversación.

Resumen práctico

  • El loop debe recibir falla, log corto, comando y límite de intentos.
  • El agente solo debe tocar el menor alcance que explica la falla.
  • El PR necesita mostrar prueba, comando ejecutado y riesgo residual.
  • Si el segundo intento falla por la misma razón, llama a una persona.

Diagrama abstracto muestra un agente, un ciclo de validación y puntos de estado de CI sin texto visible.

¿Por qué el loop de reparación en CI se volvió urgente?

En 2026, GitLab midió 91% de organizaciones usando dos o más herramientas de IA para código y 78% reportando escritura y commits más rápidos (GitLab, "AI Accountability Report", 2026, consultado en 2026-07-08). La reparación en CI se volvió urgente porque la generación aceleró antes que la verificación.

El error común es tratar una falla de CI como un mensaje que una persona debe traducir manualmente. En un flujo agentic, la falla ya debe nacer como entrada de máquina: comando, extracto relevante del log, archivos tocados, frontera de alcance y motivo de bloqueo. Eso reduce la chance de que el agente intente "mejorar" áreas que no fallaron.

Este post continúa la línea de evals de PR para agentes en CI y de spec ejecutable para agentes de código. La diferencia es el momento: aquí el foco está después de la falla, cuando el pipeline debe devolver feedback que el agente pueda ejecutar.

Cápsula citable: Un loop autocorrectivo en CI responde al cuello de botella de validación. GitLab reportó 85% viendo revisión y validación como cuello de botella (GitLab, "AI Accountability Report", 2026); por eso, cada falla debe virar feedback estructurado, con comando, log mínimo, alcance y límite de intentos.

¿Cuál es el contrato mínimo de un loop autocorrectivo?

En 2026, DORA registró que 90% de los profesionales de tecnología usan IA en el trabajo y que más de 80% cree que aumentó su productividad (DORA, "Balancing AI tensions", 2026, consultado en 2026-07-08). El contrato mínimo existe para convertir esa productividad en cambio verificable.

Un buen loop tiene cinco campos. Primero, la falla que disparó el flujo. Segundo, el comando que reproduce la falla. Tercero, el alcance de archivos autorizado. Cuarto, el criterio de éxito. Quinto, la regla de parada. Sin eso, el agente recibe una excepción e inventa un proyecto.

falla:
  comando: "npm run test -- session-renewal"
  evidencia: ".ci/failures/session-renewal.log"
alcance_autorizado:
  - "src/auth/session.service.ts"
  - "tests/auth/session-renewal.spec.ts"
exito:
  - "el comando que falló vuelve a pasar"
  - "npm run typecheck sigue pasando"
limites:
  intentos: 2
  sin_migracion_de_base: true
  sin_cambio_en_secretos: true
parar_si:
  - "la misma falla aparece dos veces"
  - "el parche toca archivo fuera del alcance"
  - "la correccion exige secreto o acceso externo"

El contrato puede vivir en una issue, en un comentario de PR o en un artefacto generado por CI. El punto es no depender de la memoria del chat. Para flujos largos con Codex y Claude Code, uso RemoteCode para reducir contexto repetido en loops agentic de código porque es una herramienta mía y encaja directamente con este problema de costo y continuidad.

Experiencia práctica: cuando probé este patrón en tareas de backend, el loop solo fue útil después de que la falla empezó a cargar alcance y regla de parada. Antes de eso, el agente tendía a corregir síntomas cercanos y crear diffs que parecían buenos, pero eran difíciles de revisar.

Cápsula citable: El contrato mínimo de reparación tiene falla, comando, alcance, éxito y parada. DORA midió adopción de IA por 90% de profesionales (DORA, "Balancing AI tensions", 2026); sin contrato, esa adopción amplía productividad local y retrabajo en el pipeline.

¿Cómo entrega CI feedback útil sin volcar contexto?

En 2026, OpenAI documentó que codex exec ejecuta Codex en scripts y CI, con eventos JSON Lines para mensajes, comandos, cambios de archivo, llamadas MCP y fallas (OpenAI Developers, "Non-interactive mode", 2026, consultado en 2026-07-08). El feedback útil es pequeño, estructurado y legible por herramientas.

No envíes el log entero de un job largo. Envía el comando que falló, la cola relevante, el camino del reporte, el diff del PR y la política de alcance. El agente puede leer más si lo necesita, pero el primer paquete debe orientar, no ahogar.

Diagrama abstracto muestra señales de falla convertidas en feedback de reparación sin texto visible.

OpenAI también publicó un ejemplo de reparación iterativa con tres fases: revisión, reparación y validación (OpenAI Developers, "Build iterative repair loops with Codex", 2026, consultado en 2026-07-08). El detalle importante es la separación. Revisar no edita. Reparar no decide solo si terminó. Validar devuelve el delta restante.

{
  "comando": "npm run test -- session-renewal",
  "estado": "fallo",
  "archivo_log": ".ci/failures/session-renewal.log",
  "archivos_alterados": [
    "src/auth/session.service.ts",
    "tests/auth/session-renewal.spec.ts"
  ],
  "pedido": "aplica la menor correccion que haga pasar el comando"
}

Cápsula citable: El feedback de CI para un agente debe ser estructurado, no voluminoso. OpenAI documentó codex exec con salida JSON Lines; eso permite transformar fallas en eventos legibles por máquina, con comando, log, archivo alterado y próxima acción.

¿Dónde poner límites para que el agente no empeore el PR?

En 2026, la documentación de codex exec informa que el modo no interactivo corre en sandbox de solo lectura por defecto y recomienda workspace-write para permitir edición controlada (OpenAI Developers, "Non-interactive mode", 2026, consultado en 2026-07-08). El límite debe estar antes de que el agente edite, no después del daño.

Usa runner aislado, token corto, permisos mínimos y branch separada. En Codex, prefiere --sandbox workspace-write para reparaciones en repositorio y evita acceso amplio fuera de ambientes controlados. En Claude Code GitHub Actions, restringe herramientas, eventos y permisos del workflow al caso de uso real.

Diagrama abstracto muestra anillos de sandbox, puntos de parada y barreras de permiso sin texto visible.

La documentación de seguridad de Claude Code Action recomienda limitar herramientas permitidas y usar GITHUB_TOKEN con alcance cuando se autorizan usuarios sin permiso de escritura (Anthropic, "claude-code-action security", 2026, consultado en 2026-07-08). También alerta contra checkout de ref no confiable en el workspace antes de la action en flujos con pull_request_target o workflow_run.

Cápsula citable: El límite de un loop autocorrectivo debe ser preventivo. Codex usa sandbox de solo lectura por defecto en automatización, y Anthropic recomienda permisos mínimos en GitHub Action; juntos, esos controles impiden que una falla de prueba se vuelva cambio amplio.

¿Cómo prueba el PR que la reparación fue legítima?

En 2026, GitHub reportó que Copilot code review procesó más de 60 millones de revisiones. El mismo texto dice que más de una de cada cinco revisiones en GitHub involucra a un agente (GitHub, "Agent pull requests are everywhere", 2026, consultado en 2026-07-08). El PR necesita probar la reparación porque la revisión humana se volvió cuello de botella.

Pide evidencia corta en el cuerpo del PR. El agente debe mostrar el comando que falló, el comando que pasó, el resumen del parche, el riesgo residual y por qué no tocó áreas vecinas. Si la corrección cambió prueba e implementación, el orden importa: prueba que falla, parche, prueba que pasa.

Evidencia en el PR Quién valida Bloquea cuando
Comando que falló CI No hay reproducción clara.
Parche pequeño Revisor Un archivo fuera del alcance cambió sin justificación.
Verificación posparche Branch protection Prueba, typecheck o build falla.
Riesgo residual Code owner Área sensible cambió sin dueño.
Intentos usados Automatización El límite fue excedido.

OpenAI mostró en un ejemplo de tarea larga que Codex ejecutó comandos de lint, typecheck, pruebas, build y exportación durante hitos de verificación (OpenAI Developers, "Run long horizon tasks with Codex", 2026, consultado en 2026-07-08). Ese es el patrón: la narrativa solo vale si viene con verificación.

Ese cuidado también responde a un riesgo de mantenimiento. En 2026, el estudio "More Code, Less Reuse" encontró que los agentes tienden a perder oportunidades de reúso e introducir más redundancia en PRs generados por IA (arXiv, "More Code, Less Reuse", 2026, consultado en 2026-07-08).

Cápsula citable: Un PR de reparación agentic necesita mostrar prueba, no confianza. GitHub reportó más de 60 millones de revisiones con Copilot code review (GitHub, "Agent pull requests are everywhere", 2026); a ese volumen, comando reproducido, parche pequeño y verificación posparche son el lenguaje común entre agente, CI y revisor.

¿Cuándo parar el loop y llamar a una persona?

En 2026, GitLab informó que 92% enfrenta algún desafío de gobernanza con código generado por IA. El mismo informe dice que 80% adoptó herramientas de IA más rápido que políticas para gobernarlas (GitLab, "AI Accountability Report", 2026, consultado en 2026-07-08). La regla de parada es gobernanza, no un detalle operativo menor.

Para cuando la misma falla vuelve dos veces, cuando el parche necesita tocar archivo fuera del alcance o cuando la corrección exige secreto. También para cuando aparece riesgo de datos, cuando el agente cambia API pública o cuando la causa parece flake de infraestructura. En esos casos, insistir solo compra más diff para revisar.

La documentación de Goals de Codex describe un objetivo persistente como contrato con condición de conclusión, verificación y restricciones, incluyendo parada por éxito, pausa, presupuesto o bloqueo (OpenAI Developers, "Using Goals in Codex", 2026, consultado en 2026-07-08). Esa lógica también sirve para CI: el loop necesita saber terminar.

Cápsula citable: Un buen loop autocorrectivo tiene parada explícita. Como 92% reporta desafíos de gobernanza con código de IA (GitLab, "AI Accountability Report", 2026), la automatización debe terminar cuando repite falla, toca alcance prohibido, exige secreto o encuentra riesgo que necesita juicio humano.

¿Qué implementar esta semana?

En 2025, OpenAI publicó un cookbook que activa Codex cuando un workflow de GitHub Actions termina con falla. El ejemplo crea un PR de corrección desde el branch roto (OpenAI Developers, "Use Codex CLI to automatically fix CI failures", 2025, consultado en 2026-07-08). El mínimo viable debe empezar revisable, no totalmente autónomo.

Implementa tres piezas. Primero, guarda logs reducidos en .ci/failures/. Segundo, crea un job que corre solo en falla y abre PR en branch separada. Tercero, exige que el PR incluya comandos ejecutados y límite de intentos. No actives auto-merge en el primer ciclo.

name: agente-repara-ci
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]
permissions:
  contents: write
  pull-requests: write
jobs:
  reparar:
    if: $false
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: node scripts/ci/resumir-falla.mjs
      - run: codex exec --sandbox workspace-write "$(cat .ci/failures/prompt.txt)"
      - run: npm test

Después conecta branch protection, code owners y un comentario automático con la evidencia. Si la segunda reparación falla, etiqueta el PR como bloqueado para revisión humana. La ganancia viene del ciclo corto, no de fingir que el agente se volvió responsable por el sistema.

Cápsula citable: El primer loop de reparación debe abrir un PR revisable, no hacer merge solo. OpenAI publicó un flujo de Codex para fallas de CI; la versión prudente guarda log corto, corre sandbox, limita intentos y entrega evidencia para branch protection.

Preguntas frecuentes sobre loop autocorrectivo en CI

¿Un loop autocorrectivo reemplaza el code review humano?

No. En 2026, GitHub reportó que más de una de cada cinco revisiones involucra a un agente (GitHub, "Agent pull requests are everywhere", 2026, consultado en 2026-07-08). Eso refuerza la revisión humana cuando cambia API, seguridad, datos o arquitectura.

¿Cuántos intentos debe tener el agente?

Dos intentos son un buen patrón inicial. En 2026, GitLab reportó 85% viendo validación como cuello de botella (GitLab, "AI Accountability Report", 2026, consultado en 2026-07-08). Si el segundo intento falla igual, falta contexto o juicio humano.

¿Puedo usar danger-full-access en CI?

Solo en un runner aislado y controlado. En 2026, OpenAI documentó danger-full-access como opción para ambiente controlado y recomendó workspace-write para nuevas automatizaciones (OpenAI Developers, "Non-interactive mode", 2026, consultado en 2026-07-08). Para PR común, prefiere token corto y alcance.

¿Qué debe recibir el agente del log?

Recibe lo mínimo que reproduce la falla. En 2026, OpenAI documentó eventos JSON Lines en codex exec (OpenAI Developers, "Non-interactive mode", 2026, consultado en 2026-07-08). Eso favorece comando, estado, archivo de log, diff y próxima acción.

Cierre

Loop autocorrectivo de agente en CI no es autonomía irrestricta. Es ingeniería de feedback. El agente recibe una falla pequeña, aplica un cambio pequeño, ejecuta una prueba pequeña y entrega un PR que personas y branch protection pueden negar.

Empieza por la próxima falla repetitiva. Captura el log mínimo, escribe el contrato de reparación, limita el sandbox y exige evidencia en el PR. Si el loop se detiene temprano, no falló. Protegió el repositorio de una corrección que todavía necesitaba juicio.

Fuentes consultadas

  • GitLab, "AI Accountability Report", consultado en 2026-07-08, https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx
  • DORA, "Balancing AI tensions: Moving from AI adoption to effective SDLC use", consultado en 2026-07-08, https://dora.dev/insights/balancing-ai-tensions/
  • GitHub, "Agent pull requests are everywhere. Here's how to review them", consultado en 2026-07-08, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
  • arXiv, "More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests", consultado en 2026-07-08, https://arxiv.org/abs/2601.21276
  • OpenAI Developers, "Non-interactive mode", consultado en 2026-07-08, https://developers.openai.com/codex/noninteractive
  • OpenAI Developers, "Build iterative repair loops with Codex", consultado en 2026-07-08, https://developers.openai.com/cookbook/examples/codex/build_iterative_repair_loops_with_codex
  • OpenAI Developers, "Run long horizon tasks with Codex", consultado en 2026-07-08, https://developers.openai.com/blog/run-long-horizon-tasks-with-codex
  • OpenAI Developers, "Using Goals in Codex", consultado en 2026-07-08, https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex
  • OpenAI Developers, "Use Codex CLI to automatically fix CI failures", consultado en 2026-07-08, https://developers.openai.com/cookbook/examples/codex/autofix-github-actions
  • Anthropic, "Claude Code GitHub Actions", consultado en 2026-07-08, https://code.claude.com/docs/en/github-actions
  • Anthropic, "claude-code-action security", consultado en 2026-07-08, https://github.com/anthropics/claude-code-action/blob/main/docs/security.md