Una CTO fintech con la que trabajo tuvo su momento de junta hace tres meses. El presidente se inclinó hacia delante a mitad de la revisión y hizo la pregunta que todo ejecutivo tecnológico teme: «¿Así que me estás diciendo que no sabes si esto está funcionando?»

Su respuesta fue mejor que la de la mayoría: «Te digo que los números que usábamos para responder a esa pregunta dejaron de responderla hace seis meses.»

La junta nunca volvió a preguntar por la velocidad.

El mito y las matemáticas

La suposición de 5x se ha arraigado en las salas de juntas de toda la industria. Los proveedores lo prometen, los analistas lo citan, los CEOs lo repiten en las llamadas de resultados. Y los equipos de ingeniería asimilan la expectativa sin que nadie se detenga a preguntar: ¿5 veces más rápido en qué, exactamente?

Fred Brooks observó en 1975 que la codificación representa aproximadamente entre el 15 y el 20 por ciento del esfuerzo total de entrega. El resto son aclaración de requisitos, decisiones de diseño, coordinación, pruebas, revisión y despliegue. La IA no ha cambiado esa proporción ni de lejos tanto como la mayoría de la gente supone. Cinco décadas después, la forma general ha cambiado mucho menos de lo que nadie esperaba. La IA acelera la porción del 15 al 20 por ciento. El otro 80 por ciento, la parte que requiere juicio, comunicación y alineación organizativa, sigue intacto.

La teoría de sistemas tiene un nombre para esta restricción: la Ley de Amdahl. Aunque la IA hiciera que la programación fuera literalmente cinco veces más rápida, la mejora total de entrega se limita a aproximadamente el 19 por ciento (porque la mayor parte del trabajo nunca fue programar desde el principio). Eso es real y merece la pena capturarlo, pero está muy lejos de ser 5x.

Las ganancias medidas reales son aún menores. Cinco estudios independientes publicados en 2025 y 2026 utilizaron metodologías diferentes y midieron distintas cosas, pero la dirección es constante: aumento de la actividad individual, resultados organizativos planos o peores. DX rastreó a 400 empresas y encontró un aumento del 65 % en el uso de IA, y un 10 % de rendimiento de relaciones públicas. El MIT y el NBER rastrearon a 100.000 desarrolladores y encontraron un 300 por ciento más de código generado, con solo un 30 por ciento más de software llegando a su lanzamiento. Cortex midió las relaciones personales por autor, subiendo un 20 por ciento, junto con incidentes por residencia permanente, con un aumento del 23,5 por ciento.

El estudio más revelador vino de METR, una organización de investigación sin ánimo de lucro de Berkeley que llevó a cabo un ensayo controlado aleatorizado con desarrolladores de código abierto experimentados trabajando en sus propios repositorios. Los desarrolladores que usaban herramientas de IA tardaban un 19 % más en completar las tareas. Después de cada sesión, esos mismos desarrolladores estimaban que habían sido un 20 % más rápidos. Una brecha de 39 puntos entre percepción y realidad, donde la dirección mide la percepción y los promotores viven dentro de la brecha. Nadie tiene un vocabulario compartido para la conversación intermedia.

La función frente a la hoja de ruta

El número 5x es real, simplemente mal aplicado. Un desarrollador dice: «Escribí esa función en 10 minutos en vez de 50.» Cierto. La función era 5 veces más rápida. Pero la función aún tardaba seis semanas, porque nunca fue el cuello de botella.

La productividad individual no es productividad de equipo, y la productividad del equipo no es el rendimiento organizativo. La afirmación 5x es cierta a nivel de tarea individual, plausible a nivel de actividad del equipo e invisible a nivel de entrega. Cuando una junta escucha «somos cinco veces más rápidos», asume que la hoja de ruta se ha comprimido en un 80 por ciento. El desarrollador se refería a la función. La junta escuchó el trimestre. Ambas afirmaciones parecen verdaderas para la persona que las hace, y la diferencia entre ellas es donde las organizaciones pierden meses de credibilidad en la planificación.

El modo de fallo es la cobertura. Un CTO dice «creemos que la velocidad puede no contar toda la historia» y todos los interesados concluyen que su uso específico de la métrica es la excepción. Los directores de ingeniería lo ven como un problema de gestión de producto. Los responsables de producto lo entienden como un problema de la disciplina de ingeniería. Todos coinciden en que algo debería cambiar y nada cambia, porque el lenguaje fue diseñado para evitar incomodar a nadie en lugar de nombrar claramente el problema.

Qué cambia realmente

Tres cosas cambian en la velocidad de entrega cuando la IA entra en una organización de ingeniería. Ninguna es «5 veces más rápida de extremo a extremo».

El cuello de botella se mueve. La generación de código deja de ser la restricción. La definición de la intención, el juicio arquitectónico y la revisión se convierten en los pasos limitantes de la tasa. Las organizaciones que se reestructuran en torno a este cambio obtienen beneficios reales, no generando código más rápido, sino reduciendo el tiempo entre la intención y el resultado empresarial validado. Las organizaciones que añaden IA a flujos de trabajo existentes experimentan la paradoja: los paneles mejoran, la entrega no.

La brecha de percepción se amplía. Cuando la IA hace que los desarrolladores se sientan más rápidos sin hacer que la organización sea más rápida de forma medible, el CTO hereda un problema de credibilidad. El consejo ve que los paneles suben mientras el vicepresidente de producto ve que la hoja de ruta se está desvaneciendo, y ambos analizan datos precisos. Están midiendo diferentes puntos en un sistema que ahora tiene una mayor distribución entre actividad y resultado.

La conversación en la junta necesita una estructura de tres partes. La estructura antigua era sencilla: aquí está nuestra velocidad, aquí nuestra previsión, aquí está nuestra confianza en la entrega. La nueva estructura requiere tres partes: qué cambió realmente (ganancias específicas, reconocidas honestamente para establecer credibilidad), qué no cambió (complejidad, coordinación, el 80 por ciento que requiere juicio) y qué empeoró (carga de revisión, deuda de comprensión, dependencia del proveedor). Un CTO que imparte las tres partes se gana la credibilidad para proponer diferentes mediciones. Sin los tres, el consejo concluye que todo está bien o concluye que la inversión ha fallado, y ninguno te da permiso para medir de forma diferente.

El acto político

Retirar una métrica es un acto político, no técnico. Cada métrica tiene circunscripciones cuya autoridad depende de que los números se mantengan exactamente iguales. El gestor de proyecto que utiliza la velocidad para hacer pronósticos. El director de ingeniería que utiliza comparaciones entre equipos para las evaluaciones de desempeño. El director financiero que informa a la junta sobre las tasas de finalización de sprints.

Las métricas asignan el poder. Decirle a un stakeholder que su métrica ya no funciona, sin ofrecerle algo mejor, genera resistencia que parece desacuerdo pero que en realidad es autopreservación. No están defendiendo la métrica. Están defendiendo el papel organizativo que la métrica les permite desempeñar.

El trabajo del CTO es construir el reemplazo antes de retirar el sistema antiguo, parte interesada por parte, con herramientas que sirvan a la necesidad legítima de cada persona. Eso es un problema de gestión del cambio, no de panel. Y la mayoría de las organizaciones nunca llegan a ese punto, porque el CTO que retira una métrica está admitiendo implícitamente que las decisiones tomadas con esa métrica pueden haber sido erróneas.

La IA no dificultó la medición. Eso dejó claro que estábamos midiendo lo más fácil en lugar de lo más importante.

Ese es el verdadero problema de la medición, y el rediseño que requiere va más allá de lo que cualquier publicación puede cubrir: el proceso de jubilación, la estrategia de alineación de grupos de interés y las métricas que sobreviven a la era de la IA. Ahora estoy trabajando en ese tratamiento más profundo.

Ricardo