- En medio de la amplia adopción de herramientas de programación con IA y el aumento de costos, varias grandes tecnológicas están organizando en métricas por capas cómo cuantifican realmente la utilidad de la IA
- La clave es un enfoque mixto que sigue en conjunto métricas básicas de ingeniería ya existentes (por ejemplo, rendimiento de PR, tasa de fallos por cambios) y métricas específicas de IA (por ejemplo, tasa de uso de IA, ahorro de tiempo, CSAT)
- Se enfatiza una mentalidad experimental que obtiene tendencias y correlaciones mediante el desglose por nivel de uso de IA según equipo, persona o cohorte, y comparaciones antes/después
- Se necesita un diseño equilibrado que supervise de forma constante calidad, mantenibilidad y experiencia del desarrollador junto con métricas de velocidad para evitar el aumento de deuda técnica y los efectos adversos de beneficios de corto plazo
- A largo plazo, se anticipa que la medición se ampliará hasta incluir la telemetría remota de agentes y áreas de trabajo no relacionadas con programación, y la pregunta termina siendo: “¿la IA está mejorando lo que ya importa (calidad, velocidad de salida al mercado y experiencia del desarrollador)?”
El discurso sobre el impacto de la IA y la brecha de medición
- Como se ve con frecuencia en LinkedIn y otros espacios, abundan las afirmaciones de que la IA está cambiando la forma en que las empresas desarrollan software
- Los medios suelen simplificar el impacto de la IA como “cuánto código se escribió”, pero como resultado la industria enfrenta el riesgo de acumular la mayor deuda técnica de su historia
- Aunque ya existía consenso en que LOC (líneas de código) no es una métrica adecuada de productividad, ha resurgido por su facilidad de medición, ocultando valores esenciales como calidad, innovación, velocidad de lanzamiento y confiabilidad
- Hoy, muchos líderes de ingeniería están tomando decisiones importantes sobre herramientas de IA sin tener claridad sobre qué funciona y qué no
- Según el LeadDev 2025 AI Impact Report, el 60% de los líderes señaló la “falta de métricas claras” como su mayor desafío
- Los líderes en campo se sienten frustrados entre la presión por resultados y ejecutivos obsesionados con las LOC, y la brecha entre la información necesaria y la medición real sigue ampliándose
- El autor lleva más de 10 años investigando herramientas para desarrolladores y, desde 2021, asesora sobre mejora de productividad y medición del impacto de la IA
- Desde que se unió como CTO de DX, ha colaborado con cientos de empresas y liderado análisis de DevEx, eficiencia e impacto de la IA
- A inicios de 2025, con datos de más de 400 empresas, coescribió el AI Measurement Framework
- Se trata de un conjunto recomendado de métricas necesarias para medir la adopción y el impacto de la IA, construido a partir de investigación de campo y análisis de datos
- En este artículo se revisa cómo 18 empresas tecnológicas miden realmente el impacto de la IA, y se comparten:
- casos reales de métricas de Google, GitHub, Microsoft y otras
- formas de uso para identificar qué funciona
- metodología para medir el impacto de la IA
- definiciones y guía de métricas de impacto de IA
1. Métricas reales utilizadas por 18 empresas
- Se comparte en imagen el caso de 18 empresas, entre ellas Google, GitHub, Microsoft, Dropbox, Monzo, Atlassian, Adyen, Booking.com y Grammarly
- Aunque las empresas adoptan enfoques distintos, en común se concentran en algunos grupos clave de métricas
-
1. Métricas de uso (Adoption & Usage)
- DAU/WAU/MAU: casi todas las empresas rastrean usuarios activos diarios, semanales y mensuales de las herramientas de IA
- Intensidad de uso / eventos de uso: Google, eBay y otras lo desglosan hasta nivel de escritura de código, respuestas de chat y acciones agentic
- CSAT de la herramienta de IA: muchas empresas, como Dropbox, Webflow y Grammarly, lo acompañan con encuestas de satisfacción
-
2. Métricas de productividad (Throughput & Time Savings)
- Rendimiento de PR (PR throughput): muchas empresas como GitHub, Dropbox, Webflow y CircleCI lo siguen de forma común
- Ahorro de tiempo (Time savings): medición de horas ahorradas por semana por ingeniero (Dropbox, Monzo, Toast, Xero y otras)
- Tiempo de ciclo de PR: usado en Microsoft, CircleCI, Xero, Grammarly y otras
-
3. Métricas de calidad/estabilidad (Quality & Reliability)
- Change Failure Rate: la métrica de calidad más común en GitHub, Dropbox, Adyen, Booking.com, Webflow y otras
- Mantenibilidad del código / percepción de calidad: GitHub, Adyen, CircleCI y otras la evalúan en conexión con DevEx
- Bugs / tasa de reversión: Glassdoor (cantidad de bugs), Toast (PR revert rate)
-
4. Métricas de experiencia del desarrollador (Developer Experience)
- Satisfacción del desarrollador / encuestas (DevEx, DXI): usadas en Atlassian, Webflow, CarGurus, Vanguard y otras
- Bad Developer Days (BDD): Microsoft mide de forma original la fricción con el concepto de “malos días de desarrollador”
- Carga cognitiva / fricción del desarrollador: Google, eBay y otras
-
5. Métricas de costo e inversión (Spend & ROI)
- Gasto en IA (total y por desarrollador): algunas empresas siguen costos, como en los casos de Dropbox, Grammarly y Shopify
- Capacity worked (nivel de aprovechamiento): Glassdoor mide cuánto se usó la herramienta frente a su potencial máximo
-
6. Métricas de innovación/experimentación (Innovation & Experimentation)
- Innovation ratio / velocity: GitHub, Microsoft, Webflow y otras convierten la velocidad de innovación en una métrica
- Cantidad de pruebas A/B: Glassdoor usa como métrica clave el número mensual de pruebas A/B
- Se rastrean en paralelo tanto métricas de resultados como métricas de comportamiento de uso, entre ellas ahorro de tiempo, rendimiento de PR, tasa de fallos por cambios, usuarios participantes y tasa de innovación
- La composición de métricas varía según las prioridades y el contexto del producto de cada organización, y no existe una métrica única universal
2. Base sólida: el núcleo de la medición del impacto de la IA
- Que la IA escriba código no cambia los criterios de un buen software. La calidad, la mantenibilidad y la velocidad siguen siendo clave
- Por eso, métricas existentes como Change Failure Rate, throughput de PR, tiempo de ciclo de PR y experiencia del desarrollador (DevEx) siguen siendo importantes
- No hacen falta métricas completamente nuevas
- La pregunta importante es: “¿La IA está haciendo mejor lo que ya era importante?”
- Si te quedas en métricas superficiales como LOC o tasa de aceptación, no puedes captar bien el impacto de la IA
- Sí se necesitan nuevas métricas objetivo para entender exactamente qué está pasando con el uso de la IA
- Permiten identificar dónde, cuánto y de qué manera se usa la IA, y usar eso para decisiones sobre presupuesto, despliegue de herramientas, seguridad y compliance
- Las métricas de IA muestran cosas como:
- ¿Cuántos desarrolladores y qué tipos de desarrolladores están adoptando herramientas de IA?
- ¿En cuánto trabajo y en qué tipos de trabajo está influyendo la IA?
- ¿Cuál es el costo?
- Las métricas clave de ingeniería muestran cosas como:
- si el equipo está haciendo ship más rápido
- si la calidad y la confiabilidad están subiendo o bajando
- si la mantenibilidad del código está empeorando
- si las herramientas de IA están reduciendo la fricción en el flujo de trabajo de los desarrolladores
-
Viendo el caso de Dropbox
- Métricas de IA
- DAU/WAU (usuarios activos diarios y semanales)
- CSAT de la herramienta de IA (satisfacción)
- tiempo ahorrado por ingeniero
- gasto en IA
- Métricas core (usando el Core 4 Framework)
- Change Failure Rate
- throughput de PR
- Resultados
- usuarios regulares semanales de IA = 90% de todos los ingenieros (por encima del promedio de la industria, 50%)
- los usuarios regulares de IA lograron 20% más PR fusionados + reducción en Change Failure Rate
- más que la tasa de adopción en sí, lo clave es confirmar si realmente está contribuyendo al desempeño de la organización, el equipo y las personas
3. Desglose de métricas según el nivel de uso de IA
- Se realizan distintos análisis comparativos para entender qué cambios provoca la IA en la forma de trabajar de los desarrolladores
- comparación entre usuarios y no usuarios de IA
- comparación de métricas clave de ingeniería antes y después de adoptar herramientas de IA
- seguimiento del mismo grupo de usuarios (cohort analysis) para observar cambios tras la adopción de IA
- Se segmentan los datos (slicing & dicing) para extraer patrones
- análisis por atributos como rol, antigüedad, región y lenguaje principal
- ejemplo: los perfiles junior aumentan la redacción de PR, mientras que los senior se vuelven más lentos porque aumenta la proporción de tiempo dedicada a revisión
- esto permite identificar los grupos que necesitan capacitación y apoyo adicional y los grupos donde el uso de IA genera mayor impacto
- Caso de Webflow
- en el grupo de desarrolladores con más de 3 años de antigüedad, el ahorro de tiempo al usar IA fue el mayor
- al usar herramientas como Cursor y Augment Code, hubo un aumento de 20% en el throughput de PR (comparando usuarios de IA vs no usuarios)
- La necesidad de una línea base sólida
- las organizaciones que no tienen una base de métricas de productividad de desarrolladores tienen dificultades para medir el impacto de la IA
- con el Core 4 Framework (usado por Dropbox, Adyen, Booking.com, entre otros) se puede asegurar rápidamente una línea base
- combinar datos de sistema, datos de muestreo de experiencia y encuestas periódicas permite hacer comparaciones más confiables
- El seguimiento continuo y una mentalidad experimental son clave
- una medición de una sola vez no tiene mucho sentido; hay que entender tendencias y patrones mediante seguimiento de series temporales
- lo que tienen en común las empresas exitosas: fijan objetivos concretos y validan hipótesis con datos
- sin depender ciegamente de los datos, mantienen una mentalidad experimental centrada en objetivos
4. Precauciones sobre mantenibilidad, calidad y experiencia del desarrollador
- El desarrollo asistido por IA sigue siendo un terreno nuevo
- todavía faltan datos que demuestren su impacto en la calidad y mantenibilidad del código a largo plazo
- el reto clave es equilibrar la mejora de velocidad en el corto plazo con el riesgo de deuda técnica a largo plazo
- Hay que seguir en conjunto métricas que se contrapesen entre sí
- la mayoría de las empresas rastrean al mismo tiempo Change Failure Rate y throughput de PR
- si sube la velocidad pero baja la calidad, eso funciona como una señal de problema inmediata
- Métricas adicionales para vigilar calidad y mantenibilidad
- Change confidence: nivel de confianza del desarrollador en la estabilidad del código al desplegar
- Code maintainability: facilidad para entender y modificar el código
- Perception of quality: percepción del desarrollador sobre la calidad del código y las prácticas del equipo
- Es necesario combinar métricas de sistema con métricas autorreportadas
- datos de sistema: throughput de PR, frecuencia de despliegue, etc.
- datos autorreportados: confianza en los cambios, mantenibilidad, etc. → señales clave para prevenir impactos negativos de largo plazo
- Se recomiendan encuestas periódicas de experiencia del desarrollador (DevEx)
- con la encuesta de ejemplo se puede rastrear la correlación entre calidad, mantenibilidad y uso de IA
- el feedback no estructurado también sirve para detectar problemas existentes y discutir soluciones
- El significado real de la experiencia del desarrollador (DevEx)
- no es un concepto de perks como “ping-pong y cerveza”, sino eliminar la fricción a lo largo de todo el proceso de desarrollo
- el objetivo es asegurar eficiencia en todo el proceso: planificación → desarrollo → pruebas → despliegue → operación
- las herramientas de IA pueden reducir la fricción al escribir código y hacer pruebas, pero también corren el riesgo de añadir nueva fricción en revisión, respuesta a incidentes y mantenibilidad
- Insight de campo (Shelly Stuart, de CircleCI)
- las métricas de output (throughput de PR) muestran qué está pasando, pero la satisfacción del desarrollador muestra la sostenibilidad
- la adopción de IA puede causar incomodidades iniciales, por lo que seguir la satisfacción es una herramienta clave para distinguir entre fricción de corto plazo vs valor de largo plazo
- el 75% de las empresas también rastrea el CSAT/satisfacción de las herramientas de IA → el foco está en crear una cultura de desarrollo sostenible más que solo en la velocidad
5. Métricas únicas y tendencias interesantes
- Microsoft: Bad Developer Day (BDD)
- Un concepto para medir en tiempo real la fricción y el nivel de fatiga en el trabajo diario
- Factores que hacen que un día sea malo incluyen la respuesta a incidentes y el cumplimiento, el costo de cambiar entre reuniones y correos, y el tiempo consumido por los sistemas de gestión del trabajo
- Se equilibra con la actividad de PR (un indicador indirecto del tiempo de programación), y si se asegura cierta cantidad de tiempo para programar, se considera un buen día incluso si hubo algunas tareas de bajo valor
- Objetivo: verificar si las herramientas de IA están reduciendo la frecuencia y la gravedad del BDD
- Glassdoor: medición de experimentos y tasa de uso de herramientas
- Hace seguimiento con la cantidad mensual de pruebas A/B para ver si la IA acelera la innovación y la experimentación
- También aplica una estrategia para convertir a los power users en evangelizadores internos de IA
- Capacity worked (utilización): mide el uso real frente al uso potencial de una herramienta para determinar el punto de saturación en la adopción y decidir la reasignación de presupuesto
- La caída de la Acceptance Rate
- Antes era un indicador clave de IA, pero su alcance es limitado porque solo observa el momento en que se acepta una sugerencia
- No refleja aspectos como mantenibilidad, aparición de bugs, reversión de código o productividad percibida por los desarrolladores
- Hoy ya no se usa mucho como métrica principal, aunque hay excepciones:
- GitHub: la usa para mejorar Copilot y para decisiones de producto
- T-Mobile: la usa para estimar en qué medida el código de IA llega realmente a producción
- Atlassian: la usa como indicador auxiliar de satisfacción de los desarrolladores y calidad de las sugerencias
- Análisis de costos e inversión
- La mayoría de las empresas no sigue de forma activa los costos de uso para evitar desincentivar a los desarrolladores
- Shopify adoptó un enfoque que celebra a los desarrolladores con mayor consumo de tokens mediante el AI Leaderboard
- ICONIQ 2025 State of AI Report: se proyecta que en 2025 el presupuesto empresarial para productividad con IA se duplicará frente a 2024
- Algunas organizaciones están cambiando a un modelo de reducir el presupuesto de contratación y reasignarlo al presupuesto de herramientas de IA
- Ausencia de telemetría de agentes
- Hoy casi no se mide, pero hay una alta posibilidad de adopción dentro de 12 meses
- A medida que se expandan los flujos de trabajo con agentes autónomos, crecerá la necesidad de medir comportamiento, precisión y tasa de regresión
- Falta de medición de actividades no relacionadas con la programación
- Por ahora se limita al apoyo para escribir código; sesiones de planificación en ChatGPT o gestión de issues en Jira casi no se incluyen
- En 2026, el uso de IA se ampliará a todas las etapas del SDLC, y la medición también deberá evolucionar
- Actividades concretas como revisión de código o escaneo de vulnerabilidades son fáciles de medir; las tareas abstractas son más difíciles
- Se espera una ampliación del alcance de las mediciones de autorreporte ("¿cuánto tiempo te ahorró la IA esta semana?")
6. ¿Cómo se debe medir el impacto de la IA?
- AI Measurement Framework
- Desarrollado junto con Abi Noda, coautor del DevEx Framework
- Elaborado a partir de datos de campo de más de 400 empresas y de investigaciones sobre productividad de desarrolladores de la última década
- Combina métricas de IA y métricas core para evaluar en conjunto velocidad, calidad, mantenibilidad y experiencia del desarrollador (DevEx)
- Una sola métrica (por ejemplo, la proporción de código generado por IA) sirve para titulares, pero no es una herramienta suficiente para medir resultados
- Necesidad de combinar datos cualitativos y cuantitativos
- Solo al recopilar tanto métricas del sistema (throughput de PR, DAU/WAU, frecuencia de despliegue, etc.) como métricas de autorreporte (CSAT, ahorro de tiempo, percepción de mantenibilidad, etc.) se puede lograr una comprensión multidimensional
- Muchas empresas usan DX para recopilar y visualizar datos, aunque también es posible construir sistemas personalizados
- Métodos de recolección de datos
- Datos del sistema (cuantitativos): API de administración de herramientas de IA (uso, gasto, tokens, tasa de aceptación) + métricas de SCM, JIRA, CI/CD, builds y gestión de incidentes
- Encuestas periódicas (cualitativas): encuestas trimestrales o semestrales para identificar tendencias de largo plazo en DevEx, satisfacción, confianza en los cambios y mantenibilidad, que son difíciles de captar con métricas del sistema
- Muestreo de experiencia (cualitativo): insertar preguntas breves dentro del flujo de trabajo (por ejemplo, justo después de enviar un PR: "¿usaste IA?", "¿este código fue fácil de entender?")
- Prioridades de ejecución
- Las encuestas periódicas son el punto de partida más rápido: permiten obtener datos iniciales en 1 a 2 semanas
- Así como no se necesita el mismo nivel de precisión para colgar una cortina que para lanzar un cohete, en decisiones de ingeniería también puede ser útil una precisión suficiente para marcar dirección
- Luego, si se combinan otros métodos de recolección para validación cruzada, aumenta la confiabilidad
- Recursos adicionales
- Aspectos a considerar al aplicarlo internamente
- En lugar de perseguir la tasa de adopción o una sola métrica, hay que verificar si está mejorando la capacidad de entregar software de alta calidad a los clientes con rapidez
- Pregunta clave:
> "¿La IA está haciendo mejor lo que ya era importante (calidad, velocidad de lanzamiento, experiencia del desarrollador)?"
- Preguntas para tratar en las reuniones de liderazgo:
- ¿Cuál es la definición de desempeño de ingeniería en nuestra organización?
- ¿Tenemos datos de desempeño previos a la adopción de herramientas de IA? Si no, ¿cómo vamos a establecer rápidamente una baseline?
- ¿No estaremos confundiendo la actividad de IA con el impacto de la IA?
- ¿Estamos equilibrando velocidad, calidad y mantenibilidad?
- ¿Estamos viendo el impacto en la experiencia del desarrollador?
- ¿Estamos operando un enfoque de medición multinivel que incluya tanto datos del sistema como datos de autorreporte?
7. Cómo mide Monzo el impacto de la IA
- Etapa inicial de adopción
- La primera herramienta fue GitHub Copilot. Venía incluida en la licencia de GitHub y se integró de forma natural en VS Code, por lo que todos los ingenieros empezaron a usarla
- Después probaron en paralelo varias herramientas como Cursor, Windsurf y Claude Code, mientras seguían invirtiendo principalmente en Copilot
- Filosofía para evaluar herramientas de IA
- En un ecosistema de herramientas que cambia rápido, la experiencia directa es indispensable
- Para conocer realmente el rendimiento, los miembros del equipo deben aplicar IA al código real todos los días y hasta crear y usar por sí mismos archivos de configuración de agentes
- La evaluación combina métricas objetivas (uso, rendimiento) y encuestas subjetivas (satisfacción con la DX)
- Efectos y valor percibido
- Los ingenieros sienten que, con la IA, buscar y resumir documentación, y entender código se volvió más fácil, y que redujo la carga cognitiva
- En un mercado laboral competitivo para el talento, no ofrecer las mejores herramientas implica riesgo de fuga de desarrolladores → proveer herramientas es en sí una estrategia de retención de talento
- Dificultades para medir
- Las cifras que entregan los proveedores se limitan a métricas restringidas, como la tasa de adopción, y es difícil entender el verdadero impacto en el negocio
- Tampoco es realista validar esto con precisión mediante pruebas A/B
- Es difícil consolidar los datos de uso de distintas herramientas (GitHub, Gemini, Slack, Notion, etc.) → las limitaciones de telemetría y el vendor lock-in son obstáculos principales
- Como resultado, por ahora la percepción de los desarrolladores es la señal principal
- Áreas donde funciona bien
- Grandes resultados en migraciones: se percibe una reducción del 40% al 60% en tareas de cambio de código
- En trabajos repetitivos y manuales, como comentar modelos de datos, los LLM hacen un primer borrador y los ingenieros lo corrigen → gran ahorro de trabajo a escala
- Lecciones inesperadas
- Falta de noción del costo de los LLM: al ver una factura basada en el uso real de tokens, se sentiría con más claridad la necesidad de optimizar
- Ejemplo: la revisión automática de código de Copilot consume muchos tokens y aporta poco valor, así que viene desactivada por defecto y solo se activa mediante opt-in cuando hace falta
- Áreas donde no usan IA
- Datos de clientes: está prohibido aplicar IA tanto a datos originales como a datos anonimizados
- En áreas con datos sensibles, la prioridad absoluta es evitar el riesgo de filtración de datos
- Filosofía del equipo de plataforma
- Proveer guardrails: preparar un entorno de uso seguro, incluyendo protección de datos
- Compartir casos: publicar con transparencia experiencias de éxito y fracaso, así como el uso de prompts
- Enfatizar la doble cara: compartir tanto lo positivo como lo negativo para mantener una visión equilibrada
- Recordar los límites de los LLM: la IA tiene limitaciones como los humanos, por lo que no debe generar una confianza excesiva
Conclusión e implicaciones
- Medir el impacto de la IA sigue siendo un área muy nueva
- No existe una “mejor metodología” en la industria
- Incluso empresas de tamaño y mercado similares, como Microsoft y Google, usan métricas distintas
- Cada empresa tiene su propio enfoque y su propio “flavor”
- Es común medir al mismo tiempo métricas que entran en tensión
- Caso representativo: seguir en paralelo la tasa de fallas en cambios (confiabilidad) y la frecuencia de PR (velocidad)
- Desplegar más rápido solo tiene sentido si no perjudica la confiabilidad, por lo que hay que medir ambos ejes de forma equilibrada
- Medir el impacto de las herramientas de IA es un desafío muy parecido al de medir la productividad de los desarrolladores
- La industria lleva más de 10 años lidiando con el problema de medir la productividad
- Ninguna métrica única puede explicar la productividad de un equipo, y optimizar una métrica específica no significa que la productividad realmente aumente
- En 2023, McKinsey afirmó haber “resuelto” cómo medir la productividad, pero Kent Beck y el autor expresaron una postura escéptica al respecto → artículo de respuesta
- Todavía no hay una solución clara, pero hace falta experimentar
- Mientras no se resuelva por completo cómo medir la productividad, también será difícil resolver por completo cómo medir el impacto de las herramientas de IA
- Aun así, hay que seguir experimentando y probando nuevos enfoques para responder a la pregunta: “¿Cómo cambian las herramientas de codificación con IA la eficiencia diaria y mensual a nivel individual, de equipo y de empresa?”
Aún no hay comentarios.