Y por qué tu ingeniero más valioso podría ser el próximo en renunciar
Hay una métrica que tu dashboard de ingeniería no te está mostrando.
Y no es velocity, ni frecuencia de deployment, ni siquiera calidad de código.
Es cuántas decisiones tomó tu senior developer hoy.
Ese número nunca aparece en una retrospectiva de sprint y, sin embargo, hoy puede ser la señal más importante de toda tu organización.
Los últimos dos años los pasamos obsesionados con lo que la IA puede hacer por los equipos de software: las líneas de código que genera, los features que salen en la mitad del tiempo, los developers junior que de golpe rinden por encima de su nivel.
De lo que casi nadie habla es de qué le pasa a la persona sentada en el medio de toda esa velocidad.
De eso trata este artículo.
La Historia de Productividad que Nos Seguimos Contando
La narrativa alrededor de las herramientas de coding con IA fue abrumadoramente positiva, y con razón. Las mejoras son reales.
GitHub reporta que los developers que usan Copilot completan tareas hasta un 55% más rápido. Los equipos con Claude Code o Cursor despachan en días lo que antes llevaba semanas. En algunas empresas AI-native, la mayor parte del código en producción hoy lo genera la IA.
No son estadísticas inventadas. Reflejan un cambio real en lo que puede producir un equipo chico y bien equipado.
Pero los reportes de productividad se saltean la parte que viene después de generar el código.
Alguien todavía tiene que leerlo, juzgar si es correcto, seguro y mantenible, y confirmar que resuelve el problema adecuado. Alguien tiene que atrapar los edge cases que el modelo ignoró y entender cómo encaja este módulo nuevo en un sistema que lleva tres años evolucionando.
Ese alguien es tu senior developer, y lo hace a un ritmo que no tiene precedente.
Qué Es Realmente la AI Fatigue
La AI Fatigue no es burnout en el sentido habitual.
El burnout clásico es un problema de volumen: demasiado trabajo, poco tiempo, sostenido durante meses hasta que la persona se rompe. Es visible, se construye despacio y los equipos suelen verlo venir.
La AI Fatigue es un problema de densidad. Aparece cuando las decisiones por hora suben de golpe mientras el output visible, tipear y reuniones, se mantiene igual o incluso baja.
Una forma útil de pensarlo:
Antes de las herramientas de IA, un senior developer tomaba unas 20 decisiones técnicas importantes por día: decisiones de arquitectura, juicios de code review, calls de debugging, trade-offs de diseño.
Con las herramientas de IA, ese mismo developer toma entre 60 y 80 por día, porque cada output generado exige un veredicto. ¿Acepto o rechazo? ¿Corrijo o dejo? ¿Confío o verifico? ¿Es este realmente el enfoque correcto para nuestro sistema?
Cada micro-decisión parece pequeña por separado. La carga se acumula igual. El cerebro no archiva cuarenta juicios chicos distinto de uno grande, y el agotamiento es agotamiento.
Lo engañoso es que desde afuera no parece fatiga. La velocity está arriba. Los features salen. El dashboard está en verde.
El agotamiento está pasando por debajo de todo eso.
Los Cuatro Síntomas a Observar
1. Accept Fatigue
Este es el peligroso.
Cuando un developer empieza a usar herramientas de coding con IA, lee cada sugerencia con atención: qué produjo el modelo, por qué, y si encaja. Es un colaborador activo.
Después de semanas o meses de trabajo intenso asistido por IA, esa vigilancia se desgasta. No porque haya dejado de importarle, sino porque su capacidad de evaluar está agotada. Empieza a aceptar sugerencias que no leyó del todo y a aprobar pull requests que no revisó a fondo.
Amazon lo aprendió de la peor manera en marzo de 2026, cuando un outage de seis horas en su sitio principal de ecommerce se rastreó hasta deployments asistidos por IA que nunca recibieron revisión humana adecuada. El briefing interno describía a engineers junior y mid-level despachando código generado por IA sin el escrutinio que necesitaba. La respuesta fue exigir sign-off de un senior en cada deployment asistido por IA.
Pero los seniors tampoco son inmunes. Un senior cansado revisando output de IA a las 6pm de un viernes es más peligroso que no tener revisor, porque va a dejar pasar cosas que no debería, y con total confianza.
2. Context Switching Extremo
Las herramientas de IA son rápidas; ese es el punto. En la práctica, rápido significa que un developer puede tener seis workstreams corriendo a la vez, cada uno avanzando con sugerencias que igual necesitan evaluación y dirección.
El costo humano del context switching no desaparece porque la IA haga más de la ejecución. Se multiplica. Ahora una sola persona es el cuello de botella en seis threads concurrentes en lugar de dos o tres.
Cambiar de contexto a esa frecuencia no es solo ineficiente. Agota de una forma que se acumula durante la semana y es casi imposible de nombrar en una retrospectiva.
3. La Sensación de «Nunca Terminás»
Acá hay un efecto psicológico más callado, difícil de medir pero fácil de reconocer una vez que lo viviste:
Cuando una persona escribe código a velocidad humana, la sensación de terminar es natural. Un feature queda hecho. Un bug queda resuelto. La lista se acorta.
Cuando la IA genera a diez veces esa velocidad, el backlog nunca se achica lo suficiente como para sentirlo satisfactorio. Siempre hay más para revisar, otra sugerencia para evaluar, otro módulo que se podría mejorar ahora que generar es barato.
Los goalposts se mueven a velocidad de máquina. El sentido de progreso de la persona, no.
El resultado es una sensación baja pero constante de estar quedándose atrás, incluso cuando el equipo va adelantado. Con el tiempo carcome la motivación en silencio, y se lee como desenganche mucho antes de que alguien lo llame fatiga.
4. Pérdida de Autoría
Este es más difícil de cuantificar, y quizás el más humano de todos.
En su mejor versión, el software es un oficio. Los senior developers sacan satisfacción real de construir cosas que entienden a fondo, trabajo que lleva su juicio, su experiencia, sus huellas.
El código generado por IA cambia esa relación. Un developer puede deployar un módulo que mayormente no escribió, que no leyó completo y que no podría reconstruir de memoria. Funciona. Pero queda una pregunta dando vueltas:
«¿Esto lo construí yo, o lo aprobé?»
Esa diferencia importa: para la motivación, para el aprendizaje y para el expertise profundo que hace difícil de reemplazar a un senior. Cuando la gente deja de sentirse autora y pasa a sentirse revisora de output de máquina, algo importante se erosiona sin que nadie lo note.
Por Qué Golpea Más Fuerte a Tus Mejores Personas
La parte cruel es que la AI Fatigue golpea a la gente que menos podés permitirte perder.
Los developers junior con herramientas de IA se llevan casi toda la ganancia de productividad sin cargar el peso de la revisión. Generan código, parece razonable, lo despachan. El costo downstream, el mantenimiento, la deuda arquitectónica, los edge cases que aparecen en seis meses, todavía no les cae a ellos.
Los seniors cargan con todo. Hacen la revisión profunda. Atrapan lo que el modelo se perdió. Sostienen el modelo mental del sistema al que ninguna herramienta tiene acceso. Son los que deciden a medianoche cuando algo se rompe.
Un survey de Fastly de julio de 2025 encontró que los senior engineers producen casi 2.5x más código generado por IA que los juniors, porque son mejores evaluando y dirigiendo al modelo. Pero casi el 30% de esos seniors dijo que arreglar y revisar ese output se comía la mayor parte del tiempo que habían ahorrado.
Se vuelven más rápidos y más agotados al mismo tiempo.
Lo que Nadie Está Midiendo
Abrí tu dashboard de métricas de ingeniería y probablemente veas:
- Frecuencia de deployment ✓
- Cycle time ✓
- Sprint velocity ✓
- Code coverage ✓
Ahora contestá: ¿cuál es la densidad de decisiones de tu senior developer a las 4pm de un jueves?
¿Cómo se compara su code review del viernes a la tarde con el del lunes a la mañana?
¿Cuántas semanas seguidas lleva operando a máxima intensidad asistida por IA sin un tramo real de recuperación cognitiva?
Nadie mide nada de esto. Es invisible para todos los frameworks de productividad que construimos, porque asumían que el cuello de botella era la velocidad de ejecución, no la calidad de las decisiones.
Movimos el cuello de botella. Nunca actualizamos los instrumentos.
El Riesgo Organizacional que Nadie Está Calculando
Acá es donde deja de ser un tema de bienestar y se vuelve uno de negocio.
En un equipo optimizado con IA, menos headcount, más palanca por persona, menos redundancias, el senior developer ya no es una persona importante entre varias. Es el camino crítico de todo.
Sostiene el conocimiento arquitectónico. Es la compuerta de calidad. Toma las decisiones que la IA no puede tomar. Es el contexto humano que le da coherencia al output del modelo.
Así que cuando esa persona se quema, y quemarse acá va desde un rendimiento en declive hasta una carta de renuncia, el daño no es lineal. No perdés el 20% de la capacidad del equipo. Perdés a la persona que le daba juicio al otro 80%.
El equipo no se desacelera. Se frena.
Y las señales quedan invisibles hasta que dejan de estarlo. El riesgo de retención por AI Fatigue no aparece en las métricas de sprint. Aparece el día que alguien renuncia, y tres meses después, cuando te das cuenta de que nadie puede reconstruir las decisiones arquitectónicas que esa persona tenía en la cabeza.
Qué Podés Hacer Concretamente
Medí lo que importa. Trackeá la calidad del review a lo largo del tiempo, no solo si el review se hizo. Un senior que aprobó 40 PRs en una semana sin objetar nada no es un héroe de productividad; es una señal de alerta.
Diseñá la recuperación dentro del sprint. No solo «el viernes no hay reuniones», sino recuperación cognitiva de verdad: resolución de problemas sin estructura, deep work en una sola cosa y tiempo completamente lejos del output generado por IA. El cerebro necesita tramos regulares en modo no-evaluación.
Repartí la carga de revisión a propósito. En un equipo lean, dejar que toda la presión de revisión caiga sobre un solo senior es una falla estructural, no una prueba de que esa persona es buena en su trabajo. Construí redundancia en la capa de revisión aunque parezca ineficiente.
Hacé visible la autoría. Dales a los developers espacio para construir cosas completamente suyas, de la idea al deployment, con la IA como herramienta pero su juicio manejando cada decisión. No dejes que cada tarea se vuelva una revisión.
Tené la conversación honesta. Preguntales directo a tus seniors: ¿cuántas decisiones tomaste hoy? ¿Cuándo fue la última vez que te sentiste realmente recuperado? ¿Qué tan afilada está tu atención a las 5pm comparada con las 10am? La mayoría ya lo sabe. Solo que nunca se lo preguntaron.
El Problema del Operador
Pasamos dos años afinando la máquina.
Las herramientas son más rápidas. La generación es mejor. La automatización hace más. El equipo es más liviano. Los números de velocity se ven geniales.
Nos olvidamos del operador.
Todo sistema complejo tiene operadores: personas que mantienen la conciencia situacional, toman las decisiones de juicio e intervienen cuando la automatización produce algo que parece correcto pero no lo es. La aviación lo aprendió. La energía nuclear también. La cirugía lo está aprendiendo ahora.
El software es el próximo.
La AI Fatigue es el riesgo ocupacional de ser el humano en el loop cuando el loop corre a velocidad de máquina. No tiene un estándar OSHA, no tiene un protocolo de tratamiento establecido y la mayoría de los sistemas de HR ni siquiera tiene una categoría para eso.
Pero es real. Y si estás liderando un equipo de ingeniería ahora mismo, probablemente lo estés viendo pasar, en un senior developer que técnicamente sigue rindiendo pero parece menos presente, menos curioso, menos afilado que hace dieciocho meses.
Eso no es un problema de personas. Es un problema estructural.
La solución no es desacelerar la IA. Es rediseñar cómo trabajan los humanos junto a ella.
Diego Fiorentin es el fundador de Next2AI, una consultora de IA que ayuda a empresas a implementar IA operacionalmente — primero el negocio, no la herramienta. Este artículo fue adaptado de una charla presentada en el meetup de tecnología 1950Labs en Montevideo, marzo 2026.
Si tu equipo está navegando la transición al desarrollo asistido por IA y estás viendo señales como las descritas acá, agendá una conversación →
