Rootly advierte: la IA puede dejar sin práctica a tus SREs

La paradoja que Bainbridge ya vio en 1983

En 1983, la investigadora de factores humanos Lisanne Bainbridge publicó un ensayo que llevaba décadas durmiendo en los archivos académicos y que hoy se lee como una advertencia operativa: The Ironies of Automation. Su tesis era incómoda: cuanto más exitosa es la automatización, menos preparados pueden estar los humanos para el momento en que falla. La automatización reduce las oportunidades de practicar el trabajo rutinario y deja a los operadores responsables de las situaciones nuevas y anormales, que son precisamente las que requieren más habilidad.

Sylvain Kalache, ex SRE de LinkedIn y actualmente en Rootly, retomó esa idea en un post reciente y la aplicó a la siguiente generación de herramientas: los AI SRE, agentes que inspeccionan alertas, formulan hipótesis, consultan telemetría, correlacionan despliegues e incluso implementan el fix por su cuenta. «Son fantásticos en muchos sentidos», escribió. «Se sienten mágicos cuando resuelven un incidente rutinario a las tres de la mañana y no tienes que despertarte por un problema de capacidad». El problema, dice, es que los incidentes rutinarios también son la manera en la que los respondedores desarrollan intuición sobre cómo fallan sus sistemas. Cuando la IA se topa con un incidente ambiguo de alta severidad que no sabe resolver, los ingenieros tendrán que tomar el control con menos práctica que antes.

Kalache lo resume con una frase: vamos a acumular deuda de comprensión (comprehension debt), una brecha creciente entre cómo funcionan nuestros sistemas y cuánto los entienden quienes deben responder cuando se caen.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Cuatro señales de que tu equipo está acumulando deuda de comprensión

El concepto de comprehension debt ganó tracción este año. Kevin Cushnie, líder senior de ingeniería en Modus Create, lo describió en Forbes con cuatro señales operativas que cualquier líder técnico puede leer sin necesidad de un dashboard nuevo.

1. Compresión de revisiones. El tiempo de review por cambio baja más rápido que la complejidad de los cambios. PRs que antes tomaban 30 minutos de revisión sustantiva hoy toman siete, y la confianza del revisor no se ganó esa compresión. Un estudio de Liu et al. sobre 304.362 commits generados con IA en 6.275 repositorios encontró que el 24,2% de los defectos introducidos por IA sobrevive hasta la última revisión: muchos pasaron el filtro.

2. Sequía de decisiones arquitectónicas documentadas. Los ADRs y las minutas de diseño se secan al mismo ritmo al que aumenta el cambio arquitectónico. Servicios nuevos salen a producción sin una rationale registrada. Escribir un decision record para un cambio que no razonaste personalmente se vuelve incómodo, y el camino más fácil es no escribirlo.

3. Arqueología de incidentes. Los post-mortem empiezan a citar «la intención original del código no es clara» o «el historial de cambios no explica por qué se implementó así» como factores contribuyentes. La pregunta «¿qué intentaba lograr el ingeniero?» se responde con «el ingeniero estaba aprobando un output, no produciendo uno».

4. La respuesta evasiva. La señal más difícil de medir. Los seniors, cuando se les pide recorrer un sistema que nominalmente les pertenece, empiezan a abrir documentación, activar el asistente de IA o diferir a un compañero. El recorrido confiado de cinco minutos se convirtió en una reconstrucción negociada de diez.

Cushnie cruza estas señales con números: el volumen de PRs subió 20%, los incidentes de producción por PR subieron 23,5%, y la confianza de los desarrolladores en la precisión del código generado por IA cayó de 40% en 2024 a 29% en 2025, incluso con adopción por encima del 84%. Un ensayo controlado randomizado de Anthropic con 52 ingenieros encontró que los desarrolladores asistidos por IA obtuvieron 17% menos en quizzes de comprensión y no mostraron una reducción estadísticamente significativa en el tiempo de completion.

Qué están haciendo los equipos que lo detectan a tiempo

