Los agentes de código suben un 30 % el código, pero no lo que se entrega

Le pediste al agente de código una funcionalidad y la tuviste lista en una tarde. Abriste el pedido de cambios para que alguien del equipo lo revise y ahí quedó: cuatro días esperando. Cuando por fin lo miraron, volvió con seis comentarios, la mitad sobre cosas que el agente cambió sin que se lo pidieras. La tarde que ganaste se perdió en la semana que siguió.

No te pasa solo a vos. Un estudio de dos economistas de Harvard, que se volvió uno de los temas más discutidos entre desarrolladores el 12 de octubre, lo midió en 718 empresas: con agentes de código se escribe un 30 % más, pero los equipos no terminan más trabajo. Abajo están los números, por qué la ganancia se pierde en la revisión, y cinco cosas que podés hacer antes de mandar cada cambio. Te van a llevar unos quince minutos por pedido, y son los minutos que más rinden de todo el proceso.

Qué midió el estudio

El estudio se llama “Artificial Intelligence in the Firm: Bottlenecks in Software Production” (abre en una pestaña nueva) (“La inteligencia artificial en la empresa: cuellos de botella en la producción de software”). Sus autores, Fiona Chen y James Stratton, trabajaron con datos de Jellyfish, una empresa que vende un sistema para medir la actividad de los equipos de ingeniería. Juntaron unos 300 millones de registros de trabajo de cerca de 700.000 personas, entre enero de 2021 y marzo de 2026: qué código subió cada una a GitHub, qué tareas cerró en Jira (el sistema donde se organizan las tareas de un proyecto), cuánto tiempo pasó en reuniones.

La comparación es simple de entender. Cada empresa adoptó las herramientas de IA en un momento distinto, según cuánto tardaron sus áreas de seguridad y de compras en aprobarlas. Entonces se puede comparar a las que las adoptaron antes con las que todavía no, y ver qué cambió.

El estudio separa dos tipos de herramienta, y la diferencia importa:

• Un asistente completa código mientras escribís, como el autocompletado de Copilot. Vos seguís escribiendo; él te ahorra teclas.
• Un agente de código, como Claude Code, Cursor o Codex, recibe una tarea, abre archivos, ejecuta comandos y entrega el cambio hecho.

Los números

Primero, lo que pasa con el código escrito. Un commit es cada vez que se guarda un cambio en el historial del proyecto, y un pull request es el pedido formal para que ese cambio se sume al código principal, que alguien del equipo tiene que revisar y aprobar.

Por persona, por mes	Con asistente	Con agente
Líneas de código	+12 % (no significativo)	+30 %
Commits	+9 %	+20 %
Pull requests	+5 % (no significativo)	+23 %

Con agentes, cada persona suma unas 1.500 líneas más por mes. Hasta acá, la promesa se cumple.

Después, lo que importa: ¿se termina más trabajo? Los autores lo miden con las tareas y los proyectos cerrados en Jira, que se cierran cuando el código ya está funcionando en producción. Ahí el efecto es tan chico que no se puede distinguir de cero. Como mucho, el trabajo terminado sube un 12 %: menos de la mitad del 30 % de código extra. Tampoco cambió la cantidad de gente empleada en esas empresas, ni junior ni senior.

Adónde se fue el tiempo

Escribir código es solo una parte del trabajo. Según el mismo estudio, un desarrollador pasa entre el 30 % y el 42 % de su tiempo escribiendo. El resto se va en planificar, revisar el código de otros y probar. Si acelerás una sola etapa, el trabajo se amontona en la siguiente.

Y se amontonó en la revisión. Con agentes:

• Un pull request pasaba en promedio 7 días desde que se mandaba hasta que se aprobaba. Pasó a unos 10 y medio: un 49 % más.
• Los pull requests que vuelven con un pedido formal de correcciones pasaron del 13 % al 25 %. Casi el doble.
• Los comentarios por pull request subieron un 35 %.
• La parte del equipo que dedica tiempo a revisar creció un 14 %.

Hay un dato que cambia cómo leer todo esto: los pull requests no se hicieron más grandes. Tienen la misma cantidad de líneas que antes. O sea que el problema no es solo que llegan más cambios, sino que cada cambio necesita más correcciones. El modelo que proponen los autores lo dice así: la IA cambia cuánto código se escribe, pero también cuántos errores trae ese código, y cada error es trabajo extra para quien revisa.

Además de los datos, los autores entrevistaron a ingenieros de distintas empresas y citan algunas respuestas en el paper. Esta es de un desarrollador junior:

La gente podía hacer muchísimos commits rápido, pero la revisión seguía siendo el cuello de botella. En un proyecto, solo un ingeniero senior podía aprobar cambios, porque era el que conocía el código. Estaba tan desbordado que podía revisar lo mío una vez por semana. Y después de algunas caídas causadas por código hecho con IA, se agregó una regla que exigía la aprobación de un senior para ese código, lo que trabó todavía más la revisión.

