Mantenedores de código aberto estão revidando contra o “AI slop”, um programa de recompensas por vez

Em 2026, "AI slop" se tornou a palavra do ano do dicionário Macquarie — conteúdo de baixa qualidade gerado por IA generativa, "frequentemente contendo erros, e não solicitado pelo usuário". Os mantenedores de código aberto não precisaram de um dicionário para entender o que isso significava. Eles estavam triando milhares desses por um ano, e o coletivo Jazzband — um conhecido núcleo de projetos de empacotamento Python — fechou completamente em 2026, com seu mantenedor principal citando o volume insustentável de pull requests e issues de spam gerados por IA como o fator decisivo.

A tese aqui não é que as ferramentas de IA são ruins para código — muitas contribuições legítimas agora começam com assistência de IA. É que a economia de revisão do código aberto foi construída sobre uma suposição específica: que uma pull request enviada representa tempo e julgamento humano real, o que justifica um mantenedor gastar tempo real avaliando-a. A IA generativa quebrou exatamente essa suposição no ponto de estrangulamento exato — capacidade de revisão humana — que o código aberto nunca conseguiu escalar.

Como o AI slop realmente se parece em uma fila de PRs

Não é obviamente malicioso. Jeffrey Paul, vice-presidente de soluções de código aberto na Fueled, descreve como envios de pessoas que não entendem completamente o problema, a solução proposta, ou ambos — um contribuidor executou uma ferramenta de IA, obteve algo que parecia plausível, e enviou sem verificar se realmente funcionava. O código frequentemente compila. Às vezes passa nos testes. Frequentemente não faz o que afirma, e descobrir isso requer a mesma profundidade de revisão que avaliar uma contribuição legítima — o esforço não é reduzido, apenas o custo de envio é reduzido.

Essa assimetria é toda a crise em uma frase: gerar uma PR de aparência plausível agora custa quase nada ao contribuidor, enquanto verificá-la ainda custa ao mantenedor o mesmo de sempre.

O programa de recompensas do curl: um estudo de caso em números

Nenhum projeto foi mais publicamente transparente sobre o dano do que o curl. O fundador Daniel Stenberg rastreou a qualidade dos envios ao longo de 2025 enquanto relatórios de segurança gerados por IA inundavam o programa de recompensas do projeto. Em meados de 2025, apenas cerca de 5% dos envios eram vulnerabilidades reais — o resto eram relatórios gerados por IA que pareciam estruturalmente corretos, mas descreviam falhas que não existiam. Stenberg fechou completamente o programa de recompensas no início de 2026. Não resolveu completamente o problema — envios de slop ainda chegam por email e GitHub — mas removeu o incentivo financeiro direto que fazia do curl um alvo específico. Apenas sete mantenedores revisam os relatórios de segurança do curl, um número que não escalou mesmo com a explosão do volume de envios.

O RubyGems supostamente está considerando a mesma medida, segundo Marty Haught, diretor de código aberto, após meses sem um único relatório de vulnerabilidade válido em meio a volume contínuo de envios.

O custo humano, não apenas o custo do processo

Rémi Verschelde, mantenedor do motor de jogos Godot, descreveu a triagem de AI slop como exaustiva e desmoralizante — uma distinção que vale a pena considerar. Revisar uma contribuição humana de má-fé ou baixo esforço é frustrante, mas compreensível; você pode raciocinar sobre a intenção do contribuidor. Revisar AI slop significa investir repetidamente esforço cognitivo real avaliando algo sem intenção alguma por trás, e depois descartá-lo. Esse é um tipo específico e cumulativo de esgotamento, distinto da sobrecarga habitual do mantenedor, e é um fator documentado na decisão do Jazzband de fechar em vez de continuar.

Como a resposta real se parece

O WordPress lançou diretrizes formais de contribuição com IA exigindo divulgação do uso de ferramentas de IA e definindo padrões inaceitáveis, como grandes despejos de código não revisado, explicitamente para reduzir a carga sobre mantenedores que avaliam envios às cegas. O GitHub, sob pressão como a plataforma que hospeda a maior parte desse tráfego, anunciou um conjunto de recursos voltados para mantenedores destinados a dar aos proprietários de projetos mais controle sobre volume e qualidade de envios.

O padrão em todas as respostas — regras de divulgação do WordPress, fechamento de recompensas do curl, ferramentas do GitHub — é o mesmo: transferir o custo do envio de baixo esforço de volta para quem o envia, porque por três anos esse custo recaiu inteiramente sobre o mantenedor.

O que realmente fazer a respeito

Se você mantém um projeto, os manuais do curl e WordPress agora são replicáveis: exija divulgação do uso de IA em seu modelo de contribuição, e trate um primeiro envio de slop como uma oportunidade educacional, mas um segundo como motivo para aviso ou bloqueio — a maioria dos contribuidores legítimos se ajusta uma vez avisados, e os que não se ajustam nunca seriam contribuidores sustentáveis de qualquer forma. Se você é um contribuidor usando ferramentas de IA, a disciplina que o mantém fora da lista de slop de um mantenedor é simples e nada glamorosa: execute e verifique o código você mesmo antes de enviar, e seja capaz de explicar com suas próprias palavras por que a correção está certa. Esse é exatamente o teste que o AI slop falha, e é a única coisa que as ferramentas generativas ainda não podem fazer por você.