Agentes já rascunham 40% dos PRs do GitHub. Quem revisa?

Mais de 40% dos pull requests no GitHub agora começam como o primeiro rascunho de um agente de IA. O dado é do relatório Octoverse 2026 do próprio GitHub, publicado em 28 de outubro e apresentado por Satya Nadella no GitHub Universe no mesmo dia. Em março, eram 17%. Só em setembro, agentes começaram cerca de 110 milhões de pull requests, umas seis vezes o volume de março.

O relatório também mostra esses pull requests sendo aceitos em até duas semanas com mais frequência que os outros. O que ele não mostra é nada sobre revisão: quanto tempo levou, quem fez, o que pegou. O número que cresceu seis vezes é o de código entrando no repositório. Nada no relatório indica que a capacidade humana de conferir esse código cresceu no mesmo ritmo.

O que o GitHub relatou

Os números principais, nas palavras do GitHub:

• "Em setembro de 2026, mais de 40% dos pull requests no GitHub começaram com o primeiro rascunho de um agente, contra 17% em março." São "110 milhões só em setembro, cerca de 6x o volume de março".
• O GitHub só conta os agentes que consegue detectar, e chama esse sinal de "um piso, já que nem todo uso de agente pode ser detectado".
• "Em fevereiro, 83% dos pull requests com envolvimento de agente foram aceitos em até duas semanas, um pouco atrás dos cerca de 86% dos pull requests sem envolvimento de agente detectado. Em setembro, os pull requests de agente chegaram a 90%, enquanto o grupo de comparação ficou em cerca de 86%."
• Pull requests começados por agente "mudam vários arquivos com mais frequência: cerca de 87%, contra 79%" dos demais.
• O total de pull requests aceitos "mais que triplicou, pra 1,3 bilhão", cerca de 3,5 milhões por dia. O GitHub hoje atende mais de 225 milhões de desenvolvedores.

O relatório é otimista, e nos termos dele está certo: os desenvolvedores estão entregando mais. A cobertura independente, como a da Econotimes, repetiu os mesmos números.

O mecanismo: "aceito" não é "conferido"

Veja o que o relatório mede e o que ele não mede.

Ele mede volume: pushes, commits, pull requests abertos, pull requests aceitos em até duas semanas. Todos subiram, alguns com força.

Ele não traz verificação: tempo de revisão, número de revisores, comentários por pull request, pull requests aceitos sem revisão, testes adicionados, reversões, incidentes causados por uma mudança. Lemos o relatório inteiro. Nada disso aparece.

Essa lacuna importa porque taxa de aceite é fácil de interpretar errado. "90% dos pull requests de agente aceitos em até duas semanas" soa como sinal de qualidade. Na verdade é sinal de aceitação. Diz que os rascunhos de agente são aceitos, e aceitos logo. Não diz se estavam certos, nem com que atenção alguém olhou antes de aceitar.

Três detalhes do relatório mostram onde a pressão cai:

1. Mudanças maiores. Pull requests de agente mexem em vários arquivos com mais frequência (87% contra 79%). Uma mudança espalhada por muitos arquivos é mais difícil de revisar bem.
2. A revisão é o novo gargalo, e o GitHub sabe disso. O relatório diz que "a revisão é onde os desenvolvedores moldam o que volta" e que o uso de revisão de código assistida por IA cresceu mais de 90% em um ano. Também destaca os stacked pull requests, um recurso pra dividir o trabalho em mudanças menores, "mais fáceis de revisar".
3. Os desenvolvedores escolhem código que conseguem conferir. TypeScript foi a linguagem principal de 35% dos repositórios novos com sinal de agente, contra 24% dos sem. A leitura do próprio GitHub: quem trabalha com agentes "tende a ir pra linguagens em que a saída do agente é mais fácil de conferir".

O GitHub fecha o relatório com a frase que mais importa: "alguém ainda tem que decidir se funciona, se faz sentido estar ali e se está bom". O relatório conta o código. Não conta essa decisão.

