Un informe publicado hoy deja una foto bastante nítida: CI/CD sigue siendo el corazón de DevOps. El cuello de botella, sin embargo, ya no pasa solo por compilar o desplegar más rápido, sino por revisar y validar un volumen cada vez mayor de cambios generados automáticamente. Y ese freno aparece justo cuando muchas organizaciones están poniendo el foco en controlar mejor su proceso de entrega, mantienen infraestructuras propias y prefieren sacar más partido a lo que ya tienen antes que lanzarse a una migración de herramientas.
Entre las organizaciones que ya trabajan con DevOps, el 83,4% ejecuta pipelines de CI/CD. Eso la mantiene, de acuerdo con el informe, como la práctica más extendida del grupo, por delante de la contenerización y orquestación, la infraestructura como código, GitOps y la ingeniería de plataformas. En el apartado de herramientas, GitHub Actions ocupa el primer lugar, seguida de GitLab CI y Jenkins, mientras que Azure DevOps Server aparece por delante de TeamCity.
Aun así, esa elección rara vez es completamente libre. El informe señala que muchas empresas se mueven a la vez entre varias plataformas, ya sea por exigencias de clientes, por diferencias entre stacks tecnológicos o por la presencia de sistemas heredados. En ese escenario, la mayoría de los desarrolladores no tiene previsto cambiar de solución a corto plazo. Y cuando el cambio entra de verdad en estudio, las razones suelen ser bastante terrenales: costes de escalado, esfuerzo de mantenimiento, necesidad de consolidar herramientas y complejidad de configuración.
Aquí pesa más el control. Según el informe, el 72,8% de los encuestados ejecuta su sistema principal de CI/CD en servidores propios o en infraestructura cloud autogestionada, y el uso on-premises alcanzó su cuota más alta de los últimos cinco años.
Detrás de la decisión de correr CI/CD en servidores propios o en infraestructura cloud autogestionada hay razones bastante concretas, también recogidas en el informe: control sobre la infraestructura, sobre los datos, sobre la seguridad, sobre los entornos de compilación y, claro, sobre los costes.
Casi la mitad de las organizaciones, un 48,8%, ya usa asistentes generativos para al menos una tarea relacionada con CI/CD, siempre según el informe, aunque solo el 8% ejecuta pasos basados en estas tecnologías directamente dentro de las fases de compilación o de pruebas. Su presencia se concentra en revisión de código, escritura o corrección de pruebas, diagnóstico de fallos de compilación, mantenimiento de configuraciones del pipeline, controles de calidad y seguridad, apoyo al despliegue y respuesta a incidentes.
Quienes todavía no los adoptan apuntan a otros frenos, según el mismo informe: baja prioridad, preocupaciones por privacidad de datos y propiedad intelectual, conformidad con los flujos actuales y coste. Las empresas pequeñas, además, son las que con más frecuencia consideran que su enfoque actual ya les funciona lo bastante bien.
Y ahí aparece la fricción de fondo: producir más código no se traduce automáticamente en entregar más software. La investigación citada calcula que la producción de los desarrolladores sube en torno al 34%, pero el tiempo medio de revisión de pull requests se dispara un 441,5%. Cuando el uso es intensivo, añade esa misma investigación, las pull requests son un 51,3% más grandes y tocan un 59,7% más de archivos, así que la frecuencia de despliegue cae un 11,7%.
Parte de ese fenómeno se entiende por la desconfianza. En un sondeo de 2026, el 96% de los desarrolladores decía no confiar plenamente en la corrección funcional del código generado automáticamente, y solo el 48% afirmaba revisarlo siempre. Además, entre los profesionales consultados en 2025, un 66% señalaba como gran frustración recibir resultados casi correctos, pero no del todo. Eso está empujando a los equipos hacia revisiones asistidas, más controles automáticos dentro de CI/CD y revisión humana según el riesgo, sobre todo en las partes más críticas del código.
