Un agente de código con permisos amplios puede tocar cualquier archivo del repositorio, incluidos los que definen cómo se construye, se testea y se despliega el propio proyecto. Eso incluye archivos de CI/CD. Y un cambio mal hecho ahí no falla en el momento: falla en el siguiente despliegue, cuando ya es mucho más caro de diagnosticar.

Por eso trato los archivos de configuración de CI/CD como una categoría aparte, con reglas distintas al resto del código.

Por qué esto es distinto a un bug normal en el código

Un bug en la lógica de la aplicación normalmente lo detectan los tests o se ve en desarrollo antes de llegar a producción. Un bug en el pipeline de CI/CD puede quedar invisible hasta el momento exacto en que necesitas que el pipeline funcione bien: un despliegue urgente, una release, un hotfix. Es el peor momento posible para descubrir que algo se rompió hace tres commits.

Cómo delimito el acceso en la práctica

  • Los archivos de pipeline van en la lista de "no tocar sin revisión explícita". Esto lo documento en el archivo de reglas del proyecto que el agente lee antes de proponer cambios: workflows de CI, Dockerfiles de build, scripts de despliegue. Cualquier cambio ahí requiere que yo lo pida explícitamente, nunca como efecto colateral de otra tarea.
  • Cuando sí necesito tocar CI/CD, lo hago como tarea aislada. No mezclo un cambio de pipeline con un cambio de funcionalidad en el mismo turno. Si el agente propone tocar ambos a la vez, le pido que separe los cambios para poder revisar el de CI/CD con más atención.
  • Reviso ese tipo de cambio línea por línea, sin excepción. Para el resto del código a veces confío en una revisión más rápida si el criterio de éxito automático es fuerte. Para CI/CD no, porque el "criterio de éxito automático" ahí es precisamente lo que se está modificando.

El caso especial de los secretos y credenciales

Nunca dejo que un agente tenga acceso de lectura a los valores reales de secretos usados en el pipeline, solo a sus nombres y a dónde se referencian. Esto no es solo precaución por fuga de datos: es que un agente que puede ver un secreto puede, sin mala intención, incluirlo en un log de depuración o en un mensaje de commit sin darse cuenta de que era sensible.

Dónde sí dejo autonomía completa

En cambios de pipeline puramente aditivos y reversibles en un entorno de prueba —añadir un paso de linting adicional en una rama de test, por ejemplo— dejo más margen, porque el coste de un error ahí es bajo y detectable de inmediato, no silencioso.

La recomendación

Trata la configuración de CI/CD como una categoría de archivos aparte, con reglas de acceso más estrictas que el resto del código, documentadas explícitamente para el agente. El coste de un error ahí no se paga en el momento, se paga en el peor momento posible: cuando de verdad necesitas que el pipeline funcione.

Relacionado: Cómo montar un pipeline de revisión de código con IA sin perder el control