Por que isso é problema de gestão, não de ferramenta

Quando o volume de rascunhos de código cresce seis vezes em seis meses, a pressão sobre o time vai pra tudo que não cresceu junto. Hoje isso é revisão, teste e o julgamento de quem sabe como o sistema deveria se comportar.

Se o seu time adotou agentes de programação este ano, o número de pull requests provavelmente subiu. A pergunta é se a capacidade de revisão subiu junto, ou se as revisões encolheram em silêncio. Já escrevemos sobre entregar código que você não entende por completo e sobre um agente que reescreveu o teste que pegaria o problema. As duas coisas ficam mais prováveis quando os revisores estão em menor número.

O que fazer agora

• Meça a revisão, não só os aceites. Acompanhe o tempo até a primeira revisão, o número de revisores por mudança, os comentários por pull request e quantas mudanças entram sem revisão de verdade. Se esses números caem enquanto o volume de pull requests sobe, esse é o sinal.
• Mantenha as mudanças de agente pequenas. Peça um assunto por pull request. Divida mudanças grandes antes da revisão, não depois. Mudança pequena é o jeito mais barato de a revisão ser real.
• Faça dos testes o primeiro revisor. Exija que pull requests de agente venham com testes que falham sem a mudança e passam com ela. Revise os testes com o mesmo cuidado do código.
• Proteja os arquivos que importam. Exija um revisor humano nomeado pra mudanças em autenticação, pagamento, permissões, CI, alertas e testes. O agente pode propor essas mudanças. Não deve ser o único a aprovar.
• Use a revisão por IA como filtro, não como veredito. A revisão assistida por IA pega problemas óbvios antes de uma pessoa olhar. Não deve ser a última checagem de um código que outra IA escreveu.
• Reserve tempo de revisão explicitamente. Se os agentes dobraram a vazão do time, planeje o tempo de revisão que vem junto, em vez de supor que ele cabe no meio do resto.

Construir a disciplina de revisão que permite ao time confiar em código escrito por IA é parte grande do nosso trabalho de produção. As ferramentas pra escrever código melhoraram muito este ano. As ferramentas pra saber se ele está certo ainda são, na maior parte, pessoas.

Pontos principais

• O Octoverse 2026 do GitHub diz que mais de 40% dos pull requests começaram com o rascunho de um agente em setembro, contra 17% em março, cerca de 110 milhões só naquele mês.
• Pull requests de agente foram aceitos em até duas semanas em 90% dos casos em setembro, contra cerca de 86% dos demais, e mudaram vários arquivos com mais frequência.
• O relatório mede volume, não verificação: não traz dados de tempo de revisão, aceites sem revisão, bugs ou reversões.
• Times devem medir a revisão tão de perto quanto a produção, manter mudanças de agente pequenas, usar testes como primeiro filtro e exigir revisão humana em áreas sensíveis.

Perguntas frequentes

Agentes de IA escrevem 40% do código no GitHub? Não exatamente. O GitHub diz que mais de 40% dos pull requests em setembro começaram com o rascunho de um agente. Isso conta pull requests, não linhas de código, e só os agentes que o GitHub consegue detectar, o que ele chama de piso.

Taxa de aceite de 90% quer dizer que o código de agente é bom? Não. Quer dizer que 90% dos pull requests de agente foram aceitos em até duas semanas. Mede aceitação e rapidez, não correção. O relatório não traz dados de bugs nem de reversões.

Revisão de código por IA resolve? Ajuda como primeira passada. O GitHub diz que o uso de revisão assistida por IA cresceu mais de 90% em um ano. Mas usar uma IA pra aprovar o código de outra IA, sem uma decisão humana, deixa a mesma lacuna no lugar.

Qual a primeira coisa que um time deve mudar? Começar a medir a revisão: tempo até a primeira revisão, revisores por mudança e quantas mudanças entram sem revisão de verdade. Não dá pra resolver um gargalo que você não mede.