La adopción de IA no es productividad con IA

El tablero dice que casi todos los ingenieros usaron IA este mes, contra más o menos la mitad en primavera. El roadmap va exactamente igual de atrasado que en primavera. Las dos cosas son ciertas, y la segunda no contradice a la primera, porque miden cosas distintas.

¿Por qué más adopción de IA no significa más productividad?

La adopción de IA cuenta insumos: personas, sesiones, tokens, sugerencias aceptadas. La productividad es un resultado: software que funciona y llega a los usuarios, con un costo y una calidad que el negocio acepta. Entre las dos está todo el sistema de entrega (revisión, pruebas, release, coordinación), y la IA acelera solo la parte donde se escribe el código.

Cuando un paso de un sistema se acelera, el trabajo se acumula en el siguiente. Si los agentes ayudan a cada desarrollador a abrir el doble de pull requests y la cantidad de revisores no cambia, crece la fila frente a la revisión. La adopción subió. El ritmo al que el trabajo terminado sale del sistema puede no moverse en absoluto.

flowchart TD
  accTitle: Dónde acelera la IA la entrega y dónde espera el trabajo
  accDescr: Cuatro pasos en cadena. Escribir código es más rápido con IA. La revisión es donde se acumulan los pull requests extra. Las pruebas y el release van al ritmo de antes. El trabajo terminado sale al ritmo del paso más lento.
  W[Escribir código: más rápido con IA] --> Q[(Fila de pull requests en espera)]
  Q --> R[Revisión: mismos revisores, mismas horas]
  R --> T[Pruebas e integración]
  T --> D[Release a los usuarios]
  D --> O[Trabajo terminado por semana: lo fija el paso más lento]

Es el resultado más viejo de la investigación de operaciones, aplicado al código: acelerar un paso que no es la restricción alarga la fila frente a la restricción y no cambia nada más.

¿Qué dice la evidencia sobre la IA y la productividad de los desarrolladores?

La evidencia se separa con claridad según lo que midió cada estudio: las tareas controladas suelen mostrar ganancias, los códigos reales muestran resultados mixtos, y los datos a escala de organización muestran que las ganancias se absorben más adelante.

Dos hallazgos de esa tabla importan más que el resto para quien mira un tablero. Primero, la brecha de percepción de METR: desarrolladores que, medidos, fueron más lentos creían que iban más rápido. Cualquier afirmación de productividad basada solo en “cuánto más rápido te sientes” hereda ese error. Segundo, el patrón de la telemetría: cuando la adopción es alta, la producción extra aparece como pull requests más grandes y revisiones más largas, y los números de la organización no se mueven.

¿Adónde van las ganancias individuales?

Las ganancias individuales van a las partes de la entrega que la IA no acelera, sobre todo la revisión y el retrabajo. El estudio de telemetría midió pull requests un 154 % más grandes y un tiempo de revisión un 91 % mayor en los equipos con más adopción. Un cambio más grande tarda más en revisarse, y una persona que revisa solo puede leer cierta cantidad al día.

xychart-beta
  accTitle: Cambios medidos en los equipos con mucha adopción en un estudio de telemetría de 2025
  accDescr: Gráfico de barras. Tareas completadas, más 21 por ciento. Pull requests fusionados, más 98 por ciento. Tamaño de los pull requests, más 154 por ciento. Tiempo de revisión, más 91 por ciento. Bugs por desarrollador, más 9 por ciento.
  title "Equipos con mucha adopción, cambio en un estudio de 2025"
  x-axis ["Tareas", "PR fusionados", "Tamaño del PR", "Revisión", "Bugs por dev"]
  y-axis "Cambio (%)" 0 --> 160
  bar [21, 98, 154, 91, 9]

Lee las cinco barras como dos grupos. Tareas y pull requests fusionados son lo que un equipo celebraría. El tamaño de los pull requests, el tiempo de revisión y los bugs son lo que paga otra persona del equipo. Las cinco subieron juntas.

Parte de la ganancia también se convierte en código que hay que atender después. Un análisis de 2025 sobre 211 millones de líneas modificadas encontró que en 2024 los bloques duplicados de cinco o más líneas se multiplicaron por ocho, y que fue el primer año en que las líneas copiadas y pegadas superaron a las líneas movidas (refactorizadas). La duplicación es rápida de escribir y lenta de mantener, así que aparece como velocidad en un trimestre y como costo en el siguiente.

