Octoverse 2026: el 40 % de los pull requests ya los empieza un agente

Entrás a la lista de pull requests de un proyecto (los pedidos para sumar un cambio al código principal) y la mitad dice que los preparó un agente. No es un proyecto raro: es lo que está pasando en todo GitHub. Y si vos todavía escribís cada cambio a mano, el Octoverse de GitHub muestra qué tan común es ya trabajar así.

El 28 de octubre, GitHub publicó el Octoverse 2026 (abre en una pestaña nueva), su informe anual sobre cómo se programa en la plataforma. Abajo están los números del último año, cómo encajan con el estudio de Harvard que se discutió este mes y qué tienen en común los proyectos donde trabajar con agentes sale bien. Son diez minutos de lectura y tres cambios que podés aplicar en tu repositorio esta semana.

Qué es el Octoverse

Cada año, GitHub mide lo que pasa en su plataforma: cuánta gente programa, en qué lenguajes, cuánto código se sube y cómo cambia la forma de trabajar. Este año cubre los doce meses que terminaron el 30 de septiembre de 2026, y ya son más de 225 millones de desarrolladores. Lo presentó Satya Nadella, el director de Microsoft, en la conferencia anual de GitHub.

La conclusión principal la dice el propio informe en una frase: “el primer paso ahora es pedirle el trabajo a un agente, y la revisión es donde el desarrollador ajusta lo que el agente entrega”.

Los números

Ahora los agentes empiezan el trabajo, no solo ayudan. En marzo, el 17 % de los pull requests arrancaba con un primer borrador hecho por un agente. En septiembre, el 40 %: unos 110 millones en un solo mes. Es más del doble en seis meses.

Los commits, los envíos y los pull requests aprobados se triplicaron. Comparado con el año anterior:

En doce meses	2025	2026
Commits (cambios guardados en el historial)	12.900 millones	34.300 millones
Pushes (envíos de cambios a GitHub)	6.700 millones	17.900 millones
Pull requests aprobados	538 millones	1.300 millones

Los cambios de los agentes son más amplios. El 87 % de los pull requests que empieza un agente toca más de un archivo, contra el 79 % de los que empieza una persona.

Y se aprueban. Este es el dato que más llamó la atención: en febrero, el 83 % de los pull requests de agentes se aprobaba en menos de dos semanas, contra el 86 % de los escritos a mano. En septiembre, los de agentes llegaron al 90 % y pasaron adelante.

Por qué el Octoverse no contradice al estudio de Harvard

El estudio de Harvard encontró que, con agentes, cada pull request tardaba un 49 % más en aprobarse. El Octoverse muestra que los de agentes se aprueban más rápido que los demás. Los dos datos son compatibles, porque miden cosas distintas, en momentos y poblaciones distintos:

• Miden otra cosa. Harvard midió cuántos días tarda en promedio un pull request en aprobarse. El Octoverse mide qué porcentaje se aprueba antes de dos semanas. Si un equipo antes aprobaba en tres días y ahora en cinco, para Harvard tardó más. Para el Octoverse no cambió nada, porque los dos casos entran en “menos de dos semanas”.
• Miran otro momento. Los datos de Harvard llegan hasta marzo de 2026, cuando solo el 17 % de los pull requests empezaba con un agente. Desde entonces mejoraron los modelos, las herramientas y, sobre todo, la forma de trabajar de los equipos.
• Miran otra población. Harvard estudió 718 empresas con datos internos de una plataforma de métricas. El Octoverse cuenta todo GitHub, incluidos millones de proyectos personales donde la misma persona escribe y aprueba.

Hay un cuidado más. En su sección de metodología, el Octoverse explica en detalle cómo calculó países e industrias, pero no cómo decide que un pull request “lo empezó un agente”. Conviene leer esos números como una dirección clara, no como una medición exacta.

Qué hacen distinto los proyectos donde funciona

Más interesante que el 40 % es lo que el informe deja ver sobre cómo trabajan los equipos a los que les va bien.

Le explican el proyecto al agente

Los repositorios que tienen archivos de configuración para agentes (un AGENTS.md, por ejemplo, donde dice cómo correr las pruebas, qué convenciones usa el proyecto y qué no hay que tocar) tienen ocho veces más commits que los que no.

Eso no significa que el archivo multiplique el trabajo: lo más probable es que los proyectos más activos sean los que lo escriben. Igual tiene sentido: un agente que sabe cómo funciona el proyecto se equivoca menos. En este artículo están los seis cambios que más le sirven a un repositorio, y qué conviene poner en ese archivo.

Mandan cambios chicos, uno detrás de otro

Más de 264.000 desarrolladores ya usan pull requests apilados en GitHub. En vez de un cambio enorme, mandás una cadena de cambios chicos, donde cada uno se apoya en el anterior. Por ejemplo: primero el cambio en la base de datos, después la lógica que lo usa, después la pantalla. Cada uno se revisa en minutos, y no hay que esperar a que se apruebe el primero para seguir trabajando en el segundo.

Es la respuesta directa al problema de Harvard: si la revisión es el cuello de botella, la solución es mandar cambios que se puedan revisar rápido.

No se casan con un modelo

El 61 % de los usuarios de Copilot ya usa más de un modelo de IA (en mayo era el 50 %), y el más usado concentra solo el 25 % de los pedidos. Los equipos eligen un modelo rápido para lo mecánico y uno que razona más para planificar. Es lo que contamos en elegir agente de código ya no es elegir modelo: la herramienta importa más que la marca del modelo que tiene adentro.

Lo que también cambió

Algunos datos más del informe que vale la pena conocer:

• TypeScript sigue primero en cantidad de gente nueva que contribuye cada mes (3,6 millones), seguido de Python (3,2 millones). Rust duplicó su cantidad de contribuidores en un año.
• Brasil ya tiene más de 10 millones de desarrolladores en GitHub, y sumó 3,3 millones solo este año. Es el tercer país después de Estados Unidos e India.
• La seguridad automática también creció. GitHub revisó 5.800 millones de envíos buscando claves y contraseñas filtradas (cuatro veces más que el año anterior), y se aprobaron más de 30 millones de pull requests de Dependabot, el bot que actualiza dependencias con fallas conocidas.

Qué cambia para vos

Si trabajás con agentes, o vas a empezar a hacerlo, el informe deja tres cosas concretas:

1. Tu primer movimiento va a ser explicar qué querés. Si el trabajo empieza dirigiendo a un agente, la calidad del pedido decide la calidad del resultado. Vale la pena aprender a escribir una especificación que no se malinterprete.
2. La revisión es donde se forma el resultado. El agente trae un borrador; lo que llega a producción depende de lo que vos corregís. Esta lista es un buen punto de partida, y esta otra te ayuda a decidir qué delegar y qué no.
3. Prepará el terreno. Un archivo de instrucciones para el agente y cambios chicos que se revisen en minutos son las dos cosas que el informe asocia con los proyectos que más avanzan.

Quién decide qué tiene que hacer el código

En el Octoverse hay una frase que resume bien el momento: “lo que no cambia es quién decide qué tiene que hacer el código”. Los agentes ya empiezan casi la mitad del trabajo en GitHub, y esa cifra va a seguir subiendo. Lo que no se delega es saber qué hay que construir y darse cuenta de cuándo lo que entregó el agente no es lo que se pidió. Con el 40 % de los borradores escritos por un agente, esa parte del trabajo no pierde valor: es la que más gana.