Como bloquear spam de bots de IA em um repositório no GitHub com a flag `--author` do Git

• O repositório Archestra passou a receber mais contribuições baseadas em IA, e comentários e PRs sem sentido se acumularam, enterrando discussões reais e aumentando a carga de manutenção
• A issue com recompensa de $900 era um espaço de discussão para contribuidores reais, mas os comentários de bots de IA fizeram o total chegar a 253 comentários, com até atitudes agressivas
• A issue de suporte ao provider x.ai recebeu 27 PRs fechados e não mesclados, e a maioria dos contribuidores nem sequer testou o que enviou
• A restrição de prior contributor do GitHub não consegue distinguir novos desenvolvedores reais de bots de IA, então eles adicionaram usuários aprovados como author de commits na main usando o Git --author
• O onboarding cria um commit de whitelist via GitHub Action depois de regras éticas para uso de IA e um CAPTCHA, priorizando qualidade acima de métricas de atividade infladas

---

Como o spam de bots de IA tomou conta de repositórios open source

• O repositório Archestra, ao contrário do crescimento das métricas de contribuições com IA mostrado pelo GitHub, viu na prática uma queda na qualidade das contribuições e um aumento da carga de manutenção
• A issue com recompensa de $900 era um espaço onde contribuidores reais propunham planos, faziam perguntas e tentavam executar o trabalho, mas a chegada de bots de IA fez o total explodir para 253 comentários
• Contas de IA deixavam planos de implementação sem sentido e até adotavam uma postura agressiva com os mantenedores, poluindo a discussão
• Integrantes da equipe que acompanhavam o repositório recebiam notificações a cada comentário de IA, e conversas de contribuidores reais como @ethanwater, @developerfred e @Geetk172 acabavam soterradas
• A issue de suporte ao provider x.ai recebeu 27 pull requests fechados e não mesclados, e na maioria dos casos o contribuidor nem havia testado o código
• Um integrante da equipe precisava gastar meio dia por semana limpando PRs não testados e issues alucinatórias; sem essa limpeza, o repositório rapidamente se tornava um espaço hostil para contribuidores reais

O método de whitelist para contornar as limitações do GitHub

• Limites da resposta inicial

  • A Archestra primeiro criou um pequeno bot chamado London-Cat para calcular a reputação dos contribuidores
  • O London-Cat calculava a reputação com base em PRs mesclados e alguns outros sinais, e ajudava a identificar contribuidores, como neste exemplo
  • Esse método falhou em bloquear o spam em si
  • O AI sheriff criado na etapa seguinte acabou fechando até alguns PRs reais, como neste exemplo

• Bloqueio de atividade sem onboarding

  • Comentários e sugestões inúteis gerados por IA continuaram, contribuidores reais foram embora, e isso levou a uma reavaliação tanto do modelo de atrair contribuições com recompensas quanto do uso de tarefas de teste para candidatos em processos de contratação
  • A Archestra reforçou a resposta para criar um repositório confortável e seguro para contribuidores reais, usuários responsáveis de IA, iniciantes e engenheiros experientes
  • Usuários que não passam pelo onboarding agora estão impedidos de criar issues, abrir PRs e escrever comentários
  • Para uma startup com investimento de VC, métricas de atividade no GitHub são sensíveis, mas a Archestra considera a qualidade mais importante do que números inflados por AI slop

• Limitações das configurações do GitHub

  • O GitHub não oferece uma forma simples de gerenciar diretamente uma whitelist de quem pode comentar ou abrir PRs em repositórios open source
  • A configuração “Limit to prior contributors” bloqueia comentários em issues e PRs de usuários que nunca fizeram commit antes na main
  • Essa configuração não consegue distinguir bots de IA de desenvolvedores reais recém-chegados por causa de recompensas, tratando ambos apenas como usuários sem contribuição anterior

