Hace unos años a los senior DevOps se les reconocía por su memoria muscular con kubectl y por la velocidad a la que escribían HCL. Hoy ese mismo volumen lo genera Claude o Codex en diez segundos, indentación incluida. El trabajo no ha desaparecido; se ha desplazado hacia arriba en la pila, y con él se ha desplazado la definición de ingeniero valioso.
Donde la IA ya supera al humano
Cualquier artefacto de plantilla — un Dockerfile, valores de Helm, un módulo de Terraform a partir de un requisito, una política IAM a partir de una descripción — la IA lo escribe más rápido, más limpio y sin cansancio. Descifrar un terraform plan de doscientas líneas en tres puntos comprensibles es ahora una operación barata. La IA detecta el drift entre Git y el clúster como un emparejamiento de patrones estructural. El triaje de un incidente típico por las top-N root causes ocurre en el tiempo de un único scroll humano.
Esa es la parte de DevOps sobre la que un junior construía su carrera en 2020. Para 2026 ha dejado de ser marca de competencia.
Donde el ingeniero se queda
El capacity planning no es una tarea de plantilla. «Tres réplicas bastan» frente a «hacen falta cinco por picos imprevisibles» se decide por el juicio sobre el negocio y el perfil de carga, no por un patrón del corpus de entrenamiento. La responsabilidad de una caída de producción no se delega: la IA no asume las consecuencias de borrar una tabla a las dos de la madrugada ni está en la guardia on-call.
Los trade-offs arquitectónicos — sync o async, consistencia o disponibilidad, failover de región o aislamiento por región — son preguntas sobre si el sistema debería siquiera tener esa forma, no preguntas de sintaxis. Los failure modes de los sistemas distribuidos (CAP, fallos parciales, tail latency, split-brain) la IA los describe de libro, pero pierde pie dentro de una topología ajena. El horizonte largo — adónde llevar la pila en dos años, qué deuda técnica cerrar primero — exige un conocimiento del equipo, del producto y de la historia de las decisiones del que el modelo no dispone.
Y por último, las negociaciones. Explicar al equipo de producto por qué la migración de datos llevará dos semanas y no dos días no lo hará la IA.
Qué cambia en el día a día
Menos tiempo se va en kubectl rollout restart, terraform apply, helm upgrade. Más tiempo se va en revisar lo que produjo el agente, diseñar escenarios de fallo y hablar de trade-offs con los stakeholders. El ingeniero senior de 2026 dedica menos horas a teclear y más a las decisiones que el tecleo enmascaraba antes.
Para un junior esto significa que aprenderse kubectl get pod de memoria ya no tiene valor de carrera. Lo tiene entender por qué tres réplicas, por qué un PodDisruptionBudget, qué devuelve un readiness probe en un graceful shutdown. Las habilidades a nivel de arquitectura se vuelven diferenciador antes en la curva profesional de lo que dictaba el mapa anterior.
El equipo alrededor de la IA: reglas de trabajo
Unas pocas reglas separan un proceso de trabajo de un experimento peligroso.
Read-only primero. Un agente nuevo empieza con acceso de solo lectura. El acceso de escritura llega tras semanas de tracking del comportamiento en tareas reales.
Human-in-the-loop para operaciones destructivas. terraform destroy, kubectl delete, escrituras contra la base de datos de producción — siempre detrás de una aprobación humana explícita. Sin allowlists de «comandos confiables» para acciones destructivas.
Guardrails como código. Los hooks PreToolUse bloquean patrones peligrosos (solicitudes a credenciales de prod, 0.0.0.0/0 en un security group, comodines IAM). El máximo de turnos se limita por tipo de tarea: 5 para revisión de PR, 15 para diagnóstico de bug, 25 para drift multi-módulo. Eso es lo que salva de los bucles infinitos con error que se acumula.
Documentación como contrato con el agente. Wikis, runbooks y CLAUDE.md ya no son solo onboarding para personas, sino también contexto RAG para el modelo. Una buena documentación rinde dos veces: el equipo la lee en las rotaciones, el agente la lee en cada solicitud.
Por qué la responsabilidad no se delega
Los failure modes de producción de los agentes de IA son conocidos y se repiten. Hallucinated tool calls — invocar la API equivocada con parámetros plausibles. Reasoning gaps — un informe seguro de «deployed» allí donde no hubo deploy. Over-permissioning — el acceso root se convierte en DROP DATABASE pese a un «never touch prod» en el prompt. Compounding errors — un error pequeño en un paso temprano crece en cascada a través de una cadena de diez tool calls.
Cada uno de estos failure modes no es un «a veces ocurre», sino una condición de operación: hay que esperarlos y construir defensas alrededor. El ingeniero en el bucle no es un favor al agente, es la condición bajo la cual se puede conectar el sistema a producción.
Lo que no ha cambiado
Los pipelines siguen teniendo que escribirse. Los clústeres siguen teniendo que configurarse. Producción sigue cayéndose a las dos de la madrugada, y al teléfono responde una persona, no el modelo. El trabajo en sí no ha cambiado; lo que ha cambiado es el reparto de horas dentro de él. Menos sintaxis, más juicio; menos teclear, más revisión; menos «saber cómo», más «saber cuándo y por qué».
La alfabetización en cloud no es saberse los comandos de memoria. Es la capacidad de tomar una decisión cuyas consecuencias viven más que la sesión de cualquier agente.