GitHub Octoverse 2026: los agentes inician más del 40 % de las pull requests mientras la actividad se dispara
GitHub publicó su informe Octoverse 2026 el 28 de octubre e informó que los agentes aportaron el primer borrador en más del 40 % de las pull requests de septiembre. Una pull request propone cambios de código para su revisión antes de que se incorporen a un proyecto. El hallazgo sitúa la redacción automatizada dentro de un flujo de trabajo central del software, aunque productividad y calidad siguen siendo cuestiones distintas.
GitHub Octoverse 2026 también informa una actividad récord en toda su plataforma. Esto hace más relevante la distinción entre producir cambios y entregar software útil. Un agente de programación con IA, un software que realiza tareas de desarrollo mediante un modelo de IA, puede generar trabajo que aún requiere un juicio humano considerable.
Para los líderes de ingeniería, la tensión central está entre el crecimiento de la producción de código y la capacidad para evaluarlo. Investigaciones anteriores de METR mostraron por qué esas métricas merecen tratarse por separado. Mientras tanto, el respaldo de GitHub a agentes de Anthropic y OpenAI sitúa a proveedores competidores dentro del mismo entorno de revisión. La cuestión práctica es cuánto trabajo útil supera todo el proceso.
GitHub Octoverse 2026 registra un cambio en cómo comienzan los cambios
Según los hallazgos de Octoverse de GitHub, los desarrolladores realizaron 17.900 millones de pushes e integraron 1.300 millones de pull requests durante el año analizado. Un push envía cambios de código guardados a GitHub. El total de pushes superó la suma de los dos años anteriores.
El período analizado abarca del 1 de octubre de 2025 al 30 de septiembre de 2026. La mayoría de las cifras incluyen proyectos públicos y privados. GitHub recalculó los años anteriores con definiciones comparables, una precisión importante al comparar estas cifras con informes publicados previamente.
La proporción iniciada por agentes aumentó del 17 % en marzo a más del 40 % en septiembre. GitHub define estas solicitudes por un primer borrador generado por agentes que puede detectarse.
La cifra de adopción mide cómo comienzan los cambios propuestos, no cuánto software terminado crea un agente de forma independiente.
Esa distinción cambia el significado del titular. Un desarrollador puede especificar la tarea, rechazar un enfoque inicial, reescribir partes del resultado y tomar la decisión final de aprobación. Calificar el trabajo resultante como totalmente autónomo borraría esas contribuciones.
El denominador importa igual de mucho. Una proporción de pull requests no puede traducirse directamente en una proporción de código, horas de trabajo o funcionalidad de producto. Los cambios propuestos varían en tamaño, dificultad e importancia.
Pensemos en una corrección de documentación junto a un cambio en la autorización de pagos. Ambos pueden generar una pull request. Sus requisitos de revisión y consecuencias difieren considerablemente, incluso cuando la plataforma registra cada uno como una sola propuesta.
Del mismo modo, un aumento en el número de cambios propuestos puede reflejar varios desarrollos. Los equipos podrían intentar más proyectos, dividir el trabajo en partes más pequeñas o generar revisiones adicionales. Estas posibilidades requieren interpretaciones diferentes.
Por eso el informe merece atención sin cargar con todas las conclusiones asociadas al debate sobre la programación con IA. Documenta un cambio sustancial en el comportamiento observable del desarrollo. Establecer el valor económico de ese comportamiento requiere evidencia adicional.
Por tanto, para los lectores que siguen la adopción de agentes de GitHub, el punto de partida útil es una atribución precisa. Se trata de las mediciones de plataforma de GitHub, con las definiciones y límites de detección de la empresa. No son una estimación auditada de forma independiente sobre la contribución de la IA a todo el desarrollo de software.
La noticia sigue siendo importante en esos términos. La elaboración de borradores es un punto de entrada significativo al trabajo de ingeniería. Cuando los agentes participan en esa fase, los sistemas de revisión se convierten en el lugar donde sus propuestas se enfrentan a los requisitos del proyecto y a la responsabilidad humana.
Eso sitúa a los mantenedores, responsables de ingeniería y revisores de seguridad directamente dentro de la historia. Sus decisiones determinan si la actividad adicional se convierte en software útil o en una colección más grande de propuestas sin terminar.
Más borradores presionan la capacidad de revisión
Los equipos de ingeniería se benefician de una elaboración de borradores más rápida cuando pueden evaluar los cambios resultantes sin perder el control sobre la calidad o las prioridades.
Este es un argumento operativo, no la afirmación de que todos los equipos ya tengan una cola de revisión sobrecargada. La presión se deriva del flujo de trabajo: producir una propuesta y asumir la responsabilidad por ella requieren labores distintas.
Un revisor debe establecer qué pretende lograr el cambio. Después necesita determinar si su implementación coincide con esa intención. Las pruebas automatizadas pueden respaldar ese juicio, pero su utilidad depende de lo que realmente verifican.
Una prueba que confirma una salida esperada puede seguir pasando por alto una suposición incorrecta sobre el comportamiento de los clientes. Un cambio puede cumplir la tarea asignada y, aun así, entrar en conflicto con otra parte del producto. Son motivos para examinar la evidencia en torno a una propuesta.
Las consecuencias también se extienden más allá de la corrección en el momento del envío. Alguien debe mantener la implementación, explicar sus decisiones y responder cuando cambien los requisitos. El código adicional crea obligaciones junto al valor inmediato que pueda aportar.
Para los responsables de ingeniería, esto plantea una cuestión de capacidad. Si elaborar borradores se vuelve más fácil, ¿cómo debería un equipo distribuir su atención entre nuevas propuestas, mantenimiento existente y fiabilidad en producción? Aumentar los envíos sin ajustar esas prioridades corre el riesgo de trasladar la restricción aguas abajo.
Los investigadores de DORA de Google Cloud describen una tensión relacionada en su análisis de las compensaciones del desarrollo con IA. Informan que el tiempo ahorrado durante la creación a menudo se traslada a la auditoría y la verificación. Su interpretación considera la IA como un amplificador de las fortalezas y debilidades organizativas existentes.
Esa observación ofrece un marco útil para leer las cifras de la plataforma. Un equipo con requisitos claros y comprobaciones fiables parte de una posición distinta a la de otro con una propiedad poco clara. Dar a ambos equipos una elaboración de borradores más rápida no elimina esas diferencias.
La presión inmediata recae sobre las personas que aprueban los cambios y asumen sus consecuencias. Un mantenedor no puede tratar razonablemente la confianza de un agente como sustituto de la evidencia. Un responsable de ingeniería no puede inferir el valor para el cliente únicamente a partir de un mayor número de envíos.
Los equipos de seguridad se enfrentan a un problema similar de asignación. Una propuesta puede requerir escrutinio porque modifica reglas de acceso, maneja información sensible o introduce un componente externo. Su origen no determina su riesgo.
Los equipos de producto también tienen un papel. Una implementación más fácil hace más tentador abordar solicitudes definidas de forma imprecisa. Los criterios de aceptación claros adquieren más valor cuando generar una implementación plausible requiere menos esfuerzo.
Para los desarrolladores individuales, la implicación es más específica que simplemente aprender a formular prompts. La habilidad valiosa consiste en conectar un cambio solicitado con evidencia de que funciona y tiene lugar en el proyecto.
Esto incluye preservar el razonamiento detrás de las decisiones. Los equipos que intentan crear una base de conocimiento con capacidad de búsqueda enfrentan un desafío relacionado: mantener disponible el contexto técnico cuando el autor original está ausente.
La documentación no puede aprobar un cambio. Puede ayudar a un revisor a comprender las restricciones de las que depende la aprobación. A medida que se acelera la elaboración de borradores, ese contexto compartido merece atención junto con las propias herramientas de generación.
Copilot, Claude y Codex compiten dentro del mismo flujo de trabajo
El contexto competitivo ayuda a explicar por qué la adopción de agentes se está convirtiendo en una cuestión de flujo de trabajo. Los desarrolladores pueden encontrarse con diferentes proveedores sin abandonar el lugar donde sus equipos debaten y aprueban cambios.
El anuncio de GitHub de febrero presentó los agentes de programación asociados, incluidos Claude de Anthropic y Codex de OpenAI, en vista previa pública. Describía la asignación de trabajo desde GitHub y la revisión de pull requests preliminares generadas por esos agentes.
Ese anuncio establece la dirección del producto durante el año analizado. No debe interpretarse como un inventario completo de la disponibilidad actual ni de las condiciones de acceso.
Para GitHub, alojar agentes competidores convierte el flujo de trabajo de revisión en un activo estratégico junto a su propio asistente de programación.
La plataforma puede seguir siendo central incluso cuando un desarrollador prefiera otro proveedor para una asignación concreta. El trabajo aún necesita un destino, un historial, una discusión y un proceso de aprobación.
Para Anthropic y OpenAI, aparecer dentro de ese entorno ofrece otra vía hacia el trabajo de desarrollo. Sus agentes pueden competir por asignaciones en las que los equipos ya gestionan cambios de software.
Esta comparación no establece qué agente produce mejores resultados. Un acuerdo de distribución y un anuncio de producto no pueden responder esa pregunta. Muestran cómo los proveedores llegan a los usuarios, no cuán fiablemente resuelven tareas comparables.
La distinción importa al interpretar la adopción de agentes de GitHub. Más propuestas iniciadas por agentes no identifican automáticamente a un proveedor ganador. La adopción del flujo de trabajo y la competencia dentro de ese flujo son desarrollos separados.
Un ejemplo concreto aparece en el anuncio de febrero: los desarrolladores podían asignar una incidencia a un agente y recibir un borrador para revisión. Una incidencia registra una tarea o problema solicitado. Eso otorga a la delegación un inicio reconocible y un resultado revisable.
La importancia reside en el traspaso. Una solicitud se convierte en un intento de implementación, que regresa a un sistema donde las personas pueden inspeccionar los cambios y solicitar revisiones. El agente participa en una estructura de responsabilidad existente.
Para un equipo que evalúa proveedores, esa estructura debería hacer que la comparación tenga más sentido. La pregunta relevante es si un proveedor completa el trabajo real del equipo con un esfuerzo de revisión aceptable. Una demostración pulida no puede establecer ese resultado.
Imaginemos comparar agentes en una tarea de mantenimiento recurrente. Una evaluación útil consideraría si cada propuesta aborda la solicitud, respeta las convenciones del proyecto y ofrece una verificación creíble. Contar los archivos generados respondería a una pregunta distinta.
Lo mismo se aplica a la integración de un agente en un equipo. El acceso a la herramienta es solo el principio. Los permisos, los límites de las tareas y la responsabilidad de la aprobación siguen requiriendo decisiones explícitas.
También existe un beneficio práctico al preservar un entorno de revisión coherente. Los equipos pueden evaluar un nuevo proveedor sin sustituir simultáneamente todos los procesos circundantes. Eso facilita distinguir las diferencias entre proveedores de los cambios en el flujo de trabajo.
Por tanto, la historia competitiva respalda la tensión central. Los proveedores están haciendo que la elaboración de borradores sea más accesible dentro de entornos de ingeniería establecidos. El valor de ese acceso depende de cuán exitosamente conviertan los equipos propuestas competidoras en cambios aceptados y mantenibles.
Las integraciones más rápidas dejan abiertas cuestiones importantes sobre la calidad
GitHub informa que las solicitudes con participación de agentes de septiembre alcanzaron una tasa de integración en dos semanas del 90 %, frente a aproximadamente el 86 % de las solicitudes sin participación de agentes detectada.
Una integración registra la aceptación en un proyecto; no establece la fiabilidad a largo plazo ni el valor comercial del cambio.
Esa limitación también se aplica a los cambios realizados por personas. La aprobación puede ser razonable según la evidencia disponible, mientras que el comportamiento posterior revela una interacción pasada por alto. La calidad del software se desarrolla con el tiempo.
Una vía más rápida hacia la aceptación puede reflejar una mejora. También puede reflejar diferencias en las tareas enviadas, las prácticas del proyecto o el nivel de escrutinio requerido. Una comparación observacional no puede separar automáticamente esas explicaciones.
La selección de tareas es especialmente importante. Los equipos podrían delegar trabajo que ya saben especificar y verificar. Las asignaciones más ambiguas podrían permanecer en manos de los desarrolladores. Comparar esos grupos sin tener en cuenta sus diferencias corre el riesgo de exagerar el resultado.
También merece consideración la posibilidad inversa. Un agente podría hacer viable un mantenimiento que antes se descuidaba, ampliando el rango de trabajo que un equipo intenta realizar. Una evaluación justa debería considerar la producción adicional útil.
Aquí es donde las interpretaciones simplistas fallan en ambas direcciones. La actividad adicional no es prueba suficiente de que todos los equipos se volvieron más productivos. La ausencia de una estimación universal de productividad no es prueba suficiente de que la actividad carezca de valor.
El experimento de productividad de desarrolladores de METR ilustra por qué importa la medición. Su estudio aleatorizado de principios de 2025 incluyó a 16 desarrolladores experimentados que completaron 246 tareas en proyectos de código abierto conocidos. Permitir el uso de IA incrementó el tiempo de finalización en un 19%.
Esos hallazgos describen una población concreta, un contexto de tareas y una generación de herramientas determinados. No deben tratarse como una medición directa del rendimiento de los agentes a finales de 2026.
La relevancia del estudio aquí es metodológica. Observar que los desarrolladores usan una herramienta no indica cuánto más rápido completan trabajo equivalente. Eso requiere una comparación creíble.
La investigación histórica también debe actualizarse a medida que cambia el comportamiento. Un resultado puede seguir siendo válido para su contexto original y, aun así, aportar menos información sobre un flujo de trabajo más reciente. Tratarlo como atemporal sería otro error de medición.
Las comparaciones de calidad requieren límites igualmente cuidadosos. Un cambio propuesto puede superar las comprobaciones existentes mientras añade complejidad que los futuros mantenedores deberán asumir. Como alternativa, una implementación más amplia puede eliminar una solución temporal incómoda y reducir el esfuerzo futuro.
Por tanto, los revisores necesitan evidencia vinculada a la tarea. Las comprobaciones pertinentes, un razonamiento comprensible y una explicación clara del comportamiento modificado aportan más información que una etiqueta de origen.
Para los compradores empresariales, esto plantea un reto de contratación. Los paneles de adopción son fáciles de resumir, mientras que los incidentes evitados y la reducción de la carga de mantenimiento tardan más en establecerse. Una evaluación convincente debe reconocer esa diferencia.
La conclusión adecuada es específica. Las cifras de aceptación de GitHub aportan información sobre cómo los cambios avanzan por su plataforma. Dejan margen para más investigación sobre retrabajo, fiabilidad, esfuerzo de revisión y entregas útiles.
Esa brecha es una agenda de medición. No exige asumir ni que los agentes son beneficiosos de forma universal ni que sus contribuciones son mero ruido.
Medir la productividad de los agentes se vuelve más difícil a medida que cambia el trabajo
El reto de la medición va más allá de seleccionar el panel correcto. El uso de agentes puede cambiar qué tareas intentan realizar los desarrolladores y cómo distribuyen su atención.
En su actualización de investigación sobre productividad de febrero de 2026, METR afirmó que su experimento posterior proporcionaba una estimación poco fiable de los efectos actuales de la IA sobre la productividad. La selección de participantes, la selección de tareas y el uso simultáneo de agentes complicaron la interpretación.
Los investigadores pensaban que los desarrolladores probablemente se estaban beneficiando más de lo que sugerían sus estimaciones anteriores. También subrayaron que sus datos ofrecían evidencia débil sobre la magnitud de esa mejora.
Una evaluación fiable debe tener en cuenta los cambios en el trabajo mismo, además de los cambios en las herramientas que lo realizan.
Esto importa porque una comparación de tareas fijas responde a una pregunta acotada. Puede estimar cómo afecta la asistencia a una asignación concreta. No puede capturar plenamente qué ocurre cuando la asistencia cambia las asignaciones que las personas eligen.
Supongamos que un desarrollador antes posponía una migración tediosa porque requería demasiado esfuerzo concentrado. Un agente podría hacer viable ese trabajo durante una semana por lo demás ocupada. El beneficio incluye completar algo que habría permanecido sin hacer.
Ahora consideremos el caso opuesto. Una redacción más sencilla podría animar a un equipo a implementar una función antes de establecer que los usuarios la necesitan. La implementación puede tener éxito técnico mientras consume atención que se aprovecharía mejor en otro lugar.
Estos ejemplos son posibilidades analíticas, no resultados comunicados del conjunto de datos Octoverse. Explican por qué una entrega útil necesita una conexión con la intención y los resultados.
El trabajo en paralelo introduce otra complicación. Un desarrollador podría revisar una propuesta mientras un agente trabaja en una tarea distinta. Medir el tiempo de ejecución transcurrido del agente como tiempo de trabajo humano representaría incorrectamente esa situación.
Sin embargo, ignorar la supervisión también distorsionaría el resultado. La preparación de tareas, las interrupciones, los enfoques rechazados y la revisión final deben formar parte de una evaluación del flujo de trabajo. El límite contable afecta a la conclusión.
Para las organizaciones, esto favorece varias formas complementarias de evidencia. Las evaluaciones de tareas comparables pueden examinar el esfuerzo de finalización. Los registros operativos pueden mostrar aceptación y retrabajo. Los resultados de producto pueden establecer si los cambios entregados ayudaron a los usuarios.
Ninguna medida lo captura todo. Esa es una razón para indicar qué representa una medida, en lugar de reducir resultados distintos a una puntuación universal de productividad.
Un equipo podría mejorar su velocidad de entrega mientras tiene dificultades con el mantenimiento. Otro podría reducir el esfuerzo repetitivo sin aumentar la frecuencia de lanzamientos porque las aprobaciones siguen limitadas en otra parte. Ambos merecen descripciones que reflejen su experiencia real.
La misma disciplina se aplica al comparar equipos. Un servicio maduro con estrictos requisitos de fiabilidad difiere de un nuevo proyecto experimental. Sus recuentos de envíos no deberían convertirse en una clasificación de la eficacia de los desarrolladores.
GitHub Octoverse 2026 es útil como evidencia de un entorno de desarrollo en transformación. Sus implicaciones más amplias se aclaran cuando la actividad de la plataforma se considera junto con estudios a nivel de tarea y resultados organizativos.
Para los desarrolladores, la preocupación práctica es si su trabajo resulta más fácil de completar y de mantener. Para los directivos, es si esas ganancias se mantienen en todo el equipo. Ninguna de las dos preguntas desaparece cuando la redacción se vuelve habitual.
Observe el esfuerzo de revisión, la fiabilidad y los resultados de tareas comparables
La siguiente evidencia útil debería conectar la participación de los agentes con lo que sucede después de que aparece una propuesta. Durante los próximos meses, los lectores deberían buscar cambios que aclaren la relación entre la redacción y la entrega.
La evidencia de seguimiento más sólida conectará el trabajo originado por agentes con el esfuerzo de revisión, los resultados en producción y comparaciones creíbles de tareas.
La primera señal es una mejor información sobre el esfuerzo de revisión. Los proveedores de plataformas y los equipos de ingeniería deberían mostrar cuánta atención humana requieren las propuestas aceptadas de agentes. El tiempo de espera por sí solo no puede establecerlo.
Una solicitud puede esperar en una cola sin consumir mucho esfuerzo de los revisores. Otra puede avanzar rápidamente mientras exige una discusión intensa. Distinguir esas situaciones haría que las estadísticas de aceptación fueran más informativas.
La evidencia de una reducción del esfuerzo de revisión en trabajo comparable reforzaría el argumento de que los agentes mejoran todo el flujo de trabajo. Un esfuerzo creciente sugeriría que parte del ahorro en redacción se desplaza hacia la supervisión.
Los lectores también deberían examinar cómo contabilizan los equipos el trabajo rechazado. Un panel centrado solo en las fusiones exitosas puede omitir el esfuerzo dedicado a evaluar propuestas que nunca llegan a aceptarse. Esos intentos también deben formar parte de la evaluación.
La segunda señal es la fiabilidad tras la aceptación. Busque evaluaciones que sigan los cambios más allá de la fusión y examinen si requieren correcciones, reversión o respuesta ante incidentes.
Una reversión elimina o deshace un cambio anterior. Su significado depende del contexto, ya que las decisiones de producto pueden cambiar por motivos no relacionados con la calidad del código. Una información útil necesita suficiente detalle para separar esas explicaciones.
Una fiabilidad estable junto con una entrega más rápida reforzaría el argumento de ganancias netas. Más reparaciones posteriores lo matizarían. La comparación pertinente debería tener en cuenta el riesgo de la tarea y la madurez del proyecto.
Esto es especialmente importante para los compradores que evalúan el despliegue en toda una organización. Un piloto exitoso en trabajo de mantenimiento acotado no establece automáticamente la preparación para sistemas sensibles. La expansión debería generar evidencia sobre el nuevo alcance.
La tercera señal es una investigación actualizada que compare trabajo equivalente con herramientas actuales. Los estudios deberían explicar cómo manejan la selección de tareas, los agentes simultáneos y el esfuerzo humano que rodea la generación.
Una mejora consistente en evaluaciones creíbles reforzaría el argumento de productividad. Los resultados mixtos sugerirían que los beneficios dependen de la asignación, el desarrollador o la organización. Cualquiera de los dos resultados sería más útil que una afirmación universal.
Los investigadores también deberían hacer visibles los límites. Un resultado a nivel de tarea, un resultado de entrega del equipo y un resultado de satisfacción de los desarrolladores pueden ser válidos. Describen dimensiones diferentes de la experiencia.
Para los lectores que evalúan GitHub Octoverse 2026, mantengan visibles las distinciones centrales a medida que lleguen nuevos anuncios. Pregunten qué trabajo inician los agentes, quién lo evalúa y qué ocurre tras la aprobación. Sigan si las organizaciones publican evidencia sobre el esfuerzo de revisión y la fiabilidad junto con la adopción. Al comparar herramientas, busquen resultados de tareas similares a las suyas, con la supervisión incluida en el cálculo. Preserven el contexto de los cambios importantes para que los futuros revisores puedan entender su propósito. El informe hace difícil pasar por alto la participación de los agentes; su próxima decisión debería depender del trabajo que esa participación ayuda a completar. ¿Qué evidencia mostraría que su equipo entrega software más útil con menos esfuerzo total?
