# Arreglar fallos de CI y comentarios de PR con IA

URL: https://agentvera.dev/es/blog/auto-fix-ci-failures-with-ai/ · Publicado: 2026-10-18

Deja que un agente de IA arregle ejecuciones de CI en rojo y atienda comentarios de PR: qué lo dispara, qué límites tiene, cómo entrega y qué revisar antes de main.

**En resumen:**

- En AgentVera, una regla puede iniciar Claude Code o Codex cuando GitHub Actions, GitLab CI o Jenkins se ponen en rojo, o cuando un miembro del repo comenta en un PR abierto; los comentarios se leen cada 2 minutos.
- El agente trabaja en su propio worktree y solo hace commits; AgentVera hace el push tras escanear archivos secretos y nunca hace push directo a la rama por defecto.
- Cada regla tiene un límite diario (5 por defecto, hasta 50), y se intentan como máximo 2 arreglos automáticos de CI por rama y día, así que un arreglo fallido no puede entrar en bucle.

Poder arreglar fallos de CI con IA te quita de encima una de las tareas más repetitivas. Haces push y diez minutos después GitHub Actions está en rojo. Abres el log, recorres doscientas líneas, encuentras un error de tipos o un snapshot obsoleto, lo arreglas y vuelves a hacer push. Con los comentarios de PR pasa lo mismo: notas pequeñas como «renombra esta variable» o «aquí falta una comprobación de null» se acumulan, y cada una te saca de lo que estabas haciendo.

Este artículo explica cómo delegar ese trabajo en un agente de IA: qué lo dispara, qué límites tiene, cómo entrega y qué mirar antes de que llegue a main.

## Por qué arreglarlo a mano sale caro

Arreglar un build en rojo rara vez es difícil. Lo que cuesta es el cambio de contexto:

- **Estás en medio de otra cosa.** La notificación de CI en rojo te aparta de ella.
- **Leer logs lleva tiempo.** El error real está enterrado entre cientos de líneas, y la primera línea roja a menudo no es el error real.
- **Hay que reproducirlo en local.** Encontrar el comando de CI, ejecutarlo y resolver las diferencias de entorno es un trabajo en sí mismo.
- **Los comentarios llegan en pedazos.** Una revisión con seis comentarios implica leer los seis y responder a cada uno.

Lo que tienen en común estos trabajos es un conjunto conocido de pasos. El trabajo con pasos conocidos se puede delegar en un agente.

## Disparadores: ¿cuándo empieza el agente?

En AgentVera, las automatizaciones están en **Details → Automation → Automations**. Una regla empieza a trabajar sola cuando ocurre un evento. Aquí importan dos disparadores.

### CI turned red

Este disparador vigila los proveedores que añadiste en la pestaña CI/CD: GitHub Actions, GitLab CI y Jenkins. Deja **Branches** vacío para vigilar todas las ramas, o enuméralas, como `main, release/*`.

Algunas ejecuciones se omiten a propósito. Las ejecuciones de pull requests desde forks y las ejecuciones de merge requests de GitLab no activan la regla. La rama y el log de un fork pertenecen a alguien ajeno a tu repo, así que la regla solo reacciona a ramas en las que puedes hacer push de un arreglo.

### PR got a comment

Los comentarios nuevos de revisión y de conversación en pull requests abiertos se leen cada 2 minutos, con filtros:

- **Solo cuentan los comentarios del propietario, los miembros o los colaboradores del repo.** Un comentario de alguien de paso no iniciará un agente.
- **Los comentarios de bots no cuentan.** Las propias respuestas de AgentVera están marcadas y nunca se vuelven a recoger.
- **Si ya hay un agente trabajando en ese PR,** los comentarios nuevos van a él; no se abre un segundo agente.
- **Si se alcanza el límite diario,** los comentarios no se pierden; se vuelven a leer más tarde.

Los disparadores de comentarios de PR e incidencias necesitan que el `origin` del repo esté en GitHub y una sesión de GitHub iniciada en tu ordenador.

