El techo invisible de los agentes de código: un solo developer revisa 8 de cada 10 PRs

Es decir: el volumen de código que produce un agente no predice cuánta gente lo revisa. Predice, más bien, cuánto tiempo pasa una sola persona con la vista fija en un diff.

Vale la pena aclarar el alcance del estudio: mide qué pasa dentro de la ventana analizada —quién revisa, quién mergea, con qué frecuencia—, no qué pasa después. Reverts, bugs que aparecen semanas más tarde, o qué tan bien envejece ese código en producción quedan fuera del dataset. Eso no invalida el hallazgo; al contrario, sugiere que el problema real —la calidad sostenida del código agéntico bajo revisión de una sola persona— probablemente sea más grande de lo que estos números ya muestran.

El patrón que no cambia con la escala

Lo más revelador no es el promedio general, sino lo que pasa cuando se sube el volumen. Raida volvió a revisar los equipos pequeños que superaron 30 PRs agénticos en la ventana del estudio —los que más presionaron el sistema— y encontró que la mayoría seguía operando bajo el mismo esquema de un solo revisor.

"Even among the most active small repositories, the majority of agentic PRs continued to follow a single-reviewer workflow. This suggests that increased agentic activity did not necessarily lead to more distributed review practices", explicó Raida a Help Net Security.

Equipos chicos, carga desproporcionada

Los equipos de una a cinco personas no solo usan más agentes: los usan de forma desproporcionada respecto a equipos medianos y grandes. Tiene sentido —son los que menos fricción organizacional tienen para adoptar una herramienta nueva—, pero también son los que menos margen tienen para absorber una cola de revisión que crece sin que crezca el equipo.

Feature vs. fix

El estudio también encontró una diferencia de uso: en flujos de un solo revisor, el tipo de PR más común fue de features nuevas. En flujos con varios revisores o committers, dominaron los PRs de fixes. Los mantenedores solitarios apuntan sus agentes a construir. Los equipos con más de una persona los usan más para reparar.

Por qué la revisión es el verdadero techo

Aquí está el punto que casi nadie está discutiendo en voz alta: la conversación sobre agentes de código lleva dos años centrada en cuánto código pueden generar. Ese problema ya está prácticamente resuelto. El problema que queda —y que este estudio deja ver con números— es que la capacidad de revisión humana no escala al mismo ritmo que la capacidad de generación.

Un desarrollador tiene un número finito de horas para leer diffs, correr pruebas y decidir si algo se mercea o no. Multiplicar los agentes multiplica los PRs, no las horas de revisión disponibles. Los 25 proyectos del estudio que generaron PRs agénticos al ritmo de un desarrollador profesional (usando un benchmark de Worklytics como referencia) son la excepción, no la norma. El resto simplemente no ha llegado ahí todavía —o ha chocado con el mismo techo sin darse cuenta.

Esto conecta con algo que ya se ve en casi todos los coding agents del mercado: la adopción del protocolo MCP (Model Context Protocol) les permite conectarse a más fuentes de datos, más APIs y más herramientas, lo que en teoría multiplica lo que un agente puede automatizar de punta a punta. Pero cada nueva integración también multiplica la superficie que un humano tiene que entender para juzgar si el resultado es correcto. Más contexto para el agente no es gratis para quien revisa.

Lo que esto significa para agencias y developers

Para una agencia como la nuestra, o para cualquier equipo de desarrollo que esté metiendo Claude Code, Copilot o Codex en su flujo diario, el mensaje es directo:

• No optimices solo la generación. Si tu equipo mide éxito en "cuántos PRs abre el agente por semana", está midiendo la mitad del problema. La otra mitad es cuánta gente puede revisar sin quemarse.
• Diseña el proceso de revisión antes de escalar el uso del agente. Definir quién revisa qué tipo de PR (features vs. fixes), con qué checklist y con qué SLA, evita que un solo dev se convierta en el cuello de botella silencioso de todo el equipo.
• Vigila los equipos pequeños. Si tu agencia opera con squads de 3-5 personas por cliente —como suele pasar en consultoría—, este es exactamente el perfil que el estudio identifica como el de mayor uso y mayor riesgo de sobrecarga en revisión.
• El merge rate similar entre revisor único y grupo no es una validación de que "no hace falta más gente". Es una señal de que todavía no hemos estresado el sistema lo suficiente como para ver dónde se rompe.

La lección de fondo es que la productividad de un equipo con agentes de IA no se mide por líneas de código generadas, sino por la velocidad con la que ese código se convierte en algo mergeado, probado y en producción con confianza. Eso sigue siendo, hoy, un problema humano.

En Geek Vibes ya estamos ajustando los flujos de revisión de nuestros propios squads antes de subir la dosis de agentes de código, precisamente para no llegar al mismo techo sin haberlo visto venir. Si tu equipo está en ese punto —generando más código del que puede revisar con calidad— hablemos: comercial@geekvibes.agency.