Medir la productividad de desarrolladores con IA

Tu equipo adoptó Claude Code y Cursor hace tres meses. Los pull requests suben, las licencias se usan y alguien pregunta lo obvio: ¿está valiendo la pena? Buscas una respuesta y encuentras un experimento que dice que desarrolladores experimentados tardaron entre 4 % y 18 % menos, otro que dice 55,8 % más rápidos, un tercero que habla de cerca de 21 % menos tiempo y un estudio de todo GitHub donde los commits subieron 240 % mientras los lanzamientos subieron 30 %. Todos son reales y ninguno describe a tu equipo.

El desacuerdo tiene causas que se leen en el diseño de cada estudio, y esas causas indican qué medir. Esta guía concilia los estudios principales, propone un modelo por capas y resuelve un ejemplo completo con esfuerzo humano, revisión, retrabajo y costo de IA en dos herramientas.

¿Cómo se mide la productividad con IA en ingeniería?

La productividad con IA se mide como el esfuerzo humano y el costo de IA por cada cambio aceptado, no como uso ni como volumen de código. La unidad es el cambio aceptado: un pull request, un ticket o una migración que cumplió los criterios acordados antes de empezar. Así las sesiones abandonadas siguen a la vista, porque su costo lo pagan los cambios que sí se aceptaron, y también quien revisa: una corrección que toma diez minutos escribir y cuarenta revisar no es una corrección de diez minutos.

¿Qué dice la investigación y por qué los estudios no coinciden?

Los estudios no coinciden porque miden tareas distintas, con personas distintas y contra líneas base distintas. Leídos uno junto a otro, dejan de contradecirse.

Tres variables explican casi toda la dispersión. La tarea: un servidor desde cero y un bug en un repositorio maduro son trabajos distintos. La línea base: Google y Copilot compararon contra ingenieros sin IA frente a una tarea nueva, mientras que METR estudió a desarrolladores experimentados en repositorios que ya conocían. Y el alcance: tiempo por tarea, commits y lanzamientos son tres mediciones distintas, y el NBER encontró que un aumento de 240 % en commits se convirtió en un aumento de 30 % en lanzamientos.

Los números de METR de 2026 muestran además la brecha de percepción, aunque vienen de dos muestras distintas. En su encuesta de mayo, los trabajadores técnicos reportaron una mediana de 3 veces más velocidad, pero solo entre 1,4 y 2 veces más valor, y METR advierte que los resultados de una encuesta no necesariamente reflejan la realidad. Su propio experimento de febrero midió entre 4 % y 18 % menos tiempo, con intervalos que incluyen el cero. Es el mejor argumento para poner datos de sistema junto a las encuestas. Las respuestas dicen cómo se siente el trabajo; los registros, qué le pasó.

¿Qué métricas conviene seguir y en qué orden?

Sigue seis capas en orden, porque cada una explica la siguiente. Con adopción baja, un número de costo o de entrega dice poco. Si la entrega mejora mientras la estabilidad cae, ese es el patrón que conviene investigar primero.

El modelo toma ideas de dos marcos públicos. El ROI del desarrollo de software asistido por IA de DORA vincula la adopción de IA con las capacidades, luego con las métricas DORA, después con la productividad y la experiencia, y solo al final con el costo y los ingresos. DORA también dice que los agregados de toda la empresa carecen de sentido y las puntuaciones individuales hacen daño. El artículo de SPACE sostiene algo más general: la productividad del desarrollador “no puede medirse con una sola métrica o dimensión”. En la capa 5 entra la guía de métricas DORA, y los hallazgos de DORA 2025 explican por qué importa: la adopción de IA fue de la mano con más rendimiento y menos estabilidad.

¿Cómo se calcula el esfuerzo neto por cambio aceptado?

El esfuerzo neto por cambio aceptado son los minutos humanos de preparar, revisar y corregir un cambio, divididos entre la cantidad de cambios que cumplieron los criterios de aceptación. Compáralo con la misma cifra de cambios comparables hechos sin IA, y deja fuera el tiempo en cola para que la espera no pase por esfuerzo.

