¿La IA ralentiza a los desarrolladores? Dentro del ensayo controlado del 19 % de ralentización

La sensación más seductora del trabajo de software moderno es ver aparecer cincuenta líneas de código repetitivo en segundos. Esa síntesis instantánea crea una poderosa impresión de velocidad, y el vídeo la convierte en números: los investigadores de aprendizaje automático predecían una aceleración del 38 %, los economistas un 39 %, y los propios desarrolladores un 24 %. El ensayo controlado aleatorizado de METR invirtió el signo. Las tareas realizadas con asistencia de IA tardaron de media un 19 % más. La explicación ofrecida es una heurística cognitiva: los desarrolladores recuerdan vívidamente los segundos dedicados a dar instrucciones a un modelo, pero descuentan sistemáticamente los treinta minutos posteriores dedicados a auditar casos límite, perseguir alucinaciones y arreglar pruebas unitarias rotas. Juzgar por el flujo o la velocidad de tecleo oculta dónde se produce el verdadero drenaje de productividad en entornos profesionales complejos.

El estudio se planteó deliberadamente sobre terreno difícil. Entre febrero y junio de 2025, 16 mantenedores senior con unos cinco años de historial en sus propios repositorios completaron 246 incidencias reales del backlog. El escenario: 14 repositorios de código abierto maduros y emblemáticos como scikit-learn y transformers, con una media de más de un millón de líneas de código, unos diez años de historial y alrededor de 23.000 estrellas. Cada incidencia se asignaba aleatoriamente a la condición «IA permitida» o «IA prohibida» solo después de que el desarrollador hubiera pronosticado su dificultad, y la condición «IA permitida» se apoyaba principalmente en Cursor Pro con Claude 3.5 y 3.7 Sonnet. Para aislar el efecto causal, el análisis utilizó una regresión log-lineal controlando esos pronósticos previos a la asignación, absorbiendo la enorme varianza entre un arreglo de cinco minutos y un cambio arquitectónico de diez horas, y dejando la ralentización del 19 % como estimación causal. La familiaridad no era la culpable: el 44 % de los participantes ya usaba con regularidad el IDE potenciado por IA, y las grabaciones de pantalla mostraron que las herramientas se usaron en más del 83 % de las tareas con IA permitida.

Lo más llamativo es lo obstinada que se mantuvo la percepción. Antes de empezar, los desarrolladores pronosticaban un ahorro de tiempo del 24 % gracias a la IA; al terminar, seguían estimando un ahorro del 20 %. En realidad eran un 19 % más lentos. Los expertos externos eran aún más optimistas, prediciendo duraciones un 39 % menores en economía y un 38 % en aprendizaje automático. Eso no significa que los pronósticos fueran inútiles. La correlación de Pearson entre la duración prevista y la real fue de 0,59 a 0,64, así que los desarrolladores sabían qué incidencias eran más difíciles; simplemente se equivocaron en el signo de la contribución de la IA. El error de pronóstico fue colectivo, no idiosincrático, y sobrevivió a la experiencia directa.

Para ver a dónde fue el tiempo, los investigadores etiquetaron a mano 143 horas de grabaciones de pantalla con una resolución de unos diez segundos, aproximadamente el 29 % del tiempo total en tarea. La línea base sin IA para los expertos es un 41 % programando activamente y un 36 % leyendo y buscando información. En la condición con IA esa base productiva se reduce. El seis por ciento del tiempo total se destina a dar instrucciones al modelo, el cuatro por ciento a esperar las generaciones, y otro nueve por ciento a revisar, depurar y reparar la salida del modelo. La carga de auditoría refleja una baja fiabilidad: los desarrolladores tuvieron que rehacer sustancialmente o rechazar de plano el 56 % de las sugerencias de la IA, menos del 44 % se aceptaron tal cual, y el 75 % declaró leer cada línea del código generado. Los pequeños ahorros en tiempo de escritura quedaron más que compensados por el bucle de revisión, reasignando el esfuerzo cognitivo del pensamiento constructivo sobre el sistema a una verificación agotadora.

