AI fatigue en desarrollo: lo que la evidencia sostiene y lo que ya no

Hace unos meses circuló un estudio de Boston Consulting Group sobre "AI brain fry", la fatiga cognitiva de supervisar demasiadas herramientas de IA a la vez. El hallazgo se repitió en decenas de posts como prueba de que más herramientas de IA es peor. El estudio existe, se puede leer completo y sus cifras principales se sostienen. Pero alrededor de él se acumularon otras citas (sobre todo un ensayo de METR con desarrolladores) que ya no dicen lo que decían cuando se publicaron por primera vez. Vale la pena separar una cosa de la otra antes de rediseñar tu stack basándote en un titular.

El estudio de BCG existe, y buena parte de sus cifras se sostienen

El artículo "When Using AI Leads to Brain Fry", publicado en Harvard Business Review en marzo de 2026 por un equipo de BCG liderado por Julie Bedard, encuestó a 1.488 trabajadores a tiempo completo en grandes empresas de Estados Unidos. Define AI brain fry como la fatiga mental que resulta de usar, interactuar con o supervisar IA más allá de la capacidad cognitiva del usuario, y la distingue explícitamente del burnout: el burnout es agotamiento emocional acumulado, el brain fry es una sobrecarga aguda de atención y memoria de trabajo.

Los números que circularon son reales: un 14% de media reporta brain fry, con picos en marketing (26%) y RR.HH. (19%), y desarrollo de software por encima de la media general. Quienes lo experimentan muestran un 33% más de fatiga de decisión, un 39% más de errores graves (11% más en errores menores) y un 34% de intención activa de dejar la empresa frente a un 25% en quienes no lo reportan. Sobre el número de herramientas: la productividad percibida sube al pasar de una a dos, se estabiliza con una tercera y cae a partir de la cuarta. Los propios autores lo describen como una señal temprana concentrada en quienes ya hacen orquestación de múltiples agentes.

Dicho esto, conviene leer la letra pequeña. Todos los datos son autorreportados: no hay medición objetiva de errores ni de productividad, solo percepción de los propios trabajadores. El diseño es transversal, así que no distingue si el brain fry es un estado permanente o una fase de adaptación a herramientas nuevas que remite con el tiempo. Y BCG es una consultora que vende precisamente transformación con IA, lo que no invalida el hallazgo pero sí pide cautela al tratarlo como verdad definitiva. El propio estudio matiza además que cuando la IA elimina tareas rutinarias, el burnout de esos mismos trabajadores baja un 15%: el problema no es la IA en sí, es la supervisión sin límite.

METR: la cifra que definió el debate no se sostiene en su propio seguimiento

El dato más citado sobre "la IA hace más lentos a los developers" viene de un ensayo controlado de METR publicado en julio de 2025: 16 desarrolladores experimentados de código abierto, trabajando en sus propios repositorios maduros, completaron 246 tareas y resultaron un 19% más lentos usando herramientas de IA (principalmente Cursor Pro con Claude 3.5 y 3.7 Sonnet) que sin ellas. Lo más citado del estudio no es solo la cifra, sino la brecha entre percepción y realidad: antes de empezar, los participantes estimaban que la IA los haría un 24% más rápidos, y después de medir que en realidad fueron más lentos, seguían creyendo que les había ayudado un 20%.

Lo que casi nadie repite es que METR publicó en febrero de 2026 los resultados de un segundo experimento, iniciado en agosto de 2025 con 10 desarrolladores del estudio original más 47 nuevos. No es una corrección del estudio de 2025 sino un experimento posterior con diseño distinto, y sus números no replican aquel 19%: el estimado global del nuevo estudio es un -18% con un intervalo de confianza de -38% a +9%, y entre los desarrolladores recién reclutados un -4% (intervalo de -15% a +9%); ambos intervalos cruzan el cero. La parte más citable del post es otra: la propia METR califica esa nueva medición como una señal poco fiable, porque cada vez más desarrolladores declinan participar si no pueden usar IA (lo que sesga a la baja el estimado del nuevo estudio), la retribución bajó de 150 a 50 dólares por hora, y medir el tiempo por tarea se vuelve poco fiable cuando un participante supervisa varios agentes en paralelo. Están rediseñando el experimento para asignar el uso de IA por desarrollador completo, no por tarea.

La lección no es que la IA definitivamente no ralentice a nadie, ni lo contrario. Es que la cifra del 19%, la que se sigue citando como si fuera un hecho estable, no se replica en el seguimiento de la propia METR, y la organización describe su medición más reciente como poco fiable en ambas direcciones. Si un post o un hilo de LinkedIn usa hoy ese número como verdad cerrada, está citando una foto fija de una investigación que su autor considera abierta.

