Hace meses, escribí sobre el problema de la medición: la ingeniería de métricas que recompensan el comportamiento incorrecto tras la adopción de la IA. Esa publicación fue un diagnóstico basado en el reconocimiento de patrones entre organizaciones, aumento de velocidad mientras la entrega se mantenía estable, paneles de control que se volvían verdes mientras los productos se enviaban tarde.
Llegaron los datos.
Entre finales de 2025 y mediados de 2026, cinco programas de investigación independientes publicaron hallazgos que convergen a la misma conclusión. Las ganancias individuales de productividad asistidas por IA son reales, medibles y consistentemente no se traducen en una mejora en la entrega organizacional. La brecha entre «los desarrolladores se sienten más rápidos» y «la organización lanza mejor software» ahora tiene cifras asociadas.
Esta publicación no es una secuela en el sentido de repetir el diagnóstico. El diagnóstico se mantiene. Esto trata de lo que revela la validación externa sobre dónde realmente está el cuello de botella y por qué las organizaciones que ven retornos están estructuradas de forma diferente a las que no lo están.
El embudo que se evapora
Los datos más llamativos provienen de un estudio del MIT y el NBER realizado con más de 100.000 desarrolladores de GitHub, publicado a principios de este año. Los investigadores siguieron lo que ocurre con el código asistido por IA a medida que avanza en una cadena de desarrollo.
En el momento de la creación, los desarrolladores asistidos por IA generaban casi un 300% más de archivos que su línea base previa a la IA. Cuando ese código llegó a la revisión, la ganancia se había reducido a la mitad hasta aproximadamente el 150%. En la fase final, los lanzamientos reales de software, el aumento fue de aproximadamente un 30%.
El trescientos por ciento se convierte en treinta por ciento. No porque el código fuera malo. Porque los sistemas organizativos entre la creación y la liberación, los procesos de revisión, las pruebas de integración, las comprobaciones de coherencia arquitectónica y la gobernanza del despliegue, absorbieron la mayor parte del aumento bruto de la producción antes de llegar a los clientes.
Este es el embudo de productividad de IA. Y explica por qué los ejecutivos informan de cosas contradictorias. El CTO que dice «mis desarrolladores son 3 veces más rápidos» está midiendo la parte superior del embudo. El vicepresidente de Producto que dice «todavía vamos tarde en la hoja de ruta» está midiendo el fondo. Ambos tienen razón. La organización simplemente no tiene un mecanismo para convertir uno en otro.
Cinco estudios, un patrón
El embudo del MIT es la ilustración más dramática, pero no está aislado.
DORA 2024 encuestó a más de 39.000 profesionales técnicos y encontró que por cada aumento del 25% en la adopción de IA, las organizaciones experimentaron una disminución del 1,5% en el rendimiento de entrega y una disminución del 7,2% en la estabilidad de la entrega. Los desarrolladores individuales informaron de mayor productividad, mejor flujo y mayor satisfacción laboral. Las métricas a nivel de equipo se movieron en dirección opuesta. El propio equipo de investigación de Google lo calificó de «anomalía» en el informe.
DX hizo un seguimiento de 400+ organizaciones de ingeniería durante 16 meses. El uso de herramientas de IA en esas organizaciones aumentó un 65%. El rendimiento medio de relaciones públicas subió un 7,76%, no el 3 o 10 veces que prometían los proveedores, menos del 8% en el mundo real. Incluso en el percentil 90, los mejores resultados alcanzaron solo el 44%. La brecha entre lo que prometen los proveedores y lo que miden las organizaciones ahora está cuantificada.
El Índice de Referencia de Ingeniería de Cortex 2026 encontró que las solicitudes de extracción por autor aumentaron un 20% interanual, los incidentes por solicitud de extracción un 23,5% y las tasas de fallo de cambio un 30%. La velocidad aumentó. La fiabilidad bajó. Los tiempos de resolución aumentaron porque los equipos tenían dificultades para depurar código que no habían escrito y que no entendían del todo.
La encuesta de CEO de PwC 2026 planteó una pregunta más sencilla: ¿ha mejorado la IA tus ingresos o reducido tus costes en los últimos 12 meses? El cincuenta y seis por ciento de los CEOs no reportó ninguna de las dos cosas. Solo el 12% reportó haber logrado ambos. La clase ejecutiva que aprobó presupuestos de IA ahora está mirando las facturas sin las devoluciones que esperaban.
Un estudio separado del NBER encuestó a 6.000 directivos de cuatro países. El noventa por ciento reportó que no había un impacto significativo en la productividad o el empleo por la IA durante un periodo de tres años. Uso medio de IA por parte de ejecutivos: 1,5 horas por semana a pesar de una tasa de adopción del 69%. Las herramientas se despliegan. La transformación no está ocurriendo.
Cinco programas de investigación, cinco metodologías diferentes, cinco poblaciones distintas, el mismo hallazgo estructural: los avances a nivel individual no se traducen automáticamente en resultados organizativos.
Por qué el embudo se filtra
La explicación tentadora es que el código de IA es de baja calidad. Eso es parte de ello, pero no es suficiente como explicación completa. Los datos de Cortex muestran que los incidentes están aumentando, sí, pero los datos de DX también muestran que las organizaciones en el percentil 90 están obteniendo rendimientos significativos. Algo distingue al 12% del 56%.
La paradoja de la productividad en la tecnología no es nueva. Robert Solow observó en 1987 que «se puede ver la era informática en todas partes menos en las estadísticas de productividad.» La resolución llegó cuando los economistas demostraron que las organizaciones que reorganizaron sus flujos de trabajo en torno a la informática, en lugar de simplemente añadir ordenadores a los trabajos existentes, captaron las ganancias.
Tupper, escribiendo sobre la productividad de TI en Data Architecture (2011), capturó la dinámica en una frase que encaja de forma diferente en 2026: «Los sistemas malos, cuando están automatizados, simplemente te permiten cometer más errores y más rápido. Las ganancias reales en productividad solo se logran cuando hay ciertos facilitadores críticos: un sentido de visión compartida, comunicaciones claras, procesos estables y comprendidos, y un ferviente entusiasmo por la mejora continua.»
Sustituye «ordenador» por «asistente de programación de IA» y la paradoja se resuelve igual.
El embudo se filtra porque las organizaciones añadieron IA a flujos de trabajo existentes sin reestructurarlos en torno a los cambios de IA. El 300% en la creación se traduce en un proceso de revisión diseñado para una producción de código a velocidad humana, la revisión se convierte en un cuello de botella, los revisores ojelan en lugar de leer, los defectos pasan y los incidentes aumentan. El equipo genera más rápido y rompe más mientras el salpicadero muestra la velocidad alta y el sistema se degrada silenciosamente.
El propio ensayo aleatorizado de Google midió una aceleración individual del 21% gracias a herramientas de codificación con IA. Eso es real. Pero es real en el vacío.
Fred Brooks argumentó en The Mythical Man-Month que la programación representa solo una fracción del esfuerzo total de entrega de software. La mayor parte del tiempo del proyecto se dedica a entender requisitos, tomar decisiones arquitectónicas, validar suposiciones y coordinarse con otras personas. Décadas de trabajo empírico desde entonces han confirmado la ratio: el acto mecánico de escribir código representa aproximadamente el 15-20% de lo que realmente requiere un proyecto de software. El resto es pensar, decidir y comunicarse. Un aumento del 21% en el 20% del trabajo produce una mejora del 4% en la entrega total del proyecto. Esa es la matemática que explica por qué el estudio DX muestra un 7,76% y no un 300%. La IA aceleró la parte que nunca fue el cuello de botella.
¿Qué es la participación exitosa del 12%
Los datos de PwC revelan que las empresas que captan los rendimientos de la IA no están gastando menos en IA ni utilizando modelos diferentes. Se centran en el crecimiento más que en la reducción de costes, y han reestructurado cómo fluye el trabajo en sus organizaciones.
El Informe Accelerate State of DevOps 2025 ofrece una pista sobre lo que ha cambiado en un año. Para 2025, la relación de flujo de rendimiento con la adopción de IA se había vuelto positiva, lo que sugiere que los primeros adoptantes habían superado la fricción inicial. Los equipos aprendieron dónde ayuda la IA y dónde genera arrastre. Pero la estabilidad de entrega se mantuvo negativa, lo que significa que el problema de calidad persiste incluso cuando el problema de velocidad se resolvió. La curva de aprendizaje para la generación es más corta que la curva de aprendizaje para la gobernanza.
¿Qué distingue a las organizaciones con resultados positivos en IA de aquellas con resultados planos o negativos? Al analizar los datos, el patrón es notablemente consistente: cambiaron cómo se especificaba el trabajo, cómo se revisaba, cómo operaban los equipos y cómo se medía el éxito.
Definen la intención antes de la generación. Cuando un desarrollador sabe exactamente qué construir, especificado con precisión con criterios de aceptación y restricciones arquitectónicas, el código generado por IA se acerca más al correcto en la primera pasada. La carga de revisión disminuye porque la especificación es el estándar de revisión. El embudo no se evapora porque se necesita menos corrección entre la creación y la liberación.
Validan en el límite organizativo, no solo en el individual. Las métricas individuales (PRs por desarrollador, líneas generadas, historias cerradas) están subordinadas a las métricas de entrega (frecuencia de despliegue, tasa de fallo de cambio, tiempo de restauración, tiempo de ciclo según el valor del cliente). Esto evita la dinámica que describí en el problema de medición: cada uno es productivo individualmente, colectivamente ineficaz.
Tratan el código generado por IA como una categoría de reseña diferente. Cuando un humano escribe código, construye comprensión mientras escribe. Cuando la IA genera código, nadie tiene ese entendimiento todavía. La carga de la revisión es estructuralmente diferente. Las organizaciones que reconocieron esto y reestructuraron sus procesos de revisión en torno a ello captaron los avances. Quienes aplicaron el mismo proceso a un artefacto fundamentalmente diferente obtuvieron los números de Cortex: más código, más incidentes, tiempos de resolución más largos.
Miden las decisiones mejoradas, no los tokens consumidos. Gartner descubrió que el 84% del gasto empresarial en IA se centra en la productividad individual, mientras que solo el 16% se centra en los resultados empresariales. Las organizaciones del 12% cambiaron esa proporción. Preguntaron «¿Nos ayudó la IA a tomar una mejor decisión arquitectónica?» no «¿ayudó la IA a este desarrollador a escribir código más rápido?»
La tesis de amplificación, validada
En mi publicación anterior sobre las cuatro capas de las organizaciones de ingeniería impulsadas por IA, argumenté que la IA amplifica lo que ya tienes: los sistemas alineados aceleran, los sistemas desalineados aceleran la disfunción. Los datos de DORA validan esto con precisión. Equipos con bases sólidas, pequeños lotes, pruebas robustas y una clara propiedad, veían la IA como un acelerador. Los equipos sin esos cimientos lo veían como un amplificador de sus problemas existentes.
La paradoja de la productividad es una medida de la preparación organizativa. La IA no creó la brecha entre generación y entrega, la hizo visible, medible y lo suficientemente cara como para que ignorarla se convirtiera en un problema a nivel de placa.
Qué significa esto para los líderes de ingeniería
Si tu organización ha desplegado herramientas de codificación por IA en los últimos 12-18 meses y tus métricas de entrega no han mejorado proporcionalmente, no estás solo. Tú eres la mediana. El 7,76% del estudio DX en la mediana representa el resultado cuando la IA se añade a procesos existentes sin cambios estructurales.
La resolución no es mejor IA. La resolución es la misma que resolvió la paradoja de Solow hace treinta años: reorganizar el trabajo en torno a lo que realmente cambia la tecnología.
Eso significa aceptar que el cuello de botella se movió. Nunca fue generación de código, siempre fue definición de intención, juicio arquitectónico y validación, y la IA lo hizo visible eliminando la restricción en la que todos se centraban. Las organizaciones que se reestructuraron en torno al verdadero cuello de botella captaron las ganancias. Los que siguieron midiendo el antiguo celebraron métricas que no correlacionan con los resultados.
La paradoja ya tiene cifras, y las cifras apuntan en una dirección: se reestructura mientras la brecha del 7,76% sigue siendo una ventaja competitiva, o se reestructura más adelante, después de que las organizaciones que lo descubrieron pronto hayan acumulado esa ventaja en años de distancia de entrega.
Ricardo