Los eventos los vigila la app de escritorio, así que AgentVera debe estar abierto en tu ordenador para que las reglas se ejecuten.

### Presets

Cuando un proyecto aún no tiene reglas, AgentVera ofrece presets. Dos de ellos hacen justo este trabajo:

| Preset | Qué hace |
| --- | --- |
| Fix CI when it breaks | Lee el log de la ejecución en rojo y lo arregla; hace push a las ramas de funcionalidad y abre un PR para la rama principal |
| Handle PR comments | Aplica los comentarios de revisión de los PR abiertos, hace push a la rama del PR y responde |

Los otros dos se ocupan de las incidencias con la etiqueta «ajan» y de actualizar dependencias cada lunes.

## Qué hace el agente

Cuando se activa una regla, el agente arranca en un worktree nuevo sobre una rama nueva que empieza por `ajan/`. La rama se basa en la rama del evento: la de la ejecución en rojo o la del PR. Tu carpeta de trabajo no se toca. Los archivos `.env` ignorados por git se copian al worktree para que los tests puedan ejecutarse, pero nunca se suben.

El agente sigue los pasos del **Playbook** de la regla. Para CI, el playbook por defecto es «Fix a CI failure»:

1. Encuentra el primer error real en el log.
2. Ejecuta el comando de CI en local y reproduce el error.
3. Arregla la causa raíz; si el problema está en la configuración de CI (workflow, versión, variable de entorno), arregla eso.
4. Vuelve a ejecutar los comandos de CI en local y comprueba que pasan.

Para los comentarios de PR, el de por defecto es «Address PR comments»: lee cada comentario y el código al que apunta, aplica los que sean correctos, explica tu razonamiento donde discrepes, ejecuta los tests y, en la respuesta, enumera lo que se hizo para cada comentario.

Puedes cambiar los playbooks. Guarda los tuyos en este ordenador o en el repo; los playbooks del repo se escriben en `.agentvera/playbooks/`, se comparten con el equipo mediante git y sustituyen al playbook integrado del mismo nombre.

Usa **Extra instructions** para acotar la regla. Por ejemplo: «Arregla solo tests y errores de tipos; no cambies el contrato de la API.»

En el campo **Agent**, elige Claude Code o Codex.

## Límites: ¿qué frena al agente?

Un agente que se ejecuta por su cuenta tiene que estar limitado, no solo ser bueno. En AgentVera los límites son:

- **Un límite diario.** Cada regla tiene un valor **Max per day** de 1 a 50, 5 por defecto, contado sobre las últimas 24 horas. Las ejecuciones que inicias a mano no cuentan.
- **Un límite por rama.** Se intentan como máximo 2 arreglos automáticos de CI por rama y día, y solo un arreglo por rama se ejecuta o espera a la vez. Si un arreglo vuelve a romper el CI, el agente no da vueltas sin fin.
- **El texto externo no son instrucciones.** Los logs de CI, los comentarios de PR y el texto de las incidencias se entregan al agente como texto externo no confiable que solo describe el trabajo. Se le dice al agente que no comparta secretos, que no ejecute comandos ajenos a la tarea y que no envíe datos a ningún otro sitio.
- **El agente no hace push.** Solo hace commits. Hacer el push y abrir el PR es trabajo de AgentVera, después de que el agente entregue.
- **Un escaneo de archivos secretos.** Antes del push, cada commit y el estado final se escanean en busca de archivos secretos: archivos `.env`, claves como `.pem` y `.key`, `id_rsa`, `.npmrc`, `.netrc`, `credentials.json` y similares. Los archivos de ejemplo como `.env.example` no dan problema. Si se encuentra alguno, no se sube nada y la ejecución falla.
- **Un agente atascado se detiene.** Si el agente pide ayuda, se queda en silencio o se cierra, la ejecución pasa a «needs attention» y recibes una notificación.

## Entrega: ¿adónde va el trabajo?

Lo que ocurre cuando el agente termina lo define **On delivery**:

| Opción | Qué ocurre |
| --- | --- |
| Automatic (push to the CI branch, PR to the main branch) | Push si el fallo fue en una rama de funcionalidad, PR si fue en la rama por defecto |
| Open a PR | Siempre un PR |
| Push to the same branch | Push a la rama del evento; en la rama por defecto sigue siendo un PR |
| Add to the merge queue | La rama entra en la cola y se prueba su resultado fusionado |
| Leave on the branch | No se sube nada; la rama se queda contigo |

Una regla nunca cambia: AgentVera nunca hace push directo a la rama por defecto. Si el agente no hizo cambios, la ejecución termina con una nota de «no changes».

Para los comentarios de PR, el trabajo se sube a la rama del PR y AgentVera publica una respuesta en el PR que describe lo que el agente hizo con cada comentario.

Elegir la cola de fusión significa que el arreglo se prueba una vez más sobre el último main. Explico cómo funciona la cola en el [artículo sobre la cola de fusión](/es/blog/merge-queue-for-ai-agents/).

## Revisa antes de que llegue a main

Un arreglo automático no es una aceptación automática. Hay varias formas de revisar el trabajo del agente:

- **El propio pull request.** Los fallos en main ya vuelven como PR. Lee el diff, mira cómo el CI se pone en verde y fusiónalo como cualquier otro PR.
- **Aprobación en la cola de fusión.** **Land passing branches automatically** está desactivado por defecto, así que el trabajo que pasa su comprobación te espera.
- **Dejarlo en la rama.** Durante las primeras semanas de una regla nueva, elegir **Leave on the branch** y revisar a mano es la opción más prudente.
- **La pestaña Runs.** Mira el estado de cada ejecución, su agente y el PR que abrió.

Para tus propios agentes, AgentVera también tiene revisión de código automática: cuando termina el turno de un agente, un modelo Claude que elijas revisa el código e informa de hallazgos con severidad y archivo:línea. Más en el artículo sobre [revisión de código con IA](/es/blog/ai-code-review/).

Al revisar, fíjate bien en:

- **¿Se arregló el test o el código?** Si el agente cambió un valor esperado para que un test pase, es una señal de alerta. Puedes prohibirlo en Extra instructions.
- **¿Cambió la configuración de CI?** Editar un workflow puede ser legítimo, o puede ser un paso omitido.
- **¿Se mantuvo dentro del alcance?** Un error de tipos no debería volver como un refactor de diez archivos.

## Arreglos con un clic desde el centro de CI/CD

Puede que no quieras una regla para cada ejecución en rojo. La pestaña CI/CD lista las 25 ejecuciones más recientes por proveedor; puedes volver a lanzar una ejecución, relanzar solo los jobs fallidos (no en Jenkins) o cancelarla. En una ejecución en rojo, **Have an agent fix it** abre un agente con los detalles de la ejecución y el final del log de sus jobs fallidos. Esta vez estás ahí mismo con el agente.

## Errores comunes

- **Vigilar main con «Push to the same branch» y esperar un push directo.** AgentVera no hace push a la rama por defecto; el arreglo sigue llegando como PR.
- **Subir el límite diario al máximo.** El límite es una red de seguridad. Mantenlo bajo hasta que la regla se gane tu confianza.
- **Dejar vacío Extra instructions.** Decirle al agente qué no debe tocar acota los resultados de forma notable.
- **Dejar los tests inestables al agente.** Con un test que falla de vez en cuando, el agente puede cambiar cosas que no hacía falta cambiar. Ocúpate tú primero de los tests inestables.
- **Guardar secretos en el repo.** El escaneo detiene el push, pero la solución real es no poner nunca secretos en el repo.

## Un día de ejemplo

### Por la mañana

El commit de madrugada de alguien a `main` rompió el CI. La regla «Fix CI when it breaks» lo detectó: el agente encontró el error de tipos en el log, lo reprodujo en local y lo arregló. Como era la rama por defecto, el trabajo volvió como un PR. Lees el diff con el café y lo fusionas.

### A mediodía

