A quién le sirve. Equipos de desarrollo cuyas pruebas automáticas fallan a ratos y frenan las entregas; si no programas, te sirve para saber qué pedirle a tu equipo técnico.
Qué hicieron
El autor dio a Claude acceso de lectura a los resultados del sistema de integración continua (CI, el proceso que ejecuta las pruebas automáticas del código) y le hizo construir una herramienta que sigue el porcentaje de aciertos y fallos de los últimos 30 días. Claude eligió las pruebas inestables más graves, planteó si la causa estaba en la prueba o en el código y las redujo a reproducciones mínimas. Cuando no podía reproducir el fallo siempre igual, probaba un arreglo y volvía a lanzar las pruebas por la noche para juzgarlo con estadística. De día, el autor revisaba las propuestas de cambio.
Cómo salió
En unas pocas semanas el proceso se acortó en 20 minutos y el porcentaje de aciertos subió un 35 %, desde un 40 % aproximado en la rama principal. Algunas soluciones de Claude eran malas y hubo que descartarlas.
Conviene saber
Revisa tú todos los cambios propuestos: el autor descartó arreglos malos, así que lo que hace la IA de noche necesita comprobación humana de día.
Qué necesitas
- Claude Code instalado y una cuenta con acceso a él (plan de pago o clave de API).
- Acceso de solo lectura a los resultados de tu sistema de integración continua (CI), que es el que ejecuta las pruebas automáticas del código.
- El repositorio del proyecto en tu ordenador o en un servidor.
- Una máquina que pueda trabajar de noche, para repetir las pruebas muchas veces.
- Una persona que revise por el día los cambios propuestos.
Cómo hacerlo tú, paso a paso
- Dale a Claude Code acceso de solo lectura a los resultados de tu sistema de CI.
- Pídele una herramienta que calcule el porcentaje de aciertos y fallos de cada prueba en los últimos 30 días.
- Pídele que elija las pruebas más inestables y que plantee, de cada una, si la causa está en la prueba o en el código.
- Pídele que reduzca cada fallo a una reproducción mínima, el caso más pequeño que sigue fallando.
- Cuando no pueda reproducirlo siempre igual, pídele que pruebe un arreglo y relance las pruebas muchas veces por la noche, para juzgar el resultado con estadística.
- Haz que cada arreglo vaya en una rama aparte, con su propuesta de cambio.
- Por el día, revisa las propuestas y descarta las que no convenzan.
Mira las últimas [número] ejecuciones de pruebas de [nombre del repositorio] y ordena las pruebas según lo a menudo que fallan de forma intermitente. Con las [número] peores, reproduce el fallo en local, encuentra la causa y propón un arreglo en una rama aparte. Ejecuta cada arreglo [número] veces para comprobar que es estable, descarta los que no aguanten y resume lo que ha funcionado. Habrás terminado cuando tengas ese resumen. No unas nada a la rama principal sin enseñarme antes los cambios.
Consejos
- Revisa tú todos los cambios. El autor descartó algunos arreglos malos, y lo que hace la IA de noche necesita comprobación humana de día.
- Que trabaje siempre en ramas aparte y que no pueda unir nada a la rama principal sin tu permiso.
- Empieza por las pocas pruebas más inestables, no por todas a la vez.
Preguntas frecuentes
¿Qué es una prueba inestable?
Una prueba automática que unas veces pasa y otras falla sin que el código haya cambiado. Con el tiempo el equipo deja de fiarse de los avisos.
¿Puede la IA romper algo del proyecto?
Si trabaja en ramas aparte y no puede unir cambios sin tu permiso, el riesgo baja mucho. Aun así revisa cada cambio, porque algunas soluciones que propuso eran malas.
Fuentes
En el directorio desde el 3 de octubre de 2026.