GitHub Octoverse 2026: commits triplicam, mas o relatório não mede se o código funciona

No GitHub Universe 2026, a empresa anunciou que PRs merged e commits mais que triplicaram no ano. Para quem revisa e mantém esse código, o número interessante é o que o relatório não conta.

Nota da redação: o parágrafo acima contém uma imprecisão: segundo a fonte (Simon Willison), apenas os commits mais que triplicaram; os PRs merged triplicaram (sem o "mais que"). A versão correta está no parágrafo seguinte e na tabela do artigo; mantivemos o registro aqui para transparência sobre o erro original.

No GitHub Universe 2026, a empresa anunciou que PRs merged triplicaram e commits mais que triplicaram no ano. Para quem revisa e mantém esse código, o número interessante é o que o relatório não conta.

O que o GitHub anunciou no Universe 2026

No dia 28 de outubro de 2026, durante o GitHub Universe, o EVP Jay Parikh apresentou o relatório Octoverse 2026. O desenvolvedor Simon Willison, presente ao evento, publicou os números em seu blog no mesmo dia.

Vale separar as coisas: isso é telemetria do próprio GitHub sobre a própria plataforma, divulgada pelo fabricante no palco do seu evento. Não é um estudo independente nem uma auditoria de terceiro. Os números são reais e públicos, mas a leitura deles precisa levar isso em conta.

Os três números que o GitHub destacou

O relatório aponta um salto concentrado em 2026, mais forte na segunda metade do ano:

PR merged é o portão final: código que passou por revisão (humana, automatizada ou as duas) e entrou na branch principal. Commit é volume bruto de mudança. Repositório novo é criação de projeto. Os três subindo juntos, e rápido, é a assinatura esperada de agentes de codificação trabalhando em loop: editar, rodar teste, corrigir, abrir PR, repetir, em ciclos muito mais curtos do que um humano sozinho sustentaria.

O que a metodologia deixa de fora

O Octoverse 2026 trouxe também recortes por indústria e por país, e aqui a metodologia importa tanto quanto o número final.

Para classificar repositórios por setor (usando a taxonomia NAICS), o GitHub usou um modelo de embedding multilíngue ajustado (fine-tuned) que lê nome, descrição, tópicos e README de uma amostra aleatória por ano. É uma classificação automática baseada em texto curto e, muitas vezes, incompleto: repositório sem README decente tende a cair em categoria genérica ou errada.

Para contar repositórios de interoperabilidade ou engenharia reversa, o critério foi lexical: o relatório busca termos como "interoperability", "reverse engineering", "clean room implementation", "drop-in replacement" e "protocol re-implementation" no nome, descrição, tópicos ou README. Isso captura quem descreveu o projeto com essas palavras, mas não pega quem fez a mesma coisa sem usar esse vocabulário. É contagem de menção, não de intenção.

Para o ranking de países por push em repositório público, o GitHub tentou corrigir o viés de VPN usando um LLM para extrair o código ISO 3166-1 alpha-2 a partir do texto livre do perfil do usuário. Funciona melhor que IP bruto, mas ainda depende de o perfil ter alguma informação de localização escrita, e ainda confia no que a pessoa colocou lá.

O número que falta: quanto desse volume sobrevive

O relatório não informa taxa de revert, densidade de bug introduzido ou tempo médio de revisão humana por PR. PR merged não é sinônimo de código correto, é sinônimo de código que passou pelo processo de aprovação daquele repositório, seja ele rigoroso ou frouxo.

Com agentes produzindo em ciclos automatizados, essa lacuna pesa mais do que antes. Um time pode estar fechando três vezes mais PRs sem ter capacidade real de revisar três vezes mais linhas de diferença, o que empurra a revisão para outro agente, para aprovação automática por CI verde, ou simplesmente para menos olhos por PR. Isso é leitura minha a partir do que o relatório não diz, não um dado do Octoverse.

Quem decide ferramenta de agente no time ganha mais informação olhando revert rate e tempo de hotfix depois do merge do que olhando o volume bruto de commits.

Como comparar o próprio time com a curva nacional

Dá para puxar o próprio histórico de PRs merged por mês via API do GitHub e comparar a inclinação da curva com a do relatório, em vez de confiar só no número agregado do setor.

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

gh api graphql -f query='
  query($org: String!, $cursor: String) {
    organization(login: $org) {
      repositories(first: 50, after: $cursor) {
        nodes {
          name
          pullRequests(states: MERGED, first: 1) {
            totalCount
          }
        }
        pageInfo { hasNextPage endCursor }
      }
    }
  }' -f org="sua-org"

Para olhar a evolução mês a mês de um repositório específico, gh pr list --state merged --json mergedAt --limit 1000 | jq length dá o total recente; filtrando por mergedAt com jq dá para montar a mesma curva que o GitHub mostrou no palco, só que com os dados da própria organização.

O custo que o relatório não coloca na conta

Mais PR merged e mais commit por mês significa mais execução de CI, não só mais trabalho de agente. Cada push dispara pipeline, cada PR dispara checks, e isso consome minutos de Actions (ou do runner equivalente) e tempo de fila, independente do custo por token do modelo que gerou o código.

Vale medir minutos de CI consumidos por PR merged antes e depois de introduzir agente no fluxo de codificação. Se o volume triplicou mas o minuto de CI por PR também subiu (porque o código do agente precisa de mais iteração para passar), o ganho líquido é menor do que o gráfico do Octoverse sugere à primeira vista.

O salto de volume é real e mensurável pelo próprio GitHub. O que ele significa para a qualidade do software que está entrando em produção é uma pergunta que cada time só responde olhando os próprios números de revert, hotfix e tempo de revisão, não o relatório de palco.

Fonte: Simon Willison