Los agentes ya redactan el 40% de los PR. ¿Quién revisa?

Más del 40% de los pull requests en GitHub ya empiezan como el primer borrador de un agente de IA. El dato es del informe Octoverse 2026 del propio GitHub, publicado el 28 de octubre y presentado por Satya Nadella en GitHub Universe ese mismo día. En marzo era el 17%. Solo en septiembre, los agentes iniciaron unos 110 millones de pull requests, unas seis veces el volumen de marzo.

El informe también muestra que esos pull requests se aceptan en menos de dos semanas con más frecuencia que el resto. Lo que no muestra es nada sobre la revisión: cuánto tardó, quién la hizo, qué encontró. El número que creció seis veces es el del código que entra al repositorio. Nada en el informe indica que la capacidad humana de revisarlo haya crecido al mismo ritmo.

Qué informó GitHub

Las cifras principales, en palabras de GitHub:

• "Para septiembre de 2026, más del 40% de los pull requests en GitHub empezaron con el primer borrador de un agente, frente al 17% de marzo." Son "110 millones solo en septiembre, unas 6 veces el volumen de marzo".
• GitHub solo cuenta los agentes que puede detectar, y llama a esa señal "un piso, ya que no todo el uso de agentes puede detectarse".
• "En febrero, el 83% de los pull requests con participación de agentes se aceptó en menos de dos semanas, algo por detrás del 86% aproximado de los pull requests sin participación de agentes detectada. Para septiembre, los pull requests de agentes llegaron al 90%, mientras el grupo de comparación se mantuvo en torno al 86%."
• Los pull requests iniciados por agentes "cambian varios archivos con más frecuencia: alrededor del 87%, frente al 79%" del resto.
• El total de pull requests aceptados "más que se triplicó, hasta 1.300 millones", unos 3,5 millones por día. GitHub atiende hoy a más de 225 millones de desarrolladores.

El informe es optimista y, en sus propios términos, tiene razón: los desarrolladores están entregando más. La cobertura independiente, como la de Econotimes, repitió las mismas cifras.

El mecanismo: "aceptado" no es "revisado"

Mira lo que el informe mide y lo que no.

Mide volumen: pushes, commits, pull requests abiertos, pull requests aceptados en menos de dos semanas. Todos subieron, algunos con fuerza.

No informa sobre verificación: tiempo de revisión, número de revisores, comentarios por pull request, pull requests aceptados sin revisión, pruebas agregadas, reversiones, incidentes causados por un cambio. Leímos el informe completo. Nada de eso aparece.

Esa brecha importa porque una tasa de aceptación es fácil de malinterpretar. "El 90% de los pull requests de agentes se aceptó en menos de dos semanas" suena a señal de calidad. En realidad es una señal de aceptación. Dice que los borradores de agentes se aceptan, y se aceptan pronto. No dice si estaban bien, ni con qué atención alguien los miró antes de aceptarlos.

Tres detalles del informe muestran dónde cae la presión:

1. Cambios más grandes. Los pull requests de agentes tocan varios archivos con más frecuencia (87% frente a 79%). Un cambio repartido en muchos archivos es más difícil de revisar bien.
2. La revisión es el nuevo cuello de botella, y GitHub lo sabe. El informe dice que "la revisión es donde los desarrolladores dan forma a lo que vuelve" y que el uso de revisión de código asistida por IA creció más del 90% en un año. También destaca los stacked pull requests, una función para dividir el trabajo en cambios más pequeños, "más fáciles de revisar".
3. Los desarrolladores eligen código que pueden comprobar. TypeScript fue el lenguaje principal del 35% de los repositorios nuevos con señal de agente, frente al 24% de los que no la tenían. La lectura del propio GitHub: quienes trabajan con agentes "se inclinan por lenguajes en los que es más fácil comprobar lo que produce el agente".

GitHub cierra el informe con la frase que más importa: "alguien todavía tiene que decidir si funciona, si corresponde y si está bien". El informe cuenta el código. No cuenta esa decisión.

