La mejor persona de operaciones con la que trabajé pasaba la mayor parte de su tiempo leyendo un libro en su escritorio. Los deploys — releases automatizados de código nuevo a servidores en producción — salían a tiempo. Resolvía incidentes antes de que alguien los notara. El onboarding de nuevos empleados funcionaba como reloj suizo.

Su jefe casi la despide por "no verse suficientemente ocupada."

No estaba ociosa. Había terminado.

La brecha de la que nadie habla

La cultura laboral premia el esfuerzo visible. El desarrollador que teclea furiosamente parece productivo. El que se queda mirando al techo veinte minutos — pensando en la arquitectura — parece flojo. La persona que responde correos a las 11 PM se gana el título de "comprometida." La que se va a las cinco se gana el de "le vale."

Un estudio de 2022 de investigadores de Columbia, Georgetown y Harvard confirmó lo que la gente de ops ya sabía: los managers calificaron consistentemente a los empleados que "se veían ocupados" como más competentes, incluso cuando su producción real estaba por debajo de la de colegas más tranquilos. Premiamos la apariencia de trabajo, no el trabajo en sí.

El 12 de marzo, PagerDuty presentó su SRE Agent como respondedor virtual — software que detecta caídas, ejecuta diagnósticos y sigue procedimientos de reparación sin que un humano toque el teclado. Cuatro días después, en GTC el 16 de marzo, NVIDIA anunció el Agent Toolkit con OpenShell — infraestructura para ejecutar agentes de operaciones autónomos de forma segura en producción. El 24 de marzo, en el YC Demo Day, startups como IncidentFox presentaron la respuesta autónoma a incidentes como su producto entero. La señal del mercado: si una tarea sigue un patrón predecible, un humano no debería hacerla a mano.

Lo cual plantea una pregunta que los equipos de ops en todas partes enfrentan ahora: si los agentes de IA — programas que actúan por su cuenta, tomando decisiones y ejecutando pasos sin supervisión humana constante — se encargan del firefighting visible, ¿qué hace una persona de ops todo el día?

La respuesta no ha cambiado. Pero la presión por entenderla, sí.

En operaciones, la vieja estructura de incentivos crea una dinámica perversa — un sistema que premia exactamente el comportamiento equivocado. Si tu empresa te valora por apagar incendios, tienes cero motivación para prevenirlos. Si tu jefe mide tu valor por cuántos mensajes urgentes de Slack atiendes, construir sistemas que eliminen esos mensajes te hace ver prescindible. Y ahora los agentes de IA también apagan incendios. Más rápido. Sin dormir. Sin quejarse.

La paradoja en el corazón de ops

Mientras mejor eres en operaciones, menos parece que haces. Un bombero que previene incendios parece desempleado. Una persona de ops cuyos sistemas nunca se caen parece que está de floja. El trabajo visible desaparece precisamente porque alguien hizo bien el trabajo invisible.

He visto este patrón repetirse por años. A la persona de ops que automatiza su trabajo le preguntan: "¿Qué haces todo el día?" A la que maneja cada incidente manualmente, trabajando jornadas de doce horas, la ascienden por "ponerse la camiseta."

Una construyó un sistema. La otra construyó una dependencia de sí misma. Pregúntate cuál necesita realmente la empresa — y a cuál reemplaza primero un agente de IA.

Cómo se ven las buenas operaciones en la práctica

El buen trabajo de operaciones ocurre en dos fases.

Fase 1: Construir los sistemas. Esta parte es visible y tiene tiempo limitado. Escribir runbooks — guías paso a paso para manejar situaciones específicas. Configurar monitoreo — verificaciones automatizadas que detectan problemas antes de que los usuarios los noten. Crear automatización para tareas repetitivas. Documentar procesos para que cualquiera pueda seguirlos. Esta fase es intensa: típicamente de dos a seis meses de trabajo enfocado.

