Métricas de productividad de desarrollo con IA: ¿qué deberías medir?

El primer tablero de IA que arma casi cualquier equipo muestra la tasa de aceptación de sugerencias, porque es el número que la herramienta entrega gratis. Sube durante unos meses, todos se sienten bien, y nadie sabe explicar qué tiene que ver con el release que se atrasó. La tasa de aceptación mide cuántas veces alguien presionó Tab. Es un dato del editor, no de lo que entrega el equipo.

¿Por qué las métricas de IA más obvias son las equivocadas?

Las métricas de IA más obvias (tasa de aceptación, líneas generadas por IA, porcentaje del código escrito por IA) miden actividad en el momento de escribir, y premian el volumen. También son los números más fáciles de manipular: cuando a un equipo se le mide por líneas generadas, produce más líneas, las necesite o no el trabajo.

El volumen tampoco es neutro. Un análisis de 2025 sobre 211 millones de líneas modificadas encontró que durante 2024 los bloques duplicados de cinco o más líneas se multiplicaron por ocho. Más líneas generadas pueden significar más código que mantener, que es lo contrario de la productividad. Una métrica que sube tanto en el caso bueno como en el malo no te dice en cuál estás.

¿Qué marcos ya definen la productividad de desarrollo?

Tres marcos cubren casi todo lo que necesita un equipo que trabaja con IA, y la IA no reemplazó a ninguno.

Las métricas de entrega de software de DORA. Cinco métricas en dos grupos. Ritmo: tiempo de entrega de un cambio, frecuencia de despliegue y tiempo de recuperación tras un despliegue fallido. Inestabilidad: tasa de fallas en cambios y tasa de retrabajo de despliegues. Describen el sistema de entrega completo, que es donde las ganancias de la IA llegan o se absorben.

SPACE. Cinco dimensiones de la investigación original: satisfacción y bienestar, desempeño, actividad, comunicación y colaboración, y eficiencia y flujo. Su idea central es que ninguna dimensión sola captura la productividad, así que un equipo elige unas pocas medidas repartidas entre varias.

Lo que suma la IA. Tres preguntas que cualquier despliegue de IA tiene que responder además: quién la usa y con qué profundidad (utilización), qué cambió en el trabajo (impacto, leído con las métricas de entrega de arriba) y cuánto cuesta.

El patrón en los tres: las métricas de IA se ponen junto a las de entrega, nunca en su lugar.

¿Qué debería medir de verdad un equipo que programa con IA?

Mide cinco capas, con una métrica principal y una contramétrica en cada una. La contramétrica es el número que se movería si la principal se estuviera manipulando o pagando con un costo oculto.

La capa de experiencia importa más de lo que parece. Parte del valor de las herramientas de IA (menos tiempo leyendo código desconocido, menos cambios de contexto) nunca aparece en Git. Una pregunta de encuesta cada trimestre lo captura. Léela con cuidado, porque el ensayo de METR de 2025 encontró desarrolladores que creían ir un 20 % más rápido mientras eran más lentos según la medición.

¿Cómo se lee una métrica junto con su contramétrica?

Pon el cambio de cada par uno contra el otro y la historia del trimestre suele quedar a la vista. Toma ritmo y calidad: el eje horizontal es cuánto más fusionó el equipo que en el periodo anterior, y el eje vertical es cómo se movió su tasa de fallas (arriba es mejor, así que una tasa de fallas que baja queda alta).

quadrantChart
  accTitle: Cambio de ritmo frente a cambio de calidad
  accDescr: Cuatro cuadrantes. Arriba a la derecha, una ganancia real, más fusiones con menos fallas. Abajo a la derecha, velocidad con retrabajo. Arriba a la izquierda, cuidadoso pero más lento. Abajo a la izquierda, más lento y peor. Hay tres equipos ilustrativos, uno en cada uno de los tres primeros cuadrantes.
  title Ritmo y calidad, cambio frente al periodo anterior
  x-axis Menos fusiones --> Más fusiones
  y-axis Peor calidad --> Mejor calidad
  quadrant-1 Ganancia real
  quadrant-2 Cuidadoso pero más lento
  quadrant-3 Más lento y peor
  quadrant-4 Velocidad con retrabajo
  Equipo A: [0.78, 0.72]
  Equipo B: [0.82, 0.24]
  Equipo C: [0.3, 0.66]

El equipo B es el caso que una sola métrica esconde. Su conteo de pull requests es el mejor de los tres, y en un tablero sin contramétrica sería el equipo que todos copian. Con el par, la siguiente pregunta es clara: ¿qué cambios fallaron, y participó la IA en escribirlos o revisarlos?

La misma lectura sirve para cada capa. Más uso con las sesiones por persona planas significa que más gente probó la IA sin que se volviera parte de su trabajo. Más gasto con un costo por pull request fusionado que baja es un equipo que paga más y recibe más por ello, lo que en general está bien.

¿Cómo se arma un conjunto de métricas de productividad con IA en un mes?