Por qué los repositorios maduros resisten la ayuda es el argumento central del vídeo. A esta escala, la ingeniería consiste sobre todo en leer: escanear arquitecturas intrincadas, detectar acoplamientos delicados entre subsistemas y respetar invariantes no escritos que mantienen el sistema estable. Estos proyectos dependen de un contexto implícito del repositorio, de modismos estilísticos y de reglas específicas del dominio que viven en la cabeza de los mantenedores y no están especificadas explícitamente para que un modelo pueda procesarlas. Las ventanas de contexto locales batallan con tales dependencias no locales, de modo que incluso modelos de frontera como Claude 3.7 a menudo fracasan a la hora de mantener el estilo idiomático en una base de código de un millón de líneas. El modelo tiende a producir código de apariencia plausible que ignora cómo un cambio en un módulo desencadena fallos en cascada a lo largo del grafo de dependencias. El vídeo lo captura como un desarrollador junior que teclea a velocidad sobrehumana pero con una despreocupación total, obligando a los senior a gastar más energía corrigiendo la alucinación de lo que habría costado escribir desde cero.

Situar el resultado en la base de evidencia más amplia aclara cuándo aplica la ralentización. Un documento de trabajo del NBER de mayo de 2026 que sigue a más de 100.000 desarrolladores de GitHub constata que el autocompletado eleva los commits en torno a un 40 %, los agentes interactivos hasta un acumulado del 140 %, y los agentes autónomos hasta el 180 %, pero las ganancias se atenúan con fuerza al subir en la jerarquía de producción: un 50 % para proyectos y un 30 % para releases, con líneas de código un 741 % al alza pero releases solo un 20 % más. El patrón encaja con un modelo de eslabón débil con una elasticidad de sustitución de 0,25 entre el esfuerzo de la IA y el humano. Un estudio observacional de dosis-respuesta sobre 16.223 ingenieros de Microsoft estima un 40,5 % más de pull requests en las semanas de mayor uso de Copilot a igual tiempo de programación. Un estudio de caso longitudinal en una empresa con 802 desarrolladores bajo un mandato de mediados de 2025 de duplicar las pull requests fusionadas por ingeniero sí alcanzó 2,09 veces la línea base previa al mandato en abril de 2026, pero la carga por revisor se duplicó aproximadamente y la cobertura de revisión automatizada pasó de cerca del 19 % a cerca del 84 % mientras la revisión humana se adelgazaba. La telemetría de JetBrains a lo largo de dos años con 800 desarrolladores muestra que los usuarios de IA añaden 587 caracteres al mes frente a 75 de los no usuarios, junto con más borrados y más cambios de contexto. La ralentización de METR ocupa, por tanto, un rincón específico: existen aceleraciones reales para el trabajo rutinario y el código en terreno virgen, pero para el mantenimiento de alta familiaridad y altos estándares, la aceleración se convierte en deuda de revisión.

La lección del vídeo es redefinir la velocidad profesional como velocidad de verificación en lugar de velocidad de redacción. En los sistemas maduros, el cuello de botella no es la rapidez con que se produce el texto, sino la rapidez con que se puede establecer la corrección, así que las herramientas futuras deberían ir más allá de la autocompletación hacia una verificación autónoma en entornos aislados locales e interfaces que minimicen el esfuerzo de revisión humana en lugar de maximizar el volumen generado. La ilusión es persistente; incluso después de cientos de horas, los desarrolladores seguían creyendo que eran un 20 % más rápidos. Un seguimiento de febrero de 2026 con la misma metodología apunta a un aprendizaje, con el subgrupo de participantes originales estimado en menos 18 % y un intervalo amplio que cruza el cero, mientras que los desarrolladores recién reclutados se sitúan cerca de menos 4 %. La conclusión se mantiene: el progreso vendrá menos de una máquina que escribe más rápido y más de un sistema que ayuda a los humanos a demostrar que el código funciona.