Un estudio recién publicado por investigadores del Rochester Institute of Technology analizó 25,264 pull requests generados por agentes de código —GitHub Copilot, OpenAI Codex y Claude Code— en repositorios de GitHub con más de 100 estrellas. El hallazgo central: el 78.9% de esos PRs pasa por un solo revisor humano, que lee el diff, corrige lo que haga falta y hace merge en solitario. Los agentes escalaron la producción de código. La revisión sigue siendo trabajo de una sola persona. Y eso importa hoy, porque en Geek Vibes vemos a diario cómo los equipos adoptan estas herramientas más rápido de lo que ajustan su proceso alrededor de ellas.
Qué encontró el estudio
Maliha Noushin Raida y Daqing Hou, autores de la investigación, clasificaron cada PR según quién lo revisó y quién hizo el commit final, en una ventana de mayo a julio de 2025. No es una encuesta ni una opinión: es data extraída directamente de GitHub.
Los números clave:
- 78.9% de los PRs agénticos siguen un flujo de revisor único.
- Los repositorios con 1 a 5 colaboradores promediaron 50.2 PRs agénticos en el trimestre, muy por encima de equipos medianos y grandes.
- La mediana general de PRs agénticos por repositorio en tres meses fue de apenas uno o dos.
- El merge rate fue prácticamente idéntico entre flujos de un solo revisor (81.2%) y flujos con múltiples revisores (80.3%).
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.
