La IA no acabó con DevOps: nos obliga a volver a entregar valor
Se habla mucho de si la IA acabó con el rol del programador. Para mí, esa conversación parte de una definición demasiado pequeña del trabajo. La ingeniería de software nunca fue solamente escribir código.
Con DevOps estamos cometiendo el mismo error.
Si reducimos DevOps a escribir manifiestos, mantener scripts de infraestructura o crear archivos YAML para un pipeline, entonces sí: una parte importante de ese trabajo será automatizada. Pero ese nunca fue el punto. DevOps no nació para producir YAML. Su propósito siempre fue garantizar una entrega de valor continua, segura y confiable.
Yo diría que la IA no elimina ese propósito. Al contrario, nos obliga a volver a él.
DevOps nunca fue mover código del punto A al punto B
Durante mucho tiempo asociamos DevOps con la parte más visible del proceso: preparar un pipeline, desplegar una aplicación, ejecutar pruebas, configurar infraestructura o crear automatizaciones.
Todo eso forma parte del trabajo, pero no es el resultado. Un pipeline en verde solo demuestra que se cumplieron unas condiciones que nosotros mismos definimos. No garantiza que el cambio aporte valor, que los permisos sean correctos, que podamos recuperarnos de un fallo o que sepamos qué está ocurriendo en producción.
Aquí está el detalle importante: el artefacto no es el trabajo.
El manifiesto, el script y el flujo de CI/CD son medios. El trabajo real es construir un camino que nos permita cambiar el software con confianza. Detectar errores temprano, reducir el riesgo de cada despliegue, proteger información sensible, responder ante incidentes y aprender de lo que ocurre en producción: eso también es DevOps.
Visto así, DevOps no desaparece porque una IA pueda escribir un flujo en segundos. Lo que pierde valor es escribirlo manualmente y creer que ahí terminó nuestro trabajo.
La IA cambia dónde debemos poner el esfuerzo
Hoy una herramienta de IA puede generar una primera versión de un pipeline, un Dockerfile o una configuración de infraestructura como código. En muchos casos lo hará más rápido que nosotros y con una sintaxis bastante correcta. No tengo problema en admitirlo: ya no tiene mucho sentido gastar nuestra energía en recordar cada propiedad de un YAML.
Pero una configuración puede ser válida y seguir siendo una mala decisión para nuestro sistema. Puede conceder permisos excesivos, exponer secretos, duplicar costos, ignorar una ruta de recuperación o agregar una complejidad operativa que el equipo no necesita. La IA puede conocer la sintaxis; no necesariamente conoce nuestro contexto.
Ahí es donde cambia la conversación. No pasamos de hacer DevOps a no hacerlo. Pasamos de producir cada instrucción manualmente a orquestar y supervisar el sistema de entrega completo.
Para mí, el tiempo que ganamos debería ir a preguntas con mucho más impacto:
- ¿Qué pasa si este despliegue falla a la mitad?
- ¿Cómo comprobamos que la nueva versión funciona para usuarios reales?
- ¿Podemos revertir el cambio sin improvisar durante un incidente?
- ¿Los permisos son los mínimos necesarios?
- ¿Qué señales nos avisan antes de que el problema llegue al cliente?
- ¿El costo operativo de esta solución tiene sentido para el valor que entrega?
La IA también puede ayudarnos con estas preguntas, por supuesto. Pero la responsabilidad sobre la decisión y sus consecuencias sigue siendo nuestra. Si el despliegue rompe producción, no sirve de mucho decir que el manifiesto lo generó una herramienta.
La migración de este blog me lo dejó claro
Cuando migré este blog de WordPress a Astro, todavía no existía GitHub Agentic Workflows. Para automatizar algunas verificaciones, monté procesos que ejecutaban herramientas como Codex o Copilot desde el pipeline. En esencia, el control era un prompt: le explicaba qué debía revisar y esperaba que actuara como yo tenía en mente.
Al principio parecía funcionar. El código no se rompía y visualmente el blog se veía bien. Pero por debajo empezaron a aparecer decisiones que yo no había pedido. Un proceso que debía crear un issue podía tocar otros o crear más de uno. No era necesariamente un error de sintaxis. Era el resultado de poner una tarea no determinista dentro del flujo sin suficientes límites alrededor.
Con la migración del contenido pasó algo parecido. Algunas imágenes no seguían un estándar y afectaban el rendimiento. Quedaron enlaces rotos. Los artículos se ordenaron alfabéticamente cuando debían ordenarse por fecha. La página se veía correcta, pero el proceso no estaba entregando el resultado que yo necesitaba.
Esa fue la trampa: confundir “se ve bien” con “el sistema funciona bien”.
Mi trabajo real no terminó siendo programar cada workflow ni escribir cada paso de la migración. Fue definir qué debía conservarse, qué estructura quería, cómo debían tratarse las imágenes, qué validaciones tenían que pasar y qué cosas la IA no podía decidir por su cuenta. En WordPress muchas de esas responsabilidades estaban resueltas por plugins. Al pasar a Astro, tuve que hacerlas explícitas.
Por eso terminé creando skills y validaciones para que la IA trabajara dentro de un proceso conocido. Y por eso GitHub Agentic Workflows me pareció un avance importante: no porque convierta al agente en determinista, sino porque permite rodearlo de permisos acotados, salidas seguras y controles más claros.
Ese cambio resume bastante bien lo que intento explicar en este artículo. Mi valor no estuvo en escribir todas las instrucciones. Estuvo en orquestar la migración, detectar lo que parecía correcto pero no lo era y convertir mis expectativas en un proceso repetible.
El perfil que solo produce artefactos pierde valor
Aquí aparece una comparación incómoda con el rol del programador. Si una persona se define únicamente como alguien que convierte una tarea en líneas de código, la IA reduce mucho el valor de esa ejecución aislada. Si alguien en DevOps se define únicamente como quien recibe una aplicación y la lleva del punto A al punto B, ocurre lo mismo.
No creo que eso signifique que esas personas dejan de ser necesarias de un día para otro. Significa que el mercado va a valorar menos la ejecución mecánica y más el criterio que la rodea.
El perfil que gana importancia entiende por qué existe el pipeline, qué riesgos controla y qué necesita el equipo para entregar con confianza. Puede hablar de seguridad, escalabilidad, observabilidad, costos y recuperación. También sabe cuándo una automatización ayuda y cuándo estamos agregando infraestructura solo para sentir que el proceso es más profesional.
Esto no significa que ahora todos debamos ser especialistas profundos en Kubernetes, redes y seguridad. Ese sería otro extremo. Los sistemas complejos siguen necesitando especialistas y equipos de plataforma. Lo que ya no podemos hacer es tratar la operación como una caja negra que pertenece exclusivamente a otro equipo.
De roles separados a una ingeniería más íntegra
Durante años dividimos el desarrollo en categorías cada vez más específicas: frontend, backend, QA, infraestructura y operaciones. Esa especialización resolvió problemas reales y seguirá siendo necesaria. El problema aparece cuando la división nos hace creer que nuestra responsabilidad termina al pasarle el trabajo a la siguiente persona.
La IA está empujando en la dirección contraria. Al reducir el costo de muchas tareas especializadas, hace viable que un ingeniero participe en una parte más amplia del ciclo de vida del software. No necesita dominar cada área al mismo nivel, pero sí entender cómo su decisión llega a producción y qué ocurre después.
Por eso me parece útil pensar en un perfil con forma de E: amplitud en varias capacidades, profundidad real en algunas y capacidad de conectar el trabajo entre disciplinas. No me interesa tanto discutir la letra. Me interesa la idea detrás de ella: volver a una ingeniería de software más íntegra.
Desde esa perspectiva, DevOps no es un paso final ni un ticket que delegamos al equipo de infraestructura. Es parte del núcleo de nuestras habilidades como ingenieros. Diseñar una funcionalidad sin pensar cómo desplegarla, observarla y recuperarla es dejar el trabajo incompleto.
DevOps cambia para volver a su propósito
Tampoco conviene exagerar y decir que la IA ya puede operar cualquier sistema sin intervención humana. En entornos regulados, plataformas críticas o infraestructuras grandes, la experiencia especializada importa incluso más. No delegaría una decisión sensible a una herramienta que no conoce todas las restricciones del negocio ni carga con las consecuencias de un fallo.
Pero sí debemos aceptar que escribir artefactos dejó de ser el centro del rol. Aferrarnos a esa parte sería como defender que programar consiste en teclear cada línea a mano.
La oportunidad está en usar la IA para eliminar fricción y dedicar más capacidad a lo que siempre debió importar: crear procesos de entrega simples, seguros, observables y confiables. Procesos que permitan aportar valor de manera continua, no solamente mover paquetes entre entornos.
Para mí, esa es la reflexión. DevOps cambió, sí, pero para obligarnos a volver a su propósito. Quien solo escribía manifiestos tendrá que evolucionar. Quien entienda cómo entregar software con confianza tendrá más valor, no menos.
Si quieres seguir aprendiendo sobre estos temas te invito a ver mis otras publicaciones.