Anthropic: el problema no es usar IA, es cómo delegas

Otra evidencia experimental relevante es la de Anthropic, "How AI Impacts Skill Formation", con 52 ingenieros mayoritariamente junior con más de un año de experiencia en Python. Todos aprendieron Trio (una librería de concurrencia que ninguno conocía), la mitad con un asistente de IA y la mitad sin él. Después, sin acceso a IA, respondieron un cuestionario de 14 preguntas sobre depuración, lectura de código, escritura y conceptos.

El grupo que usó IA promedió 50% en el cuestionario frente a 67% del grupo que programó a mano, 17 puntos porcentuales de diferencia, con la brecha más marcada en preguntas de depuración. La ganancia de velocidad durante la tarea fue de apenas dos minutos de media, sin significancia estadística: el grupo con IA no fue notablemente más rápido, solo aprendió menos. El matiz importante viene de un análisis exploratorio sobre submuestras pequeñas, que muestra asociaciones y no causalidad: quienes usaron la IA para resolver dudas conceptuales puntuaron 65% o más, mientras que quienes delegaron directamente la generación de código quedaron por debajo del 40%. Los propios autores avisan que este experimento usa un asistente conversacional, no un agente autónomo como los que orquestan cambios multiarchivo, y que en herramientas agénticas el efecto sobre el aprendizaje es probablemente mayor.

Lo que muestran las encuestas grandes de desarrolladores

Más allá de los tres estudios anteriores, la foto de conjunto la dan las encuestas grandes. La Stack Overflow Developer Survey 2025 encontró que el 84% de los desarrolladores usa o planea usar IA, pero la confianza cayó a un 29% (frente a un 46% que directamente desconfía de la precisión de los resultados), con los desarrolladores más experimentados como los más escépticos. La frustración más citada, por un 66% de encuestados, es lidiar con soluciones "casi correctas pero no del todo", y un 45% dice que depurar código generado por IA le cuesta más tiempo que escribirlo desde cero. Entre quienes usan agentes, un 69% reporta ganancia de productividad personal, pero solo un 17% dice que los agentes hayan mejorado la colaboración en equipo: el beneficio es individual, no organizativo.

El informe DORA 2025 aporta la foto organizativa: la adopción de IA alcanzó el 90% de los profesionales encuestados, con una mediana en torno a las dos horas diarias de uso, y su tesis central es que la IA no arregla ni rompe nada por sí sola, sino que amplifica las condiciones del sistema en el que aterriza: los equipos con flujos claros capitalizan la velocidad extra, y los que ya arrastraban fricción la ven multiplicada. Esa lectura conecta con el brain fry de BCG desde otro ángulo: el coste de coordinar y supervisar más trabajo en paralelo no desaparece porque cada tarea individual sea más rápida.

Qué hacer con esto: criterios para consolidar el stack basados en evidencia

Juntando lo que se sostiene, la señal más consistente entre fuentes (aunque todavía con datos preliminares y en buena parte autorreportados) no apunta a cuántas herramientas tienes instaladas, sino a cuántos agentes autónomos supervisas al mismo tiempo. BCG señala la orquestación multiagente como el origen del problema, DORA describe cómo la IA multiplica la fricción organizativa preexistente, y el seguimiento de METR ya no sostiene que el simple hecho de usar IA te haga más lento. El criterio útil no es "máximo tres herramientas", una regla que suena precisa pero descansa en datos autorreportados y transversales. Es más bien: reduce el número de flujos de trabajo autónomos que revisas en paralelo en un momento dado, aunque uses varias herramientas a lo largo de la semana con roles distintos.

El hallazgo de Anthropic da un segundo criterio, más operativo: la diferencia no está en usar o no usar IA, sino en para qué la usas. Preguntarle por qué algo falla o cómo funciona un concepto no se asoció con peor comprensión; delegar directamente la generación de código sin revisión sí se asoció con peores resultados en el cuestionario. Esto conecta con el dato de Stack Overflow sobre desconfianza: los desarrolladores más experimentados son los que menos confían ciegamente en el output, y probablemente por eso son también los que retienen mejor sus habilidades.

El tercer criterio es epistémico, y es el que motiva este propio repaso: antes de citar una cifra viral sobre productividad con IA, vale la pena comprobar si quien la publicó la ha revisado después. El 19% de METR circuló durante meses como un hecho establecido; hoy la propia METR no lo replica y describe su medición más reciente como una señal poco fiable. La fatiga real de herramientas de IA no se combate memorizando el número mágico de apps permitidas, sino auditando con la misma exigencia con la que se pide auditar el código que la IA te entrega: mirar la fuente, la fecha y si su autor la sigue sosteniendo.