Informe GitHub Octoverse 2026: agentes inician más del 40% de los PR
El informe GitHub Octoverse 2026, anunciado el 28 de octubre de 2026 en GitHub Universe, dice que los agentes de inteligencia artificial iniciaron más del 40% de los pull requests de la plataforma en septiembre de 2026, frente al 17% en marzo. Los pull requests fusionados se triplicaron en menos de un año hasta 220 millones al mes. Para las empresas de software, las cifras muestran hacia dónde se mueve el trabajo: los agentes redactan más código, y la revisión, los controles de seguridad y las reglas de fusión cargan ahora con más peso.
Qué midió GitHub este año
El informe mide cuánto trabajo más pasa ahora por GitHub. El vicepresidente ejecutivo de GitHub, Jay Parikh, anunció el informe en GitHub Universe, y sus cifras principales muestran lo rápido que creció la actividad. Los pull requests fusionados se triplicaron en menos de un año hasta 220 millones al mes. Los commits se multiplicaron por más de tres hasta 7,38 mil millones al mes, con la mayor parte del aumento en la segunda mitad del año. El ritmo de repositorios nuevos se duplicó hasta 30,3 millones al mes.
El periodo del informe fue del 1 de octubre de 2025 al 30 de septiembre de 2026. Las cifras de agentes se basan en la detección que hace GitHub de la actividad de agentes en la plataforma. Para algunos desgloses, GitHub usó la propia IA: un LLM clasificó perfiles de usuarios por país, y un modelo de embeddings multilingüe ajustado clasificó los repositorios públicos por sector.
Cuánto del trabajo inician hoy los agentes de IA
Más del 40% de los pull requests en GitHub empezó con un borrador generado por un agente de IA en septiembre de 2026, frente al 17% en marzo. Los agentes iniciaron 110 millones de pull requests solo en septiembre, unas seis veces el volumen de marzo.
El trabajo de los agentes también suele ser más amplio. GitHub encontró que el 87% de los pull requests iniciados por agentes modificaba varios archivos, frente al 79% de los pull requests sin participación detectada de agentes. La proporción de pull requests con agentes fusionados en dos semanas subió del 83% en febrero al 90% en septiembre, mientras que la de los demás se mantuvo cerca del 86%. GitHub aclara que estas cifras describen el tiempo hasta la fusión, no la calidad del código.
Cómo usan los desarrolladores las funciones de agentes de Copilot
Entre los usuarios activos mensuales de GitHub Copilot, el 55% usaba funciones de agentes, frente al 35% un año antes. El uso del agente en la nube de Copilot, que permite a los desarrolladores asignar una tarea para que un agente la termine por su cuenta, creció un 230% interanual, y el uso del chat con agentes creció un 85%.
GitHub también lanzó Copilot Projects en versión preliminar pública. Permite a los desarrolladores coordinar agentes en varios repositorios, darles contexto de archivos de diseño, conversaciones de Slack y notas de reuniones, y revisar el resultado.
Cómo maneja GitHub la revisión del código escrito por agentes
Más código significa más que revisar, y las cifras de GitHub muestran que las herramientas de revisión y seguridad crecen rápido. El uso de la revisión de código asistida por IA y de GitHub Advanced Security creció cada uno más del 90% interanual. Los desarrolladores fusionaron más de 30 millones de pull requests de Dependabot, cerca del doble del volumen de 2025.
Más de 264.000 desarrolladores habían usado pull requests apilados para septiembre. La función divide un cambio grande en pull requests más pequeños que se pueden revisar uno por uno, y quedó disponible para todos el 6 de octubre. GitHub dice que los repositorios que la usaron vieron un aumento del 9% en el código fusionado durante la versión preliminar, aunque no afirma que la función por sí sola lo haya causado.
«Para un equipo que revisa el trabajo de los demás, ha sido una mejora significativa en cómo colaboramos». David Mostoller, ingeniero de software en Comcast, sobre los pull requests apilados
El 28 de octubre, GitHub añadió Copilot code review Max en versión preliminar pública, que ejecuta agentes de revisión independientes sobre modelos de distintos proveedores y combina sus hallazgos. La corrección automática con agentes quedó disponible para todos el 15 de octubre: Copilot propone arreglos para hasta 25 alertas de escaneo de código en un solo pull request y vuelve a ejecutar CodeQL para comprobarlos.
Qué significa el cambio para los líderes de ingeniería
Para una empresa que entrega software, el cuello de botella pasa de escribir código a revisarlo. Cuando los agentes inician más del 40% de los pull requests, el límite de la producción pasa a ser cuántos cambios pueden revisar las personas con confianza.
Los propios controles de GitHub muestran cómo espera que las empresas lo manejen. Las aprobaciones de Copilot, ya disponibles para todos, pueden contar para las aprobaciones obligatorias, pero vienen desactivadas por defecto, los administradores pueden limitar qué rutas de archivos puede aprobar Copilot, y una aprobación se descarta si llegan commits nuevos después. Los equipos que adopten agentes necesitarían reglas de revisión de ese tipo antes de que llegue el volumen.
Preguntas y respuestas
¿Qué proporción de los pull requests de GitHub inician los agentes de IA?
Más del 40% en septiembre de 2026, frente al 17% en marzo, según el informe GitHub Octoverse 2026. Los agentes iniciaron 110 millones de pull requests en septiembre.
¿Cuántos pull requests se fusionan en GitHub cada mes?
Unos 220 millones al mes en 2026, el triple del nivel de hace menos de un año, dice GitHub.
¿Qué es Copilot code review Max?
Una opción de revisión en versión preliminar pública desde el 28 de octubre que ejecuta agentes de revisión independientes sobre modelos de distintos proveedores y une sus hallazgos en una sola revisión. GitHub dice que tarda más y usa más créditos de IA que las opciones Lite y Balanced.
La visión de MOZGII
Cómo lo construiríamos
Cuando los agentes inician gran parte de los cambios, el recurso escaso en un equipo de software ya no es escribir. Es leer con cuidado. Si estuviéramos organizando un equipo para esto, empezaríamos por la ruta de revisión, no por el agente. Cada pull request iniciado por un agente llevaría una nota breve sobre qué cambió y por qué, qué pruebas corrió y qué archivos tocó, para que quien revisa empiece con contexto y no con un diff en bruto.
Mantendríamos los cambios pequeños, porque un cambio pequeño es más fácil de revisar que uno grande, y enviaríamos por regla a un revisor senior todo lo que toque la lógica de inicio de sesión o las bibliotecas compartidas. Las aprobaciones de la IA seguirían desactivadas para esas rutas. Un segundo modelo que revise al primero puede detectar errores, pero una persona seguiría siendo dueña de la decisión de fusionar.
Fallaría donde el volumen supera la atención. Si los revisores enfrentan muchos más pull requests cada día, empiezan a aprobar por costumbre, y las cifras de velocidad se ven bien mientras la calidad cae. Por eso no vigilaríamos el tiempo hasta la fusión. La métrica que vigilaríamos sería la proporción de cambios de agentes fusionados que se revierten o se corrigen en pocas semanas. Después, construiríamos un informe semanal que muestre a los revisores qué tipos de cambios de agentes necesitaron más retrabajo, para que el equipo sepa dónde mirar con más atención.
Fuentes
De dónde salen los datos de esta nota.