Fase 2: Mantener los sistemas. Aquí es donde empieza la confusión. Los sistemas corren. Las alertas se disparan y los runbooks las manejan — cada vez más, los agentes de IA ejecutan esos runbooks sin intervención humana. Los nuevos empleados se integran solos a través de procesos documentados. Los deploys fluyen por pipelines de CI/CD — secuencias automatizadas que mueven código desde la laptop de un desarrollador hasta servidores de producción sin pasos manuales.

El trabajo de la persona de ops en la Fase 2: observar patrones que sugieran que un sistema se está degradando. Hacer post-mortems — revisiones estructuradas de qué salió mal y por qué. Planificar capacidad futura. Decidir qué nuevos procesos delegar a agentes y cuáles aún requieren juicio humano. Leer. Aprender. Pensar.

Esa última parte parece "no hacer nada." Pero una persona de ops que no estudia nuevas herramientas, modela escenarios de falla, evalúa qué frameworks de agentes se adaptan a su infraestructura y planifica para situaciones que aún no han ocurrido, quedará en desventaja cuando ocurran. El manual de Site Reliability Engineering de Google lo dice sin rodeos: el trabajo es diseñar confiabilidad, no recuperarse heroicamente de su ausencia.

Estar ocupado es un bug report

Voy a decir lo que todos piensan pero nadie dice: estar constantemente ocupado señala sistemas rotos, no dedicación.

¿Siempre apagando incendios? Tus sistemas de prevención fallaron. ¿Siempre cambiando de contexto — saltando entre tareas sin relación cada pocos minutos? Tu priorización falló. ¿Siempre en reuniones? Tus sistemas de comunicación fallaron. ¿Siempre capacitando gente nueva a mano? Tu onboarding falló.

"Ocupado" no es un estado al que aspirar. "Ocupado" es un bug report.

El objetivo de operaciones — y honestamente, de la mayoría del trabajo de conocimiento — es llegar a un estado donde los sistemas manejen el noventa por ciento predecible y tú tengas ancho de banda para el diez por ciento impredecible. Esa franja impredecible es donde importa el juicio humano. Todo lo demás debería funcionar solo. En marzo de 2026, "funcionar solo" cada vez más significa que un agente de IA lo ejecuta — y la persona de ops que construyó el sistema decide qué debe y qué no debe tocar el agente.

El camino de salida

Si estás ahogándote en trabajo operativo ahora mismo, aquí va una secuencia práctica.

Semanas 1–2: Registra todo. Cada tarea, cada interrupción, cada problema recurrente. No arregles nada todavía. Solo observa.

Semanas 3–4: Categoriza. ¿Qué se repite? ¿Qué sigue un patrón? ¿Qué podría manejar un script — un pequeño programa que automatiza un paso manual — una checklist, o un agente de IA? Típicamente, del sesenta al setenta por ciento del trabajo operativo cae en "predecible y automatizable."

Semanas 5–8: Automatiza o documenta los diez principales consumidores de tiempo. Uno por semana. Empieza con lo que más te interrumpe. Para respuesta a incidentes — el proceso de detectar y corregir caídas — considera triage con agentes: herramientas como el SRE Agent de PagerDuty o alternativas open-source manejan incidentes que siguen patrones y te escalan los nuevos.

Mes 3: Ahora tienes entre cuarenta y cincuenta por ciento más de ancho de banda. Inviértelo en el siguiente nivel de problemas.

Mes 6: Estás leyendo un libro en tu escritorio. Tus sistemas corren. Tus agentes manejan lo predecible. Pareces ocioso. No estás ocioso. Terminaste.

Una nota para los managers

Si tu mejor persona de ops se ve aburrida, felicidades. Tus sistemas funcionan. No le asignes trabajo innecesario para justificar su salario. No la hagas montar teatro de productividad — esa actuación frenética de verse ocupado para satisfacer la expectativa de alguien sobre cómo debería verse "trabajar duro."

En vez de eso, pregúntale: "¿Qué construirías si tuvieras tres meses de tiempo ininterrumpido?" Y luego dale esos tres meses. Lo que construya va a ahorrar más que cualquier cantidad de ocupación visible.

La persona más productiva en tu empresa podría ser la que parece hacer menos. Eso no es una paradoja. Así se ve haber terminado.