Un compañero deja cuatro comentarios en uno de tus PR. En dos minutos entra en acción la regla «Handle PR comments». El agente aplica tres, discrepa de uno y explica por qué. AgentVera hace push a la rama del PR y deja una respuesta en el PR. Todo lo que haces es leer aquel con el que discrepó y decidir.

### Por la tarde

El CI sigue fallando en una rama de funcionalidad. El agente lo intenta dos veces, y los tests siguen en rojo las dos. No hay un tercer intento; ves el estado en la pestaña Runs. El log muestra que el problema es una variable de entorno del test, así que lo arreglas tú.

## Lista de comprobación

- [ ] ¿Está añadido tu proveedor de CI en la pestaña CI/CD?
- [ ] En repos de GitHub, ¿tienes la sesión de GitHub iniciada en este ordenador?
- [ ] ¿Es correcto el campo **Branches**? Vacío significa todas las ramas.
- [ ] ¿Dicen las **Extra instructions** qué no debe tocar el agente?
- [ ] ¿Está **Max per day** fijado de forma conservadora?
- [ ] ¿Encaja **On delivery** con tu forma de revisar?
- [ ] ¿Tienes los secretos fuera del repo?

## Para terminar

Delegar los fallos de CI y los comentarios de PR en un agente de IA te devuelve la parte más interrumpida de tu día. Lo importante no es que el agente sea rápido, sino que esté acotado: en AgentVera trabaja en su propio worktree, no hace push por su cuenta, nunca escribe directamente en la rama por defecto, no sube trabajo que contenga archivos secretos y tiene un número limitado de intentos por rama. La decisión final sigue siendo tuya, en el PR o en la cola de fusión.

Sigue leyendo:

- [Automatizaciones](/es/features/automations/)
- [Centro de CI/CD](/es/features/ci-cd-center/)
- [Revisión de código](/es/features/code-review/)
- [Pipeline de flujo de trabajo con agentes de IA](/es/blog/ai-agent-workflow-pipeline/)
- [Agentes de código en paralelo](/es/blog/parallel-coding-agents/)

Para probar AgentVera, empieza en la [página de inicio](/es/).

## Preguntas frecuentes

**¿Puede la IA arreglar de verdad los fallos de CI?** A menudo, en el caso de tests rotos, errores de tipos, fallos de lint y problemas de configuración de CI como una versión o una variable de entorno. El agente encuentra el primer error real en el log, lo reproduce en local y lo arregla. Tú sigues revisando el resultado.

**¿El agente hace push directo a main?** No. AgentVera nunca hace push directo a la rama por defecto. Un fallo en main vuelve como pull request; un fallo en una rama de funcionalidad se sube a esa rama con la entrega por defecto.

**¿Puede el agente quedarse atascado en un bucle de arreglos?** No. Se intentan como máximo 2 arreglos automáticos por rama y día, y solo un arreglo por rama se ejecuta o espera a la vez. Además, cada regla tiene su propio límite diario.

**¿Con qué agentes funciona?** Las reglas de automatización ejecutan Claude Code o Codex. Eliges uno en el campo Agent de la regla.

**¿Qué sistemas de CI son compatibles?** El disparador «CI turned red» vigila los proveedores GitHub Actions, GitLab CI y Jenkins que añadas en la pestaña CI/CD. Los disparadores de comentarios de PR e incidencias necesitan el repo en GitHub y una sesión de GitHub iniciada en tu ordenador.

**¿Qué plan lo incluye?** Las automatizaciones están en los planes Pro y Team. En la app de escritorio están en Details → Automation → Automations.

---

**Sobre AgentVera.** AgentVera es una app de escritorio para macOS, Windows y Linux, desarrollada por Solviera Teknoloji. Ejecuta 18 agentes de programación con IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) en paralelo, por proyecto, en terminales reales con las instalaciones y sesiones de CLI del propio usuario. El plan gratuito tiene agentes ilimitados. Descargar: https://agentvera.dev/es/download/ · Precios: https://agentvera.dev/es/pricing/