La mayoría de los cambios que propone un agente de código en los proyectos públicos de GitHub no los revisa nadie, y cuando alguien los revisa, suele ser otro agente. Si en tu equipo pasa algo parecido, tu tablero de métricas probablemente no lo distinga: una aprobación cuenta igual la haya dado una persona que la haya dado un bot.
Este año han salido tres trabajos con datos sobre cómo se revisa el código que escriben los agentes, y un artículo que propone dejar de revisarlo. Leídos juntos, dejan a tu equipo una pregunta que va antes de cuánto revisar: qué lee hoy una persona antes de que el cambio entre.
Un pull request es la petición para integrar un cambio en el código común del equipo, y la revisión es el momento en que otra persona lo lee y decide si entra. Cuando un agente abre varios al día, ese es el primer punto que se tensa: un estudio con datos de 718 empresas ya vio que la ganancia de los agentes se queda esperando en la revisión. Los trabajos de este año miran qué pasa cuando esa espera se resuelve aprobando.
Lo que se ve en GitHub
Kacper Duma y su equipo, de la Universidad Nicolás Copérnico de Toruń (Polonia), compararon cómo se revisan los pull requests generados por IA y los escritos por personas en los mismos repositorios, con el conjunto de datos público AIDev. Su conclusión, en un trabajo aceptado en la conferencia EASE 2026: la mayoría de los pull requests de agentes no recibe ninguna revisión y, cuando la recibe, la hacen sobre todo otros agentes. La participación humana, cuando la hay, suele tomar la forma de instrucciones al agente para que corrija algo.
Los autores avisan de que eso complica leer las métricas de revisión como prueba de supervisión humana en los estudios a gran escala. Para un equipo pasa lo mismo a pequeña escala: el porcentaje de cambios revisados antes de fusionarse puede estar en el 100 % sin que ninguna persona haya leído el código del agente.
Shyam Agarwal, Courtney Miller, Christian Kästner y Bogdan Vasilescu parten de un análisis parecido de la actividad pública de GitHub: los pull requests de agentes se revisan menos a menudo y se fusionan varias veces más rápido que los de personas. Y avisan enseguida de que la dirección de esas tendencias se invierte con otras decisiones de análisis igual de defendibles. Por eso no se quedan en las trazas, que según ellos muestran qué cambia sin explicar por qué: reúnen 38.709 textos de profesionales (blogs de ingeniería e hilos de Reddit) y codifican una muestra de 3.100 sobre revisión de código. Su conclusión es que la revisión es el punto de control donde se decide el efecto del agente sobre el software, y que ese efecto lo marca el equipo con su experiencia y con cómo organiza la revisión.
Quien más usa el agente aprueba más y también corta más
El tercer dato viene del uso real de Claude Code, el agente de código de Anthropic. Su equipo de Societal Impacts publicó en febrero cómo cambia la supervisión con la experiencia, a partir de sesiones de finales de 2025 y principios de 2026:
Quien más lo usa deja de dar permiso para cada acción y para al agente más a menudo cuando algo no le cuadra. Anthropic lo plantea así: supervisar bien no exige aprobar cada acción, exige estar en posición de intervenir cuando importa. Estos datos miden acciones dentro de una sesión de trabajo y los de GitHub miden pull requests, pero en los dos casos el permiso paso a paso deja de ser la forma habitual de supervisar.
El artículo que propone dejar de revisar
Martin Monperrus va más lejos en un artículo de posición publicado en junio. Según él, los agentes de código «han cruzado un umbral de capacidad» y pueden cumplir todos los objetivos declarados de la revisión de código con menos coste y a más ritmo. El esquema de agentes que escriben y personas obligadas a revisar le parece «un callejón sin salida», porque no da garantías reales y no aguanta el ritmo del desarrollo acelerado por IA.
En lo práctico tiene parte de razón. Una persona no lee con atención una decena de diffs al día de un agente (el diff es la lista de líneas que cambian), y los datos de GitHub dicen que muchos proyectos ya han dejado de intentarlo sin decidirlo. Para un equipo de empresa, su conclusión deja abierta otra pregunta: quién responde de lo que llega a producción. Alguien tiene que haber decidido qué cambios entran sin que los lea una persona y por qué, y esa decisión tiene que estar escrita donde el equipo la vea.
Donde no estoy de acuerdo es en las primeras fases. La revisión humana sigue siendo imprescindible mientras se construyen el harness (todo lo que guía al modelo: subagentes, skills, plantillas y controles) y el contexto. Es ahí donde una persona ayuda a ajustarlos y a mejorarlos.
También lo es al principio de cada funcionalidad, cuando se define, para que no quede ninguna pregunta abierta sin responder. Es lo que ahora llaman grilling.
Límite Los dos estudios de GitHub son de proyectos de código abierto (un equipo de empresa tiene sus propias reglas de revisión), y sus resúmenes no dan porcentajes, así que aquí no se citan cifras. Agarwal y sus coautores avisan de que las tendencias que observan no son estables. El de Monperrus es un artículo de posición, sin datos propios. Los datos de Claude Code son de un solo producto y de su fabricante; Anthropic recuerda que por defecto el producto pide aprobación manual, de modo que parte del aumento puede deberse a que los usuarios cambian la configuración, y que las etiquetas de supervisión las asignó un modelo.
Qué medir antes de decidir cuánto revisar
Antes de discutir si tu equipo revisa demasiado o demasiado poco, conviene saber qué pasa ahora. Con un mes de datos de tu repositorio puedes responder tres preguntas:
- De los pull requests del agente que se han fusionado, ¿cuántos tienen una aprobación o un comentario de una persona? Los de bots y otros agentes no cuentan.
- ¿Cuánto tardan en fusionarse, comparados con los de personas? Un cambio de 400 líneas aprobado en dos minutos difícilmente se ha leído.
- ¿Cuántos se han tenido que revertir o corregir en las semanas siguientes?
Con esos números, el equipo puede dejar a un lado el debate entre «hay que revisarlo todo» y «ya no hace falta revisar» y decidir qué cambios lee siempre una persona y cuáles pueden entrar sin que nadie los lea. Cómo repartir la revisión según el riesgo de cada cambio lo tratamos al leer el Technology Radar 35.
Lo que no conviene es dejar que esa regla la escriba el ritmo del agente. Si nadie decide qué se lee, el equipo acaba aprobando casi todo igualmente, pero sin saber qué ha dejado pasar ni quién lo ha decidido.
Es parte del trabajo de AI-Accelerated Development. Construimos con tu equipo dos cosas que se quedan en tu casa: el contexto en el que trabaja la IA y el proceso con el que trabajáis, de la idea a la documentación actualizada. Si quieres mirar con alguien de fuera qué se revisa hoy en tu equipo, el diagnóstico es gratuito.
Preguntas frecuentes
¿Hay que revisar el código que escribe un agente de código?
Sí, pero cada equipo tiene que decidir con qué profundidad y qué cambios lee siempre una persona. Los estudios de 2026 sobre GitHub muestran que muchos pull requests de agentes se fusionan sin revisión humana, así que la decisión ya se está tomando, aunque nadie la haya escrito.
¿Qué dicen los estudios sobre cómo se revisan los pull requests de agentes?
Un estudio aceptado en EASE 2026 concluye que la mayoría de los pull requests generados por IA en GitHub no recibe revisión y que, cuando la recibe, la hacen sobre todo otros agentes. Otro trabajo de 2026 ve que se revisan menos y se fusionan varias veces más rápido, con el aviso de que esa tendencia se invierte con otras decisiones de análisis.
¿Por qué las métricas de revisión pueden engañar cuando trabajan agentes?
Porque una aprobación o un comentario cuentan igual los haga una persona que un agente. Los autores del estudio de EASE 2026 avisan de que eso complica leer las métricas de revisión como prueba de supervisión humana. En un equipo, la forma de saberlo es contar cuántos cambios del agente tienen una aprobación o un comentario de una persona.
¿Qué es la aprobación automática en un agente de código?
Es dejar que el agente ejecute sus acciones sin pedir permiso en cada paso. Según Anthropic, en Claude Code está activada en cerca del 20 % de las sesiones de quien lleva menos de 50 y en más del 40 % a partir de 750, y quien tiene más experiencia también interrumpe al agente más a menudo.
¿Se acaba la revisión humana del código?
Martin Monperrus lo sostiene en un artículo de posición de junio de 2026: según él, los agentes ya cumplen los objetivos de la revisión y obligar a una persona a revisar todo no da garantías ni escala. Para un equipo de empresa sigue haciendo falta alguien que responda de qué cambios entran sin leer.
¿Qué puede medir un equipo para saber qué revisa de verdad?
Con un mes de datos de su repositorio: cuántos pull requests de agentes fusionados tienen una aprobación o un comentario de una persona, cuánto tardan en fusionarse comparados con los de personas y cuántos se han tenido que revertir o corregir en las semanas siguientes.
Fuentes
- Kacper Duma, Patryk Wróblewski, Jagoda Bobińska, Julia Winiarska y Piotr Przymus, «These Aren't the Reviews You're Looking For: How Humans Review AI-Generated Pull Requests», arXiv:2605.02273, 4 de mayo de 2026 (aceptado en EASE 2026).
- Shyam Agarwal, Courtney Miller, Christian Kästner y Bogdan Vasilescu, «3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse», arXiv:2607.07980, 8 de julio de 2026.
- Miles McCain et al. (Anthropic, Societal Impacts), «Measuring AI agent autonomy in practice», 18 de febrero de 2026.
- Martin Monperrus, «The End of Code Review: Coding Agents Supersede Human Inspection», arXiv:2606.13175, 11 de junio de 2026.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →