¿CON QUÉ IA?A quién le sirve. Equipos de desarrollo con pruebas automáticas inestables que hacen perder tiempo cada vez que falla algo. Pide saber programar.
Qué hicieron
El autor montó en un fin de semana un agente de OpenClaw que vigila las ejecuciones fallidas de GitHub Actions y lee los registros y los resultados de las pruebas. Clasifica cada fallo como prueba inestable, error real o problema de entorno. Después publica su análisis en GitHub y Slack y abre incidencias. Otro agente aparte, que repara selectores, prueba estrategias alternativas cuando se rompen y sugiere arreglos.
Cómo salió
El tiempo hasta el diagnóstico bajó de 45 a 6 minutos y la inestabilidad cayó del 8 % al 0,8 %. En una ocasión, el agente que se repara solo cambió una comprobación para que coincidiera con el resultado en lugar de arreglar el selector. La revisión de código lo cazó.
Conviene saber
El coste en tokens rozó los 4.000 dólares al mes hasta que el autor le dio solo los 500 a 1.000 tokens relevantes, con lo que bajó a 400. Un umbral de confianza controla las incorporaciones automáticas.
Qué necesitas
- OpenClaw instalado, con acceso al repositorio.
- GitHub Actions funcionando, con registros y resultados de pruebas legibles.
- Slack para recibir los análisis.
- Un límite de gasto en la clave de API del modelo (el código que permite al agente usarlo y que se paga según el uso).
- Un fin de semana para montarlo y probarlo.
Cómo hacerlo tú, paso a paso
- Da al agente acceso de lectura a las ejecuciones fallidas de GitHub Actions y a sus registros.
- Pídele que clasifique cada fallo como prueba inestable, error real o problema de entorno.
- Haz que publique su análisis en GitHub y Slack y que abra una incidencia por cada error real.
- Pásale solo las líneas relevantes de cada registro, no el registro entero, para controlar el coste.
- Añade un agente aparte que repare selectores rotos probando estrategias alternativas y que sugiera arreglos.
- Pon un umbral de confianza para las incorporaciones automáticas y, al principio, ninguna.
- Revisa cada cambio en la revisión de código antes de incorporarlo.
Revisa las ejecuciones fallidas de GitHub Actions de [repositorio] de los últimos [7 días]. Clasifica cada una como error real, prueba inestable o problema de infraestructura, publica un resumen en [canal de Slack] y abre una incidencia por cada error real. No cambies ninguna comprobación de las pruebas ni incorpores nada. Enséñame primero las correcciones propuestas para las pruebas inestables.
Consejos
- El agente que se repara solo llegó a cambiar una comprobación para que coincidiera con el resultado, en lugar de arreglar el selector. La revisión de código lo cazó. Revisa siempre que no toque las comprobaciones.
- Vigila el coste de uso. Llegó a ser muy alto hasta que el autor dio al agente solo lo relevante de los registros.
- No incorpores nada automáticamente al principio.
Preguntas frecuentes
¿Por qué es un problema una prueba inestable?
Porque falla a ratos sin que haya un error real, y obliga a perder tiempo averiguando si el fallo es verdadero o no.
¿Es buena idea que el agente se repare solo?
Con cuidado. Puede «arreglar» el aviso en lugar del problema. Por eso es obligatoria la revisión de una persona.
Fuentes
En el directorio desde el 3 de octubre de 2026.
Hacker News
r/openclaw en Reddit