Os numeros que preocupam
O GitHub recebeu 1 bilhao de novas submissoes de codigo em 2025. Para 2026, a projecao e de 14 bilhoes, segundo Kyle Daigle, COO da plataforma. O salto de 14 vezes em um unico ano nao e explicado por um aumento proporcional de desenvolvedores. E codigo gerado por inteligencia artificial.
O problema nao esta no volume em si, mas na qualidade. Modelos de IA tornaram trivial gerar pull requests, correcoes de bugs e ate funcionalidades inteiras com um clique. Porem, esse codigo frequentemente nao segue as diretrizes do projeto, e abandonado logo apos a submissao e exige revisao extensiva de voluntarios que ja trabalhavam no limite.
Mantenedores no limite
O GitHub reconheceu oficialmente a gravidade da situacao. Em uma discussao na comunidade fixada no topo do repositorio e com mais de 270 respostas, a plataforma descreveu o cenario: mantenedores estao dedicando tempo substancial revisando contribuicoes que nao atendem padroes minimos de qualidade, que desrespeitam guidelines do projeto e que sao abandonadas pouco apos o envio.
A Zig Software Foundation, que mantem a linguagem de programacao Zig, tomou uma medida drastica: proibiu completamente submissoes assistidas por IA, citando a baixa qualidade sistematica. Miranda Heath, pesquisadora da Universidade de Edimburgo que estuda burnout em comunidades open source, explica por que a revisao e tao dificil:
“A primeira vista, codigo escrito por IA pode parecer funcional e livre de problemas. Mas preocupacoes mais profundas frequentemente se escondem. Identificar possiveis falhas exige escrutinio extensivo.”
Miranda Heath, Universidade de Edimburgo
O cenario e paradoxal: a IA facilita a geracao de contribuicoes, mas o trabalho humano necessario para avaliar cada uma delas aumentou, nao diminuiu. O resultado e que voluntarios que mantinham projetos criticos nas horas vagas estao desistindo por exaustao.
O que o GitHub esta fazendo
A plataforma esta desenvolvendo solucoes em duas frentes. No curto prazo:
- Permissoes configuraveis para pull requests: repositorios poderao restringir contribuicoes apenas a colaboradores ou desativar PRs para casos especificos como repositorios-espelho. Essa era uma solicitacao da comunidade desde 2016.
- Exclusao de PRs pela interface: mantenedores poderao remover spam e PRs de baixa qualidade diretamente, sem precisar de automacoes customizadas.
Essas medidas ajudam, mas sao paliativas. A raiz do problema e estrutural: o modelo de contribuicao aberta que sustenta o open source ha decadas nao foi projetado para um mundo onde qualquer pessoa com acesso a um LLM pode gerar dezenas de PRs por hora.
Curiosamente, o proprio GitHub contribui para a dinamica com o Copilot. A partir de 1 de junho de 2026, workflows de code review do Copilot passaram a consumir minutos do GitHub Actions, adicionando uma nova dimensao de custo para mantenedores que ja lutam para dar conta da carga.
Por que isso importa para quem opera infraestrutura
O cartoon viral do xkcd 2347 resume a situacao: toda infraestrutura digital moderna depende de projetos mantidos por voluntarios. Quando esses voluntarios desistem por exaustao, as consequencias aparecem em producao na forma de dependencias sem manutencao, vulnerabilidades sem patch e bibliotecas abandonadas.
Para times de DevOps e SRE, algumas acoes praticas se impoe: auditar a cadeia de dependencias em busca de projetos com mantenedor unico, contribuir financeiramente via GitHub Sponsors ou Open Collective para projetos criticos e, principalmente, estabelecer politicas internas para revisao de PRs gerados por IA antes de envia-los a projetos upstream. A sustentabilidade do open source nao e problema de outra pessoa. E problema de todo mundo que roda software em producao.