1. Semana uno: línea base de la entrega. Primero ritmo y calidad, desde Git y tu pipeline de despliegue. Esos números existen use o no use IA el equipo, así que son tu “antes”.
2. Semana dos: conecta uso y costo. Paneles de los proveedores y telemetría. Claude Code, por ejemplo, exporta métricas de OpenTelemetry de sesiones, tokens, costo, commits y pull requests (claude_code.cost.usage, claude_code.pull_request.count).
3. Semana tres: envía la encuesta. Una pregunta sobre tiempo ahorrado y otra sobre satisfacción. Anónima, corta, repetida cada trimestre.
4. Semana cuatro: pon las capas en una sola página. El mismo periodo para cada número, comparado con el periodo anterior de la misma duración. Acuerden qué contramétrica abre una conversación.

Después no la toques durante un trimestre. Un conjunto de métricas que cambia cada mes nunca produce una tendencia.

flowchart TD
  accTitle: Un mes para armar las métricas y un trimestre para leerlas
  accDescr: La semana uno fija la línea base de entrega, la dos conecta uso y costo, la tres envía la encuesta y la cuatro pone las capas en una página. Luego, doce semanas sin cambiar las métricas antes de la primera revisión de tendencia.
  W1[Semana 1: línea base de entrega] --> W2[Semana 2: uso y costo conectados]
  W2 --> W3[Semana 3: encuesta enviada]
  W3 --> W4[Semana 4: vista en una página, primera lectura]
  W4 --> Q[Semanas 5 a 16: las mismas métricas, sin cambios]
  Q --> T[Primera revisión de tendencia]

¿Cómo cubre HubBound estas capas?

HubBound Métricas cubre las capas de uso, ritmo y costo con la telemetría de agentes y GitHub, agrega una huella de la IA en la entrega, y deja la calidad y la experiencia a otras fuentes.

• Uso: Activos con IA, Sesiones en el tiempo, Sesiones por herramienta, Mezcla de sesiones por modelo, Skills más usadas y Servidores MCP más usados.
• Ritmo: Commits en el tiempo, Resultado de los pull requests y Tiempo hasta el merge (horas promedio desde que se abre un pull request hasta que se cierra).
• Huella en la entrega: Participación de IA en commits y Líneas añadidas en el tiempo, separadas según si el cambio tiene evidencia de asistencia de IA.
• Costo: Costo en el tiempo, Costo por modelo, Costo por persona, Costo asociado a entregas (gasto ligado a un commit o pull request concreto) y Cobertura de medición, además de la sección Eficiencia de caché.

HubBound no hace encuestas a desarrolladores y no lee datos de despliegues ni de incidentes, así que la tasa de fallas, el tiempo de recuperación y la capa de experiencia necesitan otra fuente. Cada número se compara con el periodo anterior de la misma duración, y la vista es la organización o un miembro, no un equipo.

¿Cuándo fallan las métricas de productividad con IA?

Fallan en cuanto se usan para calificar personas. Cualquier métrica ligada a la evaluación de alguien se convierte en un objetivo, y la gente cumple objetivos de la forma más barata posible: pull requests más pequeños para subir el conteo, más código generado para subir la parte de IA. Usa los números del equipo para decidir y los de cada persona solo para ayudarla, en privado.

Fallan en equipos pequeños, donde unas vacaciones largas mueven todos los promedios. Por debajo de unas diez personas, mira la tendencia de varios periodos e ignora los saltos.

Y fallan cuando la atribución se toma como un hecho. La “evidencia de IA” en un commit es una heurística basada en telemetría y metadatos, no una prueba forense. Sirve para una tendencia, no para afirmar algo sobre un cambio puntual.

¿Qué regla vale la pena conservar?

Nunca reportes una métrica de IA sin la métrica de entrega que la dejaría en evidencia. Tasa de aceptación sin tiempo hasta el merge, porcentaje de IA sin tasa de fallas, gasto sin costo por pull request fusionado: cada uno por separado es un número que solo puede ir en la dirección que alguien quiere.

Un estudio de telemetría de 2025 sobre más de 10.000 desarrolladores es el ejemplo más claro de por qué. Los equipos con más adopción fusionaron un 98 % más de pull requests, y su tiempo de revisión creció un 91 %. Un tablero con solo el primer número habría anunciado un triunfo. Un tablero con el par mostró dónde estaba esperando el trabajo.

xychart-beta
  accTitle: Pull requests fusionados y tiempo de revisión en equipos con mucha adopción
  accDescr: Gráfico de barras con dos cambios que reporta un estudio de telemetría de 2025 para los equipos con mucha adopción. Pull requests fusionados, más 98 por ciento. Tiempo de revisión, más 91 por ciento.
  title "Equipos con mucha adopción de IA (estudio de 2025)"
  x-axis ["Pull requests fusionados", "Tiempo de revisión"]
  y-axis "Cambio (%)" 0 --> 100
  bar [98, 91]