Nada de esto significa que la IA no ayude. Significa que la ayuda cae en un paso y que la medición tiene que seguir al trabajo por el resto del camino.

¿Qué pasa cuando un equipo duplica sus pull requests y mantiene a sus revisores?

Un ejemplo pequeño hace visible la fila. Los números son ilustrativos. Un equipo de ocho desarrolladores abre 30 pull requests por semana y sus revisores pueden terminar unos 34. Luego el equipo adopta agentes, y en la semana tres los pull requests abiertos suben a 45 por semana mientras la capacidad de revisión sigue igual.

xychart-beta
  accTitle: Pull requests abiertos, fusionados y en espera durante seis semanas
  accDescr: Gráfico de líneas ilustrativo. Los abiertos suben de 30 a 46. Los fusionados se quedan entre 30 y 34. Los que esperan crecen de 4 a 50 después de la semana tres.
  title "Equipo ilustrativo: abiertos, fusionados y en espera"
  x-axis ["S1", "S2", "S3", "S4", "S5", "S6"]
  y-axis "Pull requests" 0 --> 55
  line [30, 31, 45, 45, 46, 46]
  line [30, 31, 34, 34, 34, 34]
  line [4, 4, 15, 26, 38, 50]

La línea azul son los abiertos, la verde los fusionados y la cobre los que esperan. En la semana seis la línea cobre es la más alta de las tres. Los pull requests fusionados subieron cuatro por semana, lo máximo que la revisión podía absorber. Un tablero de adopción mostraría un salto del 50 % en la producción. Un tablero de entrega mostraría una ganancia modesta y una fila que, en la semana seis, tiene más de una semana de capacidad de revisión del equipo. El tiempo hasta el merge sube con ella, porque cada pull request nuevo ahora espera detrás de los pendientes.

Recortar la IA casi nunca ayuda. Lo que ayuda es abaratar cada revisión: pull requests más pequeños, una skill o un subagente de revisión que verifique lo básico antes de que mire una persona, y un acuerdo explícito sobre qué tiene que leer quien revisa y qué ya cubren las pruebas.

¿Cómo mide un equipo adopción y productividad sin confundirlas?

Mantén dos conjuntos de números separados y léelos uno junto al otro para el mismo periodo, sin calcular un vínculo causal entre ellos.

Después lee las dos columnas juntas. Adopción arriba y tiempo hasta el merge estable: las ganancias están llegando a la entrega. Adopción arriba y tiempo hasta el merge subiendo: la revisión es el cuello de botella, y empujar más la adopción lo empeora. Adopción arriba y tasa de fallas subiendo: la velocidad se está pagando con calidad.

HubBound Métricas está pensado para leerse así. Reporta la adopción (Activos con IA, Sesiones por herramienta, Participación de IA en commits) y la entrega (Resultado de los pull requests, Tiempo hasta el merge, Líneas añadidas) para el mismo periodo, cada una comparada con el periodo anterior de la misma duración. Muestra las dos lado a lado y a propósito no calcula un vínculo entre ellas, porque en un tablero una correlación se confunde fácil con una causa.

¿Cuándo tiene sentido reportar solo la adopción?

Reportar solo la adopción tiene sentido al inicio de un despliegue, cuando la pregunta de verdad es “¿la gente la está usando?”. También es el número correcto para decidir licencias: una licencia que nadie abre es un costo sin retorno posible, diga lo que diga la investigación sobre productividad.

Es el número equivocado para cualquier frase del tipo “la IA nos hizo un X % más rápidos”. Esa afirmación necesita una métrica de resultado, una línea base de antes del cambio y honestidad sobre todo lo demás que cambió en el mismo periodo.

¿Qué deberían llevarse de esto los líderes de ingeniería?

Pon la medición donde el trabajo espera, no donde empieza. La investigación apunta en una sola dirección: la IA acelera la escritura de código, y el tiempo ahorrado se acumula frente a la revisión, las pruebas y el release. Por eso el número más informativo de un despliegue de IA muchas veces ni siquiera es una métrica de IA. Es el tiempo hasta el merge, o el tiempo de revisión, seguido mientras sube la adopción.

Si ese número se mantiene mientras la adopción crece, el equipo está absorbiendo la producción extra. Si sube, ninguna cantidad de adopción se va a convertir en entrega hasta que cambie el paso de revisión: pull requests más pequeños, skills y subagentes de revisión que comprueben lo básico primero, o simplemente más personas revisando. Nuestro artículo sobre cómo medir la adopción de IA cubre el lado de la adopción de ese par.