La revisión con IA no lo resolvió

La respuesta obvia es que la IA revise lo que escribió la IA. Las empresas lo probaron: en marzo de 2026, casi el 80 % usaba alguna herramienta de revisión automática. Pero esas herramientas escriben solo el 23 % de los comentarios, y apenas el 11 % de los pull requests recibe alguno. Quien aprueba sigue siendo una persona, y el cuello de botella sigue ahí.

Cinco cosas que podés hacer antes de mandar el cambio

El estudio no dice que los agentes no sirvan. Dice que el tiempo ganado se pierde en la revisión, y una parte grande de esa revisión depende de cómo llega el cambio. Esto es lo que está en tus manos:

1. Revisalo vos primero, como si fuera de otro

Antes de pedir revisión, abrí tu propio pull request y leé los cambios línea por línea, en la misma pantalla donde los va a ver tu compañero. Vas a encontrar archivos que el agente tocó sin necesidad, nombres raros, código de prueba que quedó olvidado. Cada cosa que corregís vos es un comentario menos y una vuelta menos. En este artículo está la lista de qué mirar.

2. Sacá lo que no pediste

Los agentes tienden a “mejorar” cosas de paso: reordenan importaciones, renombran una variable en otro archivo, reformatean una función entera. Eso infla el cambio y obliga a revisar líneas que no tienen nada que ver con la tarea. Si el agente tocó algo que no era parte del pedido, revertilo. Y la próxima vez, decile explícitamente qué no tiene que tocar: una buena especificación ahorra este paso.

3. Mostrá que lo probaste

“Debería andar” obliga a quien revisa a comprobarlo por su cuenta. Corré las pruebas antes de mandarlo y contá en la descripción qué probaste a mano. “Probé el formulario con un correo inválido y con uno vacío; los dos muestran el error” le ahorra a tu compañero hacer lo mismo.

4. Explicá el porqué y dónde mirar

Una descripción corta cambia cómo se revisa un cambio. No hace falta que sea larga; alcanza con esto:

## Qué cambia
Los pedidos con cupón vencido ahora se rechazan antes de cobrar.

## Por qué
Hoy se cobraba el precio sin descuento y el cliente se quejaba después.

## Dónde mirar con atención
- `validarCupon()`: la comparación de fechas usa la zona horaria del servidor.

## Qué es mecánico
- Los cambios en `tipos.ts` son solo el campo nuevo.

## Cómo lo probé
- Pruebas automáticas pasan.
- Cupón vencido, vigente y sin cupón, a mano en el entorno local.

La sección “dónde mirar” es la que más rinde: le dice a quien revisa dónde poner la atención y dónde puede pasar rápido.

5. Separá lo mecánico de lo importante

Si el cambio incluye una parte mecánica (renombrar algo en treinta archivos, mover carpetas) y una parte con lógica nueva, mandalas en dos pull requests distintos. El mecánico se aprueba en cinco minutos; el importante se revisa con calma. Mezclados, el importante queda escondido entre ruido.

Si organizás al equipo

El estudio deja dos conclusiones para quien dirige un equipo. La primera: contar líneas o commits no mide lo que rinde la IA, porque esos números suben aunque no se entregue nada más. Lo que conviene medir es cuánto tarda un cambio en aprobarse y cuántos vuelven con correcciones.

Si tu repositorio está en GitHub, podés ver el primer número hoy. Este comando usa gh, la herramienta oficial de GitHub para la terminal, y jq, un programa para procesar datos en formato JSON. Calcula cuántos días tardaron en promedio los últimos cincuenta pull requests aprobados:

gh pr list --state merged --limit 50 --json createdAt,mergedAt \
  | jq '[.[] | ((.mergedAt | fromdate) - (.createdAt | fromdate)) / 86400] | add / length'

Corrélo hoy y dentro de un mes. Si sube, la revisión se está trabando.

La segunda conclusión: si una etapa se acelera, el cuello de botella se pasa a otra, y hay que mover gente hacia ahí. En la práctica, eso significa tratar la revisión como trabajo planificado, con horas asignadas en cada semana, y no como algo que se hace en los ratos libres entre tarea y tarea.

Ahora lo que escasea es quien lee

Durante años, el límite de un equipo fue cuánto código podía escribir. Los agentes corrieron ese límite, y ahora el límite es cuánto código pueden leer y entender las personas que lo aprueban. Eso no se arregla escribiendo más rápido. Se arregla mandando cambios que se puedan revisar rápido: chicos, probados y explicados. Esa parte la sigue haciendo una persona, y es la que decide si la tarde que ganaste con el agente se convierte en algo que llega a producción.