Octoverse 2026: agentes iniciam mais de 40% dos PRs
O relatório Octoverse 2026 do GitHub, anunciado em 28 de outubro de 2026 no GitHub Universe, diz que agentes de IA iniciaram mais de 40% dos pull requests da plataforma em setembro de 2026, contra 17% em março. Os pull requests integrados triplicaram em menos de um ano, para 220 milhões por mês. Para empresas de software, os números mostram para onde o trabalho está indo: os agentes redigem mais código, e a revisão, as verificações de segurança e as regras de integração passam a carregar mais da carga.
O que o GitHub mediu neste ano
O relatório mede quanto mais trabalho passa agora pelo GitHub. O vice-presidente executivo do GitHub, Jay Parikh, anunciou o relatório no GitHub Universe, e seus números de destaque mostram a rapidez com que a atividade cresceu. Os pull requests integrados triplicaram em menos de um ano, para 220 milhões por mês. Os commits mais que triplicaram, para 7,38 bilhões por mês, com a maior parte do aumento no segundo semestre do ano. A taxa de novos repositórios dobrou, para 30,3 milhões por mês.
O período do relatório foi de 1º de outubro de 2025 a 30 de setembro de 2026. Os números de agentes se baseiam na detecção que o próprio GitHub faz da atividade de agentes na plataforma. Em alguns recortes, o GitHub usou a própria IA: um LLM classificou perfis de usuários por país, e um modelo de embeddings multilíngue ajustado sob medida organizou repositórios públicos em setores da indústria.
Quanto do trabalho os agentes de IA já iniciam
Mais de 40% dos pull requests no GitHub começaram com um rascunho gerado por agente de IA em setembro de 2026, contra 17% em março. Só em setembro, os agentes iniciaram 110 milhões de pull requests, cerca de seis vezes o volume de março.
O trabalho dos agentes também tende a ser mais amplo. O GitHub constatou que 87% dos pull requests iniciados por agentes modificaram vários arquivos, contra 79% dos pull requests sem participação detectada de agentes. A parcela dos pull requests com participação de agentes integrados em até duas semanas subiu de 83% em fevereiro para 90% em setembro, enquanto a taxa dos demais ficou em torno de 86%. O GitHub observa que esses números descrevem o tempo até a integração, não a qualidade do código.
Como os desenvolvedores usam os recursos de agente do Copilot
Entre os usuários ativos mensais do GitHub Copilot, 55% usavam recursos de agente, contra 35% um ano antes. O uso do agente em nuvem do Copilot, que permite ao desenvolvedor atribuir uma tarefa para o agente concluir sozinho, cresceu 230% em relação ao ano anterior, e o uso do chat de agente cresceu 85%.
O GitHub também lançou o Copilot Projects em prévia pública. Ele permite que os desenvolvedores coordenem agentes em vários repositórios, tragam contexto de arquivos de design, conversas do Slack e anotações de reuniões e revisem o resultado.
Como o GitHub trata a revisão do código escrito por agentes
Mais código significa mais a revisar, e os números do GitHub mostram as ferramentas de revisão e de segurança crescendo rápido. O uso da revisão de código assistida por IA e do GitHub Advanced Security cresceu mais de 90% cada um em relação ao ano anterior. Os desenvolvedores integraram mais de 30 milhões de pull requests do Dependabot, cerca do dobro do volume de 2025.
Mais de 264.000 desenvolvedores haviam usado pull requests empilhados até setembro. O recurso divide uma mudança grande em pull requests menores, que podem ser revisados um a um, e ficou disponível para todos em 6 de outubro. O GitHub diz que os repositórios que o usaram tiveram aumento de 9% no código integrado durante a prévia, embora não afirme que o recurso sozinho causou isso.
"Para uma equipe que revisa o trabalho uns dos outros, foi uma melhoria significativa na forma como colaboramos." — David Mostoller, engenheiro de software da Comcast, sobre pull requests empilhados
Em 28 de outubro, o GitHub lançou em prévia pública a revisão de código Max do Copilot, que roda agentes de revisão independentes em modelos de diferentes provedores e combina seus achados. A correção automática por agentes ficou disponível para todos em 15 de outubro: o Copilot propõe correções para até 25 alertas de varredura de código em um só pull request e roda o CodeQL de novo para conferi-las.
O que a mudança significa para líderes de engenharia
Para uma empresa que entrega software, o gargalo está saindo de escrever código para conferi-lo. Quando os agentes iniciam mais de 40% dos pull requests, o limite da produção passa a ser quantas mudanças as pessoas conseguem revisar com confiança.
Os próprios controles do GitHub mostram como ele espera que as empresas lidem com isso. As aprovações do Copilot, agora disponíveis para todos, podem contar para as aprovações exigidas, mas vêm desativadas por padrão, os administradores podem restringir quais caminhos de arquivo o Copilot pode aprovar, e uma aprovação é descartada se chegarem novos commits depois dela. As equipes que adotam agentes precisariam de regras de revisão desse tipo antes de o volume chegar.
Perguntas e respostas
Que parcela dos pull requests do GitHub os agentes de IA iniciam?
Mais de 40% em setembro de 2026, contra 17% em março, segundo o relatório Octoverse 2026 do GitHub. Os agentes iniciaram 110 milhões de pull requests em setembro.
Quantos pull requests são integrados no GitHub por mês?
Cerca de 220 milhões por mês em 2026, o triplo do nível de menos de um ano antes, diz o GitHub.
O que é a revisão de código Max do Copilot?
Uma opção de revisão em prévia pública desde 28 de outubro, que roda agentes de revisão independentes em modelos de diferentes provedores e reúne seus achados em uma só revisão. O GitHub diz que ela leva mais tempo e usa mais créditos de IA que as opções Lite e Balanced.
A visão da MOZGII
Como nós construiríamos
Quando os agentes iniciam uma grande parte das mudanças, o recurso escasso em uma equipe de software deixa de ser a digitação. É a leitura cuidadosa. Se fôssemos montar uma equipe para isso, começaríamos pelo caminho da revisão, não pelo agente. Cada pull request iniciado por um agente levaria uma nota curta sobre o que mudou e por quê, quais testes rodou e quais arquivos tocou, para que o revisor comece com contexto, e não com um diff cru.
Manteríamos as mudanças pequenas, porque uma mudança pequena é mais fácil de conferir que uma grande, e encaminharíamos por regra a um revisor sênior tudo o que toca a lógica de login ou bibliotecas compartilhadas. As aprovações por IA ficariam desligadas nesses caminhos. Um segundo modelo que revisa o primeiro pode pegar erros, mas uma pessoa ainda seria dona da decisão de integrar.
Ele falharia onde o volume supera a atenção. Se os revisores enfrentam muito mais pull requests por dia, passam a aprovar por hábito, e os números de velocidade ficam bons enquanto a qualidade cai. Por isso não acompanharíamos o tempo até a integração. A única métrica que acompanharíamos é a parcela de mudanças de agentes integradas que são revertidas ou corrigidas em poucas semanas. Em seguida, construiríamos um relatório semanal que mostra aos revisores quais tipos de mudança de agente exigiram mais retrabalho, para que a equipe saiba onde olhar com mais rigor.
Fontes
De onde vêm os fatos desta matéria.