Kalache propone mirar a la aviación. La automatización de cabina maneja la mayor parte del vuelo, pero los pilotos siguen siendo responsables de las situaciones que la automatización no puede gestionar: falla de motor, instrumentos poco confiables, abortaje de despegue, pérdida. Esos eventos son raros — los motores modernos de turbina experimentan menos de un in-flight shutdown por cada 100.000 horas de vuelo —, así que un piloto comercial puede completar toda su carrera sin ver uno fuera de un simulador. Pero cuando ocurre, la reacción tiene que ser rápida y correcta. Por eso la FAA exige a los capitanes recurrent training o un chequeo de proficiencia cada seis meses, incluyendo escenarios como falla de motor en despegue.

La industria del software está empezando a aplicar la misma lógica. Rootly, plataforma de on-call e incident management con clientes como NVIDIA, Replit, Canva y DoorDash, se asoció con Uptime Labs para correr simulaciones realistas de incidentes. Los ingenieros se sientan en la silla de incident commander durante un corte de e-commerce simulado, usan herramientas de observabilidad y coordinan con stakeholders impulsados por LLM dentro de Slack. El ejercicio fuerza las habilidades que importan cuando el Slack de verdad se enciende: leer información incompleta, comunicar con claridad, coordinar personas y sostener el comando.

En julio de 2026, Rootly también anunció la adquisición de ThinkHive, una plataforma de confiabilidad para agentes de IA fundada por Nour Alkhatib y Abdulwahab Omira tras su paso por Instacart. La operación lleva la ingeniería de confiabilidad al terreno de los workloads LLM: detectar alucinaciones y drift antes de que toquen un incidente real, agrupar fallas en patrones en lugar de una pared de quejas individuales, y validar fixes con shadow testing antes de que lleguen al usuario. El CEO de Rootly, JJ Tang, lo enmarcó así: «Cuando un agente da una respuesta equivocada a escala, eso es un incidente, y la mayoría de los equipos todavía no lo ve».

¿Qué significa esto para tu startup?

Si estás construyendo producto y usás agentes de IA para responder incidentes, dormirás mejor en la noche. El problema aparecerá después, en el primer SEV0 raro que la IA no sepa manejar, cuando tu equipo tenga que intervenir sin haber practicado lo suficiente.

Acciones concretas que puedes tomar este trimestre:

Mantené a tus ingenieros en el loop de incidentes reales, aunque la IA resuelva el 80%. Asigná rotación: una guardia semanal en la que un engineer senior no resuelve, pero observa cada paso del agente y puede interrumpir. Es el equivalente a que el piloto manual supervise al autopiloto.
Convertí los post-mortems en ejercicios de arqueología activa. No solo «¿qué se rompió?», sino «¿alguien en este equipo puede explicar cómo funciona este servicio sin abrir la documentación?». Si la respuesta es no, esa brecha es tu próxima hiring priority disfrazada.
Corré simulaciones de incidentes con stakeholders humanos o LLM que respondan con información incompleta. No es lujo de empresa grande: con Slack, un runbook y un bot puedes correr un drill de 45 minutos que tu equipo recordará seis meses. Rootly y Uptime Labs ya ofrecen esto como producto y un grupo inicial de clientes lo está probando en producción.
Pedile al agente que explique, después de cada incidente, qué señales miró y por qué. Explicación no sustituye práctica, como bien apunta Kalache, pero deja un rastro que después sirve para entrenar al siguiente ingeniero que tome la guardia.
Mirá las cuatro señales de Cushnie antes de mirar el dashboard de uptime. Review compression, sequía de ADRs, arqueología de post-mortems y respuestas evasivas son los termómetros tempranos. Si aparecen dos o más en el mismo trimestre, tenés un problema de comprensión acumulado que el próximo incidente va a hacer visible.

Conclusión

La automatización no es el problema. El problema es asumir que automatizar es gratis. Como escribió Kalache cerrando su post, «esa es la ironía de la automatización: cuanto más exitosa se vuelve, menos preparados pueden estar los humanos para el momento en que falla». La lección para founders no es resistir a los AI SREs, sino diseñar la transición con la misma seriedad con la que la aviación diseñó su programa de recurrent training: dejar que la máquina vuele, pero asegurar que un humano certificado siga tomándole examen al simulador cada seis meses.