Por qué es un problema de gestión, no de herramientas

Cuando el volumen de borradores de código crece seis veces en seis meses, la presión sobre el equipo se traslada a todo lo que no creció con él. Hoy eso es la revisión, las pruebas y el criterio de quienes saben cómo debería comportarse el sistema.

Si tu equipo adoptó agentes de programación este año, tu cantidad de pull requests probablemente subió. La pregunta es si tu capacidad de revisión subió con ella, o si las revisiones se acortaron en silencio. Ya escribimos sobre entregar código que no entiendes del todo y sobre un agente que reescribió la prueba que habría detectado el problema. Las dos cosas se vuelven más probables cuando los revisores son minoría.

Qué hacer ahora

• Mide la revisión, no solo las aceptaciones. Sigue el tiempo hasta la primera revisión, los revisores por cambio, los comentarios por pull request y cuántos cambios entran sin una revisión real. Si esos números bajan mientras sube el volumen de pull requests, esa es la señal.
• Mantén pequeños los cambios de agentes. Pide un solo tema por pull request. Divide los cambios grandes antes de la revisión, no después. Un cambio pequeño es la forma más barata de que la revisión sea real.
• Haz que las pruebas sean el primer revisor. Exige que los pull requests de agentes traigan pruebas que fallen sin el cambio y pasen con él. Revisa las pruebas con el mismo cuidado que el código.
• Protege los archivos que importan. Exige un revisor humano con nombre para cambios en autenticación, pagos, permisos, CI, alertas y pruebas. El agente puede proponer esos cambios. No debería ser el único que los aprueba.
• Usa la revisión con IA como filtro, no como veredicto. La revisión asistida por IA atrapa problemas obvios antes de que mire una persona. No debería ser el último control sobre código que escribió otra IA.
• Reserva tiempo de revisión de forma explícita. Si los agentes duplicaron el ritmo del equipo, planifica el tiempo de revisión que viene con eso, en vez de suponer que entra entre todo lo demás.

Construir la disciplina de revisión que permite a un equipo confiar en código escrito por IA es una parte grande de nuestro trabajo de producción. Las herramientas para escribir código mejoraron mucho este año. Las herramientas para saber si está bien siguen siendo, en su mayoría, personas.

Puntos clave

• El Octoverse 2026 de GitHub dice que más del 40% de los pull requests de septiembre empezó con el borrador de un agente, frente al 17% de marzo, unos 110 millones solo ese mes.
• Los pull requests de agentes se aceptaron en menos de dos semanas en el 90% de los casos en septiembre, frente a cerca del 86% del resto, y cambiaron varios archivos con más frecuencia.
• El informe mide volumen, no verificación: no da datos de tiempo de revisión, aceptaciones sin revisión, bugs ni reversiones.
• Los equipos deberían medir la revisión tan de cerca como la producción, mantener pequeños los cambios de agentes, usar las pruebas como primer filtro y exigir revisión humana en áreas sensibles.

Preguntas frecuentes

¿Los agentes de IA escriben el 40% del código en GitHub? No exactamente. GitHub dice que más del 40% de los pull requests de septiembre empezó con el borrador de un agente. Eso cuenta pull requests, no líneas de código, y solo los agentes que GitHub puede detectar, lo que llama un piso.

¿Una tasa de aceptación del 90% significa que el código de agentes es bueno? No. Significa que el 90% de los pull requests de agentes se aceptó en menos de dos semanas. Mide aceptación y rapidez, no corrección. El informe no trae datos de bugs ni de reversiones.

¿La revisión de código con IA es la solución? Ayuda como primera pasada. GitHub dice que el uso de revisión asistida por IA creció más del 90% en un año. Pero usar una IA para aprobar el código de otra IA, sin una decisión humana, deja la misma brecha.

¿Qué debería cambiar primero un equipo? Empezar a medir la revisión: tiempo hasta la primera revisión, revisores por cambio y cuántos cambios entran sin una revisión real. No se puede resolver un cuello de botella que no se mide.