El año pasado, participé en una revisión trimestral de negocios donde un director de ingeniería presentó lo que él llamó «el mejor trimestre en la historia del equipo». La velocidad subió un 42%. Las pull requests por desarrollador casi se habían duplicado. Los burndowns de sprint fueron fluidos como el clásico. Las diapositivas estaban pulidas, las líneas de tendencia todas apuntando hacia arriba, y la sala asentía con la cabeza.

Entonces el vicepresidente de producto hizo una pregunta sencilla: «¿Entonces por qué llevamos tres semanas de retraso con la función que los clientes realmente están esperando?»

La habitación quedó en silencio. No porque nadie tuviera una respuesta, sino porque la respuesta revelaba algo incómodo: cada métrica en el panel mejoraba mientras que lo que importaba al negocio empeoraba. El equipo había adoptado asistentes de codificación con IA seis meses antes, y los números respondieron exactamente como todos esperaban. Más código. Más velocidad. Más rendimiento. El salpicadero fue una historia de éxito. La hoja de ruta del producto no lo era.

Este es el problema de la medición, y es más común de lo que la mayoría de los líderes de ingeniería quieren admitir. No es un problema de herramientas. No es un problema de calibración. Es un fallo estructural en la forma en que medimos el desarrollo de software, uno que la adopción de la IA no crea pero expone con una claridad incómoda.

Las métricas ya eran frágiles

Permítanme ser directo en algo: las métricas en las que confían la mayoría de las organizaciones de ingeniería nunca fueron tan fiables como las tratamos. Velocidad en puntos de historia, líneas de código, gráficos de burndown de sprints, pull requests por desarrollador. Estos siempre eran proxies, aproximaciones aproximadas aproximadas del progreso que funcionaban lo suficientemente bien cuando la relación entre esfuerzo y producción era relativamente estable.

La IA rompe esa estabilidad.

Los puntos de la historia fueron diseñados para capturar un esfuerzo relativo en un mundo donde la complejidad de la implementación variaba drásticamente entre tareas. Un «1» era un cambio de configuración. Un «8» era un nuevo servicio con integración de bases de datos, diseño de API y cobertura de pruebas. La IA colapsa ese rango. Cuando la IA genera la implementación, el trabajo humano restante, revisando, validando y decidiendo, es más uniforme entre tareas. El «8» se convierte en un «2» no porque el trabajo sea más sencillo, sino porque la parte mecánica ha sido automatizada. La velocidad aumenta, pero la unidad de medida ha cambiado. Es como medir la distancia en millas y luego cambiar a kilómetros sin avisar a nadie: el número es mayor, pero no has avanzado más.

Trabajé en una empresa sanitaria donde esto se desarrolló durante seis meses. Su velocidad aumentó de una media de 45 puntos por sprint a 78 puntos. Liderazgo celebrado. Pero cuando le pregunté al product owner cuántas características habían llegado a producción en el mismo periodo, la respuesta fue desconcertante: más o menos la misma que antes. El aumento de velocidad fue completamente un artefacto de la deflación puntual. Las historias que antes eran «5s» ahora eran «2s» porque la IA se encargaba de la implementación. El equipo completaba más puntos pero entregaba el mismo valor empresarial.

El panel de control decía que estaban ganando. El producto decía lo contrario.

Cuando las métricas de salida individuales se encuentran con el trabajo colaborativo

La distorsión empeora cuando se observan las métricas de salida individuales en el contexto de cómo funciona realmente el desarrollo impulsado por IA.

Pull requests por desarrollador, commits por desarrollador, historias completadas por desarrollador. Estas métricas asumen que la unidad de productividad es el individuo. Esa suposición ya era cuestionable en cualquier entorno de desarrollo en equipo, pero se vuelve activamente perjudicial cuando la IA cambia la naturaleza del trabajo.

Una empresa fintech con la que trabajé vio cómo las pull requests por desarrollador aumentaron un 80% tras la adopción de la IA. También vieron que el tiempo medio de revisión bajaba de 45 minutos a 12 minutos. El liderazgo interpreta esto como eficiencia. No era eficiencia. Fue un auténtico aprobamiento. Los revisores no podían seguir el ritmo del volumen de código generado por IA, así que hojeaban en lugar de revisar. Los defectos que deberían haberse detectado en la revisión se detectaron en la producción.

La métrica mejoró. El sistema se degradó.

Este patrón se acelera cuando las organizaciones utilizan métricas individuales para la evaluación del rendimiento. Si un desarrollador sabe que se mide en los PRs fusionados por sprint, optimizará para ese número. En un mundo previo a la IA, esa optimización era mayormente inofensiva porque fusionar una PR requería escribir el código, lo que requería un esfuerzo real. En un mundo asistido por IA, generar código es rápido. El cuello de botella se traslada a la validación, la integración y la coherencia arquitectónica, ninguna de las cuales aparece en un recuento de relaciones públicas.

El resultado es un equipo donde cada uno es productivo individualmente y colectivamente ineficaz. El panel de cada persona se ve sólido. El sistema que están construyendo juntos no se sostiene.

En el papel en evolución del desarrollador, escribí sobre cómo la IA traslada el valor del desarrollador de la generación de código a la validación y el juicio. El problema de la medición es el reflejo organizativo de ese cambio: si sigues midiendo la generación mientras el valor se ha trasladado a la validación, estás recompensando el comportamiento equivocado.

La trampa conductual

Aquí es donde el problema de medición se convierte en un problema de gestión.

Charles Goodhart observó que cuando una medida se convierte en un objetivo, deja de ser una buena medida. En el desarrollo de software, esto se desarrolla con una precisión devastadora.

Cuando los equipos saben que se miden por velocidad, inflan las estimaciones. Una tarea que el equipo acuerda en privado como un «3» se estima como un «5» porque el compromiso del sprint debe parecer alcanzable. Tras la adopción de la IA, esta dinámica se intensifica: la brecha entre el esfuerzo real y el esfuerzo estimado se amplía, haciendo que la inflación sea más fácil y más difícil de detectar.

Cuando los directivos comparan la velocidad entre equipos, crean incentivos perversos. El equipo A corre a 60 puntos por sprint. El equipo B corre en 90. Un director que no entiende que los puntos de la historia son específicos de cada equipo, que nunca fueron diseñados para la comparación entre equipos, concluye que el Equipo B es un 50% más productivo. El equipo A responde inflando sus estimaciones. Ahora ambos equipos apuntan a 90 puntos, y el director concluye que la organización ha mejorado. Nada cambió salvo los números.

Cuando las organizaciones vinculan bonificaciones o promociones a las tasas de finalización de sprints, incentivan la reducción del alcance. Los equipos aprenden a comprometerse a menos, a completarlo de forma fiable y a presentar un gráfico perfecto de quemaduras. La métrica es impecable. La ambición se ha ido.

La IA amplifica cada una de estas dinámicas porque incrementa el volumen de producción medible sin aumentar proporcionalmente el volumen de resultados medibles. Hay más que contar, y contar es más fácil que evaluar. Así que las organizaciones cuentan.

Esto es el teatro de la productividad: la versión con IA del teatro DevOps sobre el que escribí recientemente. El teatro DevOps consistía en renombrar los silos sin quitarlos. El teatro de la productividad consiste en inflar los paneles sin mejorar la entrega. Misma dinámica, otro ámbito.

La dimensión política

Si el problema de medición fuera puramente técnico, sería fácil de solucionar. Cambia las métricas antiguas por otras mejores. Actualiza los paneles. Sigue adelante.

Pero las métricas no son solo instrumentos de medición. Son artefactos políticos. Cada métrica tiene una constituyente.

El gestor de proyecto que utiliza la velocidad para hacer pronósticos. El director que utiliza comparaciones de velocidad de equipo para las evaluaciones de desempeño. El ejecutivo que informa a la junta sobre las tasas de finalización de sprints. El equipo de RRHH que utiliza métricas de salida individuales para las decisiones de ascenso. Cada uno de estos interesados ha construido procesos, informes y decisiones en torno a las métricas existentes. Retirar una métrica significa decirles a estas personas que la cifra en la que han estado confiando ya no tiene sentido.

Esa es una conversación incómoda, y la mayoría de los líderes la evitan.

La estrategia de evitación más común es ejecutar métricas duales: mantener las antiguas «por continuidad» mientras se introducen nuevas «para experimentación». Esto suena razonable. Es una trampa. Cuando los equipos se enfrentan a dos sistemas de medición, optimizan para el que tiene consecuencias. Las métricas antiguas, por estar ligadas a procesos e incentivos existentes, siempre ganan la batalla por la atención. Las nuevas métricas, porque son desconocidas y aún no están ligadas a nada, son ignoradas.

He visto este patrón en varias organizaciones. El equipo directivo anuncia un nuevo enfoque de medición. Los viejos salpicaderos siguen arriba. En dos meses, cada conversación vuelve a la velocidad y el desgaste de velocidad porque esos son los números que la gente sabe interpretar. Las nuevas métricas se convierten en un proyecto paralelo que nadie posee.

El problema de la medición no es «no sabemos qué medir». Es «no podemos soltar lo que hemos estado midiendo.»

Cuánto cuesta realmente esto

El coste de medir las cosas equivocadas no es abstracto. Se manifiesta de tres maneras concretas.

La magnitud del problema es mayor de lo que la mayoría de los líderes imagina. Un estudio de Wharton con 800 altos responsables de la toma de decisiones encontró que el 74% de las empresas reportan un retorno positivo de inversión (ROI) de la IA generativa. Mientras tanto, la investigación del MIT sobre pilotos de IA empresarial reveló que el 95% no logra un impacto medible en el P&L, y solo el 5% logra un valor sustancial a gran escala. Ambos estudios son creíbles. Ambos miden cosas diferentes. Esa brecha entre el ROI reportado y el impacto real en el negocio es el problema de medición a nivel de industria: las organizaciones miden la actividad y la llaman valor.

Primero, la pérdida de talento. Los ingenieros que entienden que las métricas están rotas, los que tienen el juicio y el pensamiento sistémico que más necesitas conservar, son los primeros en irse. Ven la desconexión entre lo que recompensa el panel de control y lo que requiere el trabajo. Ven cómo los colegas son reconocidos por altos conteos de relaciones públicas mientras la base de código se deteriora. Plantean el tema, les dicen «los números son buenos» y empiezan a actualizar sus currículums. Exploré esta dinámica en la conversación sobre la que realmente trata este libro: la brecha entre lo que dicen las métricas y lo que experimentan los equipos es una de las fuerzas más corrosivas en las organizaciones de ingeniería.

Segundo, inversión mal asignada. Cuando los líderes toman decisiones sobre recursos basándose en métricas que ya no se correlacionan con el valor, invierten en las cosas equivocadas. El equipo con mayor velocidad tiene más personal. El equipo que realmente está entregando más valor para el negocio pero tiene menor velocidad porque dedica tiempo a validar y coherencia arquitectónica es cuestionado. Los recursos fluyen hacia la producción, no hacia los resultados.

Tercero, el reconocimiento tardío de los problemas reales. Cuando el panel de control dice que todo está bien, nadie investiga. Los problemas de integración, la disminución de la calidad del código, las vulnerabilidades de seguridad que introduce el código generado por IA, todo esto se acumula silenciosamente tras un muro de métricas verdes. Cuando los problemas surgen en producción, son caros de solucionar y embarazosos de explicar.

Las preguntas que merece la pena hacer

No voy a prescribir un marco de sustitución en esta publicación. El problema de la medición es primero un problema diagnóstico: tienes que entender qué está roto antes de poder arreglarlo. Y el diagnóstico empieza con preguntas sinceras.

Si tu equipo adoptó asistentes de codificación por IA en el último año, pregúntate:

¿Ha aumentado la velocidad? Si es así, ¿ha aumentado proporcionalmente el número de largometrajes enviados a producción? Si la respuesta es no, tu métrica de velocidad ha perdido su calibración.

¿Estás midiendo la producción individual de los reveladores? Si es así, ¿esas métricas están creando incentivos que entran en conflicto con el trabajo colaborativo? Si un desarrollador puede mejorar sus métricas personales trabajando solo en lugar de participar en revisiones de equipo, esas métricas están jugando en tu contra.

¿Tus métricas tienen consecuencias? Si la velocidad está ligada a las evaluaciones de desempeño, la finalización de sprint a los bonos, o el recuento de relaciones públicas a los ascensos, has creado un sistema en el que la gente optimizará la métrica, no el resultado. Eso era arriesgado antes de la IA. Ahora es peligroso.

¿Puedes responder a la pregunta «¿estamos entregando valor para el negocio?» con tus métricas actuales? No «¿estamos completando sprints» o «estamos enviando código», sino «¿el software que hemos creado está marcando la diferencia para el negocio?» Si tus métricas no pueden responder a esa pregunta, están midiendo la actividad, no el impacto.

¿Cuándo fue la última vez que retiraste un criterio? Si la respuesta es «nunca», estás acumulando deuda de medición de la misma manera que las bases de código acumulan deuda técnica. Las métricas antiguas que ya no se correlacionan con la realidad no son inofensivas. Engañan activamente.

La incómoda verdad

El problema de la medición es, en última instancia, un problema de liderazgo. No se trata de paneles, herramientas o frameworks. Se trata de si los líderes están dispuestos a admitir que los números en los que han confiado ya no dicen la verdad.

Esa confesión es difícil. Significa reconocer que las decisiones tomadas basándose en esos números pueden haber sido erróneas. Significa mantener conversaciones incómodas con los grupos de interés que dependen de métricas familiares. Significa aceptar un periodo de incertidumbre mientras se establecen y validan nuevos enfoques de medición.

Pero la alternativa es peor. La alternativa es una organización que optimice para métricas que premian el comportamiento incorrecto, pierda a las personas que ven la desconexión y descubra los problemas reales solo cuando se convierten en crisis.

La IA no creó el problema de la medición. Pero eliminó el margen de error que permitía que métricas frágiles parecieran fiables. La cuestión no es si tus métricas necesitan cambiar. La cuestión es si los cambiarás antes de que el coste de no hacerlo sea imposible de ignorar.

Ricardo