• Whitelist usando a flag --author

  • O GitHub considera como prior contributor a conta do GitHub vinculada como author de um commit na branch main
  • Um commit do Git tem dois campos de identidade: author e committer, e eles podem ser diferentes
  • Com a flag --author do Git, é possível criar um commit atribuído a outra pessoa; se o e-mail corresponder à conta do GitHub, o GitHub associa o commit ao perfil e concede status de contribuidor
  • Toda conta do GitHub tem um e-mail noreply no formato <id>+<username>@users.noreply.github.com
  • Depois de consultar o ID do usuário via API, basta definir o author do commit nesse formato de e-mail

  gh api users/their-username --jq '.id'  
  git commit \  
  --author="their-username <[e-mail]>" \  
  -m "chore: add their-username to external contributors"  
  

  • Ao fazer push desse commit para a main, o usuário externo aparece como author, a conta da Archestra como committer, e o GitHub passa a tratar esse usuário como prior contributor, liberando imediatamente a permissão de comentar

• Fluxo real de onboarding

  • https://archestra.ai/contributor-onboard - no site, o onboarding inclui regras éticas para uso de IA e CAPTCHA
  • GitHub Action - ao enviar o formulário, o sistema consulta o ID do usuário no GitHub, adiciona o handle ao arquivo EXTERNAL_CONTRIBUTORS.md e faz push para a main de um commit cujo author é a conta desse usuário
  • Usuário - entra na whitelist e ganha acesso ao repositório
  • Enquanto o GitHub divulga crescimento em larga escala de métricas, inclusive de atividades geradas por IA, equipes de projetos open source precisam limpar manualmente o AI slop do repositório e até criar soluções alternativas para manter um nível saudável de participação real
  • O AI slop não só empurra para o ruído quem quer contribuir de verdade, desmotivando essas pessoas, como também traz riscos de segurança, como no repo do LiteLLM, onde um atacante tentou induzir uma conversa com bots de IA

[GN⁺]

Comentários do Hacker News

• Colaboradores do repositório passam a ter privilégios mais altos, como contornar a exigência de aprovação para executar PRs de forks, então esse método tem uma implicação de segurança que foi ignorada
  A documentação do GitHub também alerta que, em configurações que “exigem aprovação apenas do primeiro colaborador”, um usuário que já teve um commit ou PR mesclado no repositório deixa de precisar de aprovação, e um usuário malicioso pode satisfazer essa condição fazendo com que uma mudança inofensiva, como corrigir um simples typo, seja aceita

  • Concordo. Pessoas de fora da organização não são confiáveis, então exigir aprovação de todos os colaboradores externos deveria ser o padrão
  • Isso não é uma implicação de segurança
    Se o repositório fica vulnerável só porque um PR totalmente inofensivo de alguém foi mesclado, então ele já estava em um estado vulnerável antes

• O problema é que o GitHub deixou isso ser possível. Se tivesse colocado requisitos bem básicos para comentar e abrir PR, isso não teria chegado a esse ponto
  E também queria que desse para apagar PRs, assim como dá para apagar issues

  • No momento estão trabalhando em uma função para administradores arquivarem PRs
    O objetivo é dar aos mantenedores mais controle sobre como gerenciam contribuições no repositório. PRs arquivados ficariam visíveis só para admins, e os mantenedores continuariam podendo acessar o histórico de contribuições para auditoria ou exigências organizacionais e de compliance. Gostaria de saber se algo assim ajudaria
  • Essa avaliação está certa. Do mesmo jeito que não faz sentido dizer que cada pessoa deve “se virar” para não receber spam por email, isso não é algo que a comunidade open source ou cada projeto individual deveria ter que resolver por conta própria
  • Não entendo qual seria a vantagem de apagar um PR em vez de apenas fechá-lo. Deixá-lo fechado sinaliza que certos PRs não são aceitos; ao apagá-lo, você perde esse benefício

• Spam de PR é um grande problema em repositórios com bug bounty. Talvez o GitHub devesse bloquear temporariamente a criação de PR para contas cujos PRs são rejeitados em mais de 95% das vezes

  • Seria bom se o GitHub tivesse, por exemplo, um sistema para emitir um token de 1 PR
    Se alguém participa de uma discussão de forma significativa e mostra boas ideias para resolver uma issue ou implementar uma funcionalidade, recebe primeiro um token de PR; se a qualidade do PR for boa, ganha mais alguns; e, por fim, vira um colaborador que pode abrir PRs livremente. Também seria bom ter algo parecido para issues, embora eu não saiba exatamente como isso funcionaria quando a issue é o ponto de partida da contribuição via PR. Mas GitHub/MS quer vender assinaturas do Copilot e tokens, e PRs gerados por LLM fazem parte desse modelo de negócio, então não parece provável que isso aconteça de fato
  • O GitHub não tem incentivo para bloquear IA. É como pedir para uma empresa de publicidade colocar um bloqueador de anúncios no próprio navegador
  • O problema é que bots podem simplesmente continuar criando novas contas no GitHub e spammando à vontade. Mesmo assim, como defesa inicial simples, talvez seja aceitável
  • GitHub e Microsoft estão contribuindo ativamente para esse problema; por que iriam admitir a própria culpa?

• Fico pensando se um sistema de pontuação baseado em Elo funcionaria para reduzir esse tipo de problema
  Algo que avalie quem teve PRs mesclados com sucesso em determinado projeto, quem abriu issues reconhecidas como reais, quem teve a qualidade das respostas validada pela reação de outros usuários etc., multiplicando isso ainda pela importância do projeto em que a atividade aconteceu. Isso serviria não para separar humanos de IA, mas contribuições eficazes e úteis de contribuições de baixo esforço e spam. Issues e PRs poderiam ser ordenados ou filtrados por pontuação Elo. Aqui, Elo é apenas uma metáfora para uma pontuação contextual; não quero dizer que o sistema Elo real deva ser copiado 1:1
  Pontos negativos poderiam vir de denúncias de outros usuários sobre conteúdo spam ou issues não reconhecidas, e parece que seria preciso uma zona intermediária com pontuação neutra ou levemente positiva para casos em que a boa-fé é clara, mas não houve PR mesclado, ou a issue foi aberta no repositório errado, ou era um bom PR que dependia de implementação prévia

  • Elo é surpreendentemente fácil de manipular
    Por exemplo, havia um jogador de xadrez muito bom na prisão, e ele criou um grupo de jogadores que ganharam um Elo alto ao derrotá-lo; depois usou esse grupo para inflar ainda mais a própria pontuação. É só repetir esse processo
    Qualquer sistema manipulável vai acabar sendo manipulado por IA. No método do post original, basta uma IA obter status de colaborador para começar a elevar outras IAs ao mesmo status, e então o mesmo problema recomeça. Nem precisa haver propósito. Trolls fazem trolling, e trolls com bots de IA podem despejar energia infinita nisso. Quanto mais você tenta impedir, mais divertido fica para eles. Queria ter uma resposta para isso, mas não tenho
  • Só acrescentando para quem tem curiosidade sobre Elo: Elo não é sigla, é sobrenome. Mais detalhes aqui: https://en.wikipedia.org/wiki/Elo_rating_system
  • É Elo, não ELO. Elo não é sigla
    https://en.wikipedia.org/wiki/Elo_rating_system
  • Estou construindo algo parecido e coletando dados neste momento
    Frontier users: 527,865
    Light indexed: 527,865
    Ready to queue: 9,083
    Fast scores ready: 0
    Activity events 24h: 30,266
    Fast scores completed 24h: 19,123
    Deep jobs completed 24h: 3,043
    Fast-score ETA: n/a
    Deep-hydrate ETA: 69h
    Stale running jobs: 0
    GitHub backpressure jobs: 19,113
    High automation signals: 4,608
    Medium automation signals: 1,327
    Completed jobs: 74,714
    O maior obstáculo é o rate limit do GitHub. Nesse ritmo, vai levar mais dois meses para chegar a 98% de cobertura, mas depois disso a manutenção deve ser bem simples
  • Isso parece um pouco com o Vouch do Mitchell Hashimoto: https://github.com/mitchellh/vouch

• Isso é o resultado de todo mundo ficar dizendo o quanto a IA escreve código bem
  Quem vende IA começou isso e, de forma curiosa, muitos desenvolvedores independentes embarcaram nessa, inclusive alguns bastante respeitados no setor. O Facebook agora também está jogando gasolina no fogo ao demitir gente e dizer que é porque a IA é tão boa assim. Agora tem gente convencida de que seu amigo IA produz código incrível e está mandando esse código para projetos que já ficaram completamente inadministráveis

  • Talvez os cowboy coders tenham conseguido suas vaqueiras virtuais programadoras e saído vendendo isso para todo mundo
    Respeitado ou não, um desenvolvedor solo nem sempre tem o conjunto mínimo de habilidades necessárias para não agir como cowboy. Pode ser falta de experiência ou falta de talento inato. Ainda assim, não compro totalmente essa narrativa, porque desde o “início” houve um empurrão forte de cima para baixo

• O fato de ser um domínio .ai é irônico

  • Não acho exatamente irônico. Não se está dizendo que IA é ruim; está se dizendo que ela pode ser usada de forma ruim
  • Queria que esse site consertasse um pouco o código de rolagem. É irritante a ponto de eu não conseguir ler o texto
  • É como uma empresa baseada em lixo de IA dizendo: “Eu não sabia que a IA ia encher meu projeto de lixo!”
  • Não é só o domínio. Isso é uma stack agentic. Em outras palavras, dá para usar o produto dessa empresa para criar exatamente o tipo de PR do qual eles estão reclamando aqui

• Então a solução para tudo é mais catgirls no fim das contas? [1] Prova de trabalho originalmente buscava combater spam por email, e spam de PR é só o caso mais recente dessa longa tradição
  1- https://anubis.techaro.lol

  • Prova de trabalho não funcionou para email, e também não vai funcionar aqui
    O esforço para produzir uma prova de trabalho válida, em qualquer implementação, sempre pesa mais contra usuários legítimos. Quem tem incentivo para enviar spam sempre consegue fazer isso de forma mais rápida e eficiente
    Seu notebook é lento demais para enviar um PR? É só alugar hash power de alguém, e pronto: você criou um sistema em que se paga a donos de botnet para subir uma correção de typo em um repositório do GitHub. Existe uma razão para o HashCash nunca ter pegado no mundo real. Parece bonitinho, mas só funciona se você assumir um vácuo em que todo mundo age honestamente, de tão absurdos que são os incentivos
  • Anubis na verdade não é um gato. Na mitologia egípcia original, Anubis é o deus da morte e tem cabeça de canídeo. Catgirls e dog girls de anime podem parecer parecidas à primeira vista
  • Vejo o Anubis como algo para bloquear crawlers, não agentes que criam PRs. Aqui prova de trabalho não funciona; o agente simplesmente vai fazer o cálculo

• A redação da documentação de onboarding tem aquele jeitão típico de IA. Até na citação aparecem travessões longos e frases no estilo “não é A, é B”
  Entendo que pode ser combater fogo com fogo ou, como já foi dito, simplesmente falta de tempo. Ainda assim, no geral parece uma resposta pela metade e insuficiente

  • O texto inteiro parece claramente gerado por LLM
    Dá para ver que uma pessoa organizou as ideias ali, mas pedir para um LLM “transformar isso em um post de blog” sempre me pareceu conteúdo de baixo esforço e fora do padrão do HN. Ainda assim, ao menos gerou uma discussão sobre como a abordagem central, “restringir a colaboradores”, pode ser uma má ideia do ponto de vista de segurança
  • Usar IA no próprio projeto e ficar sobrecarregado por contribuições com IA enviadas por outras pessoas ou bots são problemas diferentes

• Quando li a parte “se o email corresponder à conta do GitHub, o GitHub vincula o commit ao perfil e concede status de colaborador”, fiquei preocupado se isso não quebraria caso o endereço de email do colaborador mudasse
  Já contribuí para vários projetos ao longo dos anos usando endereços de email que nem existem mais
  Mas, na prática, parece que eles não usam o endereço gravado no commit original do git do autor, e sim um endereço gerado pelo GitHub com o ID e o nome de usuário do GitHub na parte única. Aí isso continuaria funcionando mesmo se o autor mudasse de email. Talvez quebre se o colaborador perder acesso à conta e precisar criar outra, mas isso provavelmente é menos comum

• A resposta para “devemos parar de dar testes divertidos para candidatos?” é sim

  • Parece que essa empresa paga pelo custo de completar a tarefa, então talvez não seja tão ruim assim
  • Desenvolvedores: entrevistas de whiteboard não medem coisas relevantes para o trabalho real, então parem com isso
    Também desenvolvedores: não façam as pessoas resolverem problemas reais
  • Para começo de conversa, nem sei para quem isso seria divertido