Resumen de la publicación
Un estudio de Harvard sobre 718 empresas encontró que, al adoptar agentes de código, se escriben 30% más líneas pero no se entrega más software: el tiempo de revisión de cada pull request sube 49%. La misma semana, Spotify contó que duplicó sus cambios mensuales y tuvo que reforzar sus controles, y Anthropic pasó de 2.500 a más de 30.000 merges por día y rehízo su control de versiones.
Te cuento por qué leo todo esto como un cuello de botella que se mudó (de escribir a revisar, integrar y operar), por qué tirarle más agentes encima no lo resuelve, y qué cambiaría hoy en code review, CI, ownership y tamaño de PR.
«¿Cuánto código nos escribe el agente?» ya tiene respuesta, y es «mucho». Lo que casi nadie está midiendo es la pregunta siguiente: ¿cuánto software de más llegó a producción?
Entre el 9 y el 13 de octubre se juntaron varios datos que, leídos juntos, responden bastante bien. Y no dan ni para la euforia de las demos ni para el «la IA no sirve».
Qué midió el estudio de Harvard
El trabajo se llama «Artificial Intelligence in the Firm: Bottlenecks in Software Production», de Fiona Chen y James Stratton (Harvard). Usa datos de Jellyfish, una plataforma de métricas de ingeniería: unos 300 millones de eventos de trabajo (commits, issues de Jira, calendarios) de 718 empresas, entre enero de 2021 y marzo de 2026.
Comparan empresas que adoptaron agentes antes contra las que lo hicieron después, y siguen el efecto por toda la cadena, desde la línea de código hasta la funcionalidad entregada:
- Producción intermedia: +30% de líneas de código, +20% de commits y +23% de pull requests.
- Software entregado: las issues y épicas de Jira resueltas (es decir, trabajo que llegó a producción) suben un poco, pero sin significancia estadística. El estudio descarta una mejora mayor al 12%.
- Revisión: el tiempo para revisar un pull request sube 49%, los PR con cambios pedidos casi se duplican, los comentarios por PR suben 35% y hay 14% más gente haciendo code review.
- Empleo: no encuentran cambios atribuibles a la IA, ni para arriba ni para abajo.
Dos detalles me parecen clave. El primero: el tamaño de cada PR no cambió de forma significativa, así que la revisión no se alarga porque los PR sean más grandes, sino porque llegan más y con más cosas para corregir.
El segundo: casi el 80% de las empresas ya había usado IA para revisar código en marzo de 2026, pero solo el 23,3% de los comentarios de revisión los generó una IA. La revisión sigue siendo, en su enorme mayoría, trabajo humano.
La letra chica: es un «job market paper» (el trabajo con el que un doctorando sale a buscar puesto), sin revisión de pares publicada y con datos hasta marzo. Pero la muestra es enorme y coincide con lo que vengo viendo en equipos reales.
Cuando la ola llega a casa
Un paper se puede discutir. Lo difícil de ignorar es que, en la misma semana, dos empresas grandes contaron lo mismo desde adentro.
Spotify: el doble de cambios, y los controles corriendo atrás
En su blog de ingeniería, Spotify contó que sus cambios mergeados por mes pasaron de unos 8.100 a 17.000 en un año (medido en agosto), sobre casi 3.000 servicios en producción. InfoQ lo levantó el 12 de octubre.
Lo honesto del texto es el diagnóstico de sus incidentes: el código escrito por IA no fue un causante directo relevante. El problema fue que el volumen de cambios creció más rápido que algunos de sus controles de verificación.
Lo que ajustaron no fue el agente, fue todo lo que viene después:
- Monitoreo de punta a punta en el pipeline de contenido.
- Más capacidad de rollback (volver atrás un cambio rápido).
- Prioridades de carga y planificación de capacidad rehechas.
- Los cambios automáticos ahora se programan en el horario laboral del equipo dueño del servicio.
Y hay una frase que me encantó: el tamaño y la complejidad de los PR vienen subiendo, y dicen que no van a reescribir los umbrales de alerta «para sentirse mejor».
Anthropic: de 2.500 a 30.000 merges por día
El caso extremo lo contó Anthropic el 13 de octubre en «Redesigning source control at Anthropic». En mayo mergeaban unos 2.500 cambios por día; en septiembre, más de 30.000. Dicen textualmente que el cuello de botella ahora es toda la infraestructura pensada a escala humana: control de versiones, builds y CI.
Su respuesta fue reemplazar Git por un sistema propio (Scion) y armar una herramienta nueva de revisión (Antique), cuyas reglas de aprobación distinguen un cambio trivial de uno que toca lógica sensible. Las personas siguen revisando cada cambio, pero miran la intención y no cada línea.
No todos vamos a escribir nuestro propio Git, pero la señal es clara: cuando escribe el agente, lo primero que se rompe es la cañería.
Más agentes no destapa el cuello
La tentación obvia es contestar con más IA: si un agente escribe rápido, pongamos cien. Esa semana salieron dos datos que muestran la tensión.
Del lado entusiasta, Anthropic sacó en beta los workflows dinámicos de Claude Managed Agents: un agente líder arma un programa que reparte el trabajo entre hasta 1.000 subagentes por corrida. En su propia prueba, escondieron 70 bugs en un código de 116.000 líneas: un solo agente encontró entre 14 y 27 según la corrida, y el workflow encontró 66 de manera consistente.
Es un resultado fuerte, aunque es la prueba del propio vendedor y no vino con una comparación de costos. La documentación, de hecho, pide fijar un presupuesto por sesión porque cada agente de la corrida consume tokens.
Del lado escéptico, Vals AI comparó agentes solos contra equipos construyendo 50 aplicaciones web completas, con GPT-6 Sol y Claude Opus 5.5. Los equipos costaron entre 1,8 y 5,1 veces más por aplicación, y de cuatro comparaciones solo una mostró una mejora estadísticamente significativa. El caso más caro: Opus en esfuerzo máximo pasó de 23,77 a 122 dólares por app para ir de 89,8% a 93,2% de tests aprobados, una diferencia que no llegó a ser significativa.
Encontrar bugs se reparte bien en paralelo; construir una aplicación coherente, no tanto. Y en los dos casos, lo que sale del enjambre tiene que pasar por una persona que lo entienda, lo apruebe y se haga cargo cuando falle.
Sesenta y seis hallazgos son sesenta y seis cosas para triar. Si tu cuello de botella ya era la revisión, más agentes lo agrandan.
Jevons llegó a tu repositorio
La paradoja de Jevons es una idea del siglo XIX: cuando algo se vuelve más eficiente y barato, en vez de usarse menos, se usa muchísimo más. Esta semana a16z la aplicó a la IA con datos hasta agosto: el precio de los tokens sigue cayendo, pero el alquiler de una GPU H100 se mantiene o sube, porque la demanda crece más rápido de lo que baja el costo.
Lo mismo pasa adentro de un equipo. El código se volvió barato, entonces se produce mucho más, y lo que no se abarató (la atención de la persona que revisa, el pipeline de CI, la guardia de los sábados) pasa a ser el recurso escaso.
El paper de Harvard lo explica con un modelo de dos canales muy útil para cualquier líder técnico. Si la IA solo te hace escribir más rápido, alcanza con mover gente hacia la revisión; si además empeora el borrador que llega a revisar, eso no se arregla reorganizando sino con mejor tecnología.
Ya hablamos acá de que el agente propone y vos decidís. Este estudio le pone número a lo que cuesta ese «decidir» cuando el agente produce mucho más rápido de lo que podemos leer.
Qué cambiaría hoy en un equipo de ingeniería
Los autores cierran con dos recomendaciones que suscribo: medir la cadena completa e invertir en la revisión en vez de solo producir más código. Así lo bajaría yo a tierra.
Medir software entregado, no líneas
Si tu tablero de adopción de IA muestra líneas generadas, commits o PR abiertos, estás midiendo actividad. Lo que importa es el throughput (cuánto trabajo terminado sale por semana) junto con su estabilidad:
- Funcionalidades o issues que llegaron a producción.
- Tiempo desde que se abre un PR hasta que se mergea, y cuánto de eso es espera de revisión.
- Tasa de cambios que fallan en producción y de retrabajo.
Code review con reglas según el riesgo
Revisar todo con la misma profundidad ya no escala. Lo que hizo Anthropic con Antique se puede imitar sin escribir una herramienta: reglas de aprobación que separen un cambio de configuración trivial de uno que toca pagos, permisos o datos personales, y que el segundo siempre lo vea alguien que conoce ese código.
CI que aguante el doble de volumen
Si los cambios se duplican, tus tests, tu pipeline y tu capacidad de volver atrás tienen que acompañar. Spotify lo aprendió con incidentes: si la verificación va más lenta que el desarrollo, la diferencia la paga el usuario.
Ownership explícito de lo que escribe el agente
Cada cambio, lo haya escrito quien lo haya escrito, tiene que tener una persona dueña que responda por él. Me gustó mucho el detalle de Spotify de mandar los cambios automáticos en el horario del equipo responsable: es una forma simple de que siempre haya alguien despierto para hacerse cargo.
PR chicos, aunque el agente pueda hacerlos enormes
El agente no se cansa de escribir, el revisor sí. Un PR que se pueda entender en una sentada sigue siendo la mejor herramienta para que la revisión sea real y no un sello de goma, y conviene pedir que el agente parta el trabajo en cambios chicos desde el principio.
El cuello se movió, no desapareció
Nada de esto quiere decir que los agentes no sirvan: escriben más, encuentran bugs que se nos escapan y aceleran migraciones. Lo que dicen los datos es que la ganancia se cobra recién cuando el resto del sistema (revisar, integrar, operar) acompaña.
La pregunta para el próximo planning no es cuánto código escribió la IA el trimestre pasado. Es dónde se te está acumulando el trabajo hoy.
En tu equipo, ¿ya se nota la cola de PR esperando revisión? ¿Qué cambiaron para absorberla? Te leo en los comentarios.