Este es un ejemplo ilustrativo, con números inventados para mostrar la aritmética. Un lote base de 30 cambios comparables se hizo sin IA. Un segundo lote de 30 se hizo con IA: 18 con Claude Code y 12 con Cursor. Los minutos incluyen a todas las personas que tocaron el cambio.

La preparación bajó 246 minutos. La revisión subió 78 y la corrección 48. La reducción neta es 246 menos 126, es decir, 120 minutos: 120 ÷ 900 = 13,3 %. Quien reporte solo la primera fila afirmaría un ahorro de 39 % en preparación.

xychart-beta
  accTitle: Minutos por cambio aceptado, lote base frente a lote con IA
  accDescr: Ilustrativo. Preparación, 21 minutos en el lote base y 12,8 con IA. Revisión y verificación, 6 en el lote base y 8,6 con IA. Corrección, 3 en el lote base y 4,6 con IA.
  title "Minutos por cambio aceptado (ilustrativo)"
  x-axis ["Preparación", "Revisión y verificación", "Corrección"]
  y-axis "Minutos" 0 --> 24
  bar [21, 6, 3]
  line [12.8, 8.6, 4.6]

El gráfico resume toda la sección en una imagen: el ahorro está en la primera columna, y una parte se devuelve en las dos siguientes.

Las dos herramientas llegan a 26 minutos por cambio, con formas distintas: Claude Code, en sesiones agénticas, gasta 12 minutos en preparar y 9 en revisar; Cursor, en el editor, 14 y 8. Los lotes incluyen cambios de distinto tipo, así que la tabla no ordena las herramientas. Para compararlas hacen falta tareas equivalentes.

¿Cómo se calcula el costo de IA por cambio aceptado?

El costo de IA por cambio aceptado es el gasto total de IA atribuido a un grupo de cambios, incluidas las sesiones abandonadas, dividido entre los cambios aceptados de ese grupo. Pon todas las herramientas sobre el mismo denominador, porque licencias, tokens y créditos se cobran en unidades distintas.

Ahora valora los minutos en US$60 por hora, un valor ilustrativo: US$1 por minuto. El lote base cuesta US$900. El lote con IA cuesta 780 en trabajo más 138 en gasto de IA, US$918: un aumento de 2,0 %, o US$30,60 frente a US$30,00 por cambio. Cada cambio ahorró 4 minutos, que valen US$4,00, y la IA detrás de él costó US$4,60.

Solo por costo, este flujo pierde por poco. Su justificación tiene que apoyarse en otra cosa: capacidad liberada, un tiempo de entrega menor, menos defectos o una mejor experiencia. Di cuál es y mídela. Y los minutos valorados con salario no son ahorro de caja a menos que el tiempo liberado se use en algo.

¿Qué errores vuelven engañosos los números de productividad con IA?

Cinco errores se repiten en los números de productividad con IA.

• Multiplicar horas reportadas por el salario. Los autorreportes describen una experiencia. En la encuesta de METR de 2026, la mediana de la velocidad autorreportada fue 3 veces, mientras que la del valor fue de 1,4 a 2 veces. Usa las horas reportadas para decidir dónde mirar.
• Hacer rankings de personas. Quien más usa IA puede tomar tareas más difíciles, correr varios agentes a la vez y revisar más. DORA sugiere desglosar el uso por equipo, aplicación o caso de uso, no por persona. Avisa que los datos no se usan para evaluar a nadie.
• Tratar la falta de datos como cero. Una herramienta sin telemetría aparece con uso cero, y quien la prefiere parece no haber adoptado nada. Señala el hueco como una brecha de cobertura.
• Sustitución de tareas. La IA también hace que las personas intenten trabajo que antes omitían. El análisis de METR de mayo de 2026 muestra que, con supuestos simplificadores, la mejora medida en tareas antiguas es una cota inferior y la medida en tareas nuevas una cota superior de la mejora en valor. Su ilustración usa +33 % y +50 %.
• Cronometrar agentes concurrentes. METR encontró que las mediciones de tiempo no son fiables cuando alguien corre varios agentes a la vez. Cuenta cambios aceptados y una muestra del esfuerzo humano, no la duración de las sesiones.

Los conteos de PR merecen la misma sospecha. En un estudio de 806 proyectos de código abierto que adoptaron Cursor, presentado en MSR 2026, las líneas añadidas subieron 281 % en el primer mes mientras los commits subieron 55 %, así que cada commit llevaba mucho más código. DORA señala que ese volumen amplía la carga de revisión. “Más PR” y “más trabajo entregado” son afirmaciones distintas.

¿Cómo se hace una primera evaluación de 30 días?

Una evaluación de 30 días sigue un flujo de trabajo, una definición de aceptación y un conjunto de fuentes, y termina con una decisión: ampliar, cambiar el flujo o seguir observando. Es una primera lectura. DORA anticipa una caída de productividad cuando un equipo adopta IA y dice que su profundidad y duración siguen siendo impredecibles.

flowchart TD
  accTitle: La evaluación de 30 días de productividad con IA
  accDescr: Los días 1 a 5 fijan la línea base y la definición de aceptación. Los días 6 a 10 conectan las fuentes y marcan los vacíos de cobertura. Los días 11 a 25 registran el esfuerzo en una muestra con revisiones semanales de casos atípicos. Los días 26 a 30 revisan las fallas posteriores y calculan los resultados. La evaluación termina en ampliar, cambiar el flujo o seguir observando.
  A[Días 1 a 5: línea base y definición de aceptación] --> B[Días 6 a 10: fuentes conectadas, vacíos marcados]
  B --> C[Días 11 a 25: esfuerzo en una muestra, revisión semanal de atípicos, encuesta el día 15]
  C --> D[Días 26 a 30: ventana de seguimiento, esfuerzo neto, costo, tiempo de entrega, estabilidad]
  D --> E{Decisión}
  E --> F[Ampliar a más equipos]
  E --> G[Cambiar el flujo y repetir]
  E --> H[Seguir observando otro periodo]

Apunta a al menos 20 cambios comparables por grupo, como número de planificación y no como umbral estadístico. Con menos, reporta los registros y omite el porcentaje.

Preguntas frecuentes sobre medir la productividad con IA

¿La IA hace más lentos a los desarrolladores?

En el experimento de METR de febrero de 2026, quienes repetían tardaron 18 % menos y los nuevos 4 % menos, con intervalos que incluyen el cero, y METR llama a sus datos evidencia muy débil. Su encuesta de mayo de 2026 recogió una mediana autorreportada de 3 veces más velocidad, pero solo de 1,4 a 2 veces más valor. El efecto depende de la tarea, la persona y la herramienta, y hay que medirlo en tu propio equipo.

¿La tasa de aceptación es una buena métrica?

Pertenece a la capa de adopción. Muestra cuántas sugerencias se conservaron, no si el cambio sobrevivió a la revisión o a producción, y no ve lo que pagó quien revisó.

¿Cuánto tarda en notarse el impacto de la IA?

DORA anticipa una caída inicial de productividad y dice que su profundidad y duración son impredecibles, así que no hay una espera fija. Usa los 30 días para saber si puedes medir el flujo.

¿Se puede medir a cada desarrollador?

Se puede, pero no deberías usarlo para evaluarlos. Las diferencias de dificultad, carga de revisión y uso de agentes tapan la señal, y DORA aconseja mirar por equipo.

¿Cómo se miden los agentes que corren en paralelo?

Cuenta los cambios aceptados, el costo de todas las sesiones detrás de ellos y una muestra de minutos humanos de preparación y revisión. El tiempo transcurrido de las sesiones exagera el esfuerzo cuando varios agentes corren a la vez.

¿Cómo se calcula el ROI de la IA sin inflarlo?

Usa el esfuerzo neto con revisión y corrección, suma todo el gasto de IA, incluidas las sesiones abandonadas, y compara con trabajo equivalente sin IA. Después exige un beneficio con nombre: capacidad, tiempo de entrega o calidad.

¿Qué conviene hacer después?

Elige un tipo de cambio que tu equipo repita, como correcciones de bugs o actualizaciones de dependencias. Registra los minutos de preparación, revisión y corrección de veinte de ellos, y el costo de IA detrás de cada uno. Después comprueba qué pasó con esos cambios en producción con la guía de métricas DORA, porque la capa de estabilidad es donde la investigación de 2025 encontró el costo.