- O mecanismo de jogos de código aberto Godot decidiu proibir código escrito por IA e envios feitos por agentes de IA em sua política de contribuições, após Pull Requests gerados por IA aumentarem a carga de revisão
- Os mantenedores avaliam que revisar PRs gerados por IA torna um trabalho de revisão já cansativo ainda mais desgastante e também enfraquece o efeito de formar novos contribuidores como futuros mantenedores
- A nova política vai rejeitar explicitamente código escrito por IA, Pull Requests enviados por agentes de IA e texto gerado por IA incluído na comunicação entre pessoas
- Os contribuidores poderão usar IA apenas de forma auxiliar para “menial things” e deverão divulgar esse uso; tradução automática baseada em texto original escrito por humanos continuará permitida
- A Godot Foundation pretende adotar uma postura conservadora por enquanto, já que as ferramentas de IA mudam rapidamente, e reavaliar a política conforme o cenário evoluir
Mudança na política de contribuições do Godot
- Após meses de discussão, a Godot Foundation e os mantenedores decidiram revisar as diretrizes para contribuidores para restringir envios relacionados a IA
- As restrições cobrem código escrito por IA, Pull Requests enviados por agentes de IA e texto gerado por IA inserido na comunicação entre pessoas
- O Godot é um mecanismo de jogos de código aberto usado em jogos como Slay the Spire 2 e The Case of the Golden Idol
A carga de manutenção causada por Pull Requests de IA
- Desde fevereiro, os mantenedores vêm discutindo como responder ao aumento de AI slop Pull Requests
- Esse fluxo de PRs se tornou algo “increasingly draining and demoralizing” para os revisores de código do projeto
- A Godot Foundation entende que o problema não é temporário e quer reduzir a carga sobre os mantenedores sem perder o caminho de formar novos contribuidores como futuros mantenedores
Quando a revisão deixa de virar mentoria
- O grande número de PRs aguardando revisão pode, por si só, ser visto como um sinal de maior interesse em usar e contribuir com o Godot
- No entanto, com o aumento das contribuições escritas ou enviadas por IA, os mantenedores estão menos dispostos a dedicar tempo à revisão de PRs
- Se o feedback dado nos PRs não servir para orientar potenciais futuros mantenedores e acabar sendo “absorvido pela máquina”, fica difícil justificar dedicar tempo livre a esse trabalho de revisão
Restrições específicas da nova política
- A política de contribuições do Godot em breve passará a incluir a rejeição explícita de AI-authored code
- Os contribuidores só poderão usar assistência de IA para “menial things” e terão de divulgar esse uso
- A Foundation afirma que “a IA não pode ser responsabilizada, e não podemos confiar que usuários intensivos de IA entendam seu código o suficiente para corrigi-lo”
- Texto gerado por IA também será rejeitado na comunicação entre pessoas
- A Foundation descreve isso como “a basic principle of respect”
- Tradução automática baseada em texto original escrito por humanos continuará permitida
Direção operacional da política
- A Godot Foundation está focada em criar barreiras para contribuições de baixo esforço classificadas como “slop”
- Entre os objetivos da política também estão permitir que os mantenedores continuem fazendo revisão de código e ajudar novos contribuidores a crescer como futuros mantenedores
- Toda contribuição deve vir de um humano que assuma responsabilidade pelo próprio código e consiga corrigi-lo diretamente em caso de falha
- A Foundation afirmou que, como as ferramentas de IA mudam diariamente no momento, manterá uma política conservadora, mas a reavaliará conforme houver mudanças
1 comentários
Opiniões no Hacker News
Esta política é justa. É muito irritante receber uma parede de texto escrita por IA, prolixa, para revisar minuciosamente; parece um ataque de negação de serviço contra a mente humana.
Ainda assim, não acho que vá impedir a programação baseada em IA em si. Pelo lado negativo, quem submete pode acrescentar marcas de estilo para parecer humano, mantendo o conteúdo principal e o tamanho da contribuição, mas deixando apenas o estilo esquisito.
Pelo lado positivo, isso pode levar a commits e comentários enxutos, do tipo “este é o código, este é o motivo da mudança, este é o impacto”. Mesmo que tenham sido criadas por IA, contribuições pequenas assim ficam muito mais fáceis de verificar, e também podem surgir padrões sobre o tamanho adequado de uma contribuição ou sobre quais mudanças precisam de revisão mais rigorosa.
Pessoalmente, se o conteúdo se encaixar no segundo caso, não me importo muito se foi gerado por IA ou não.
Seria um sonho se “commits e comentários enxutos” realmente aparecessem.
Nesse contexto, faz sentido afastar contribuições de IA, ainda mais em um software como o Godot, que já comprovou grande valor.
Se um commit escrito por IA não é fundamentalmente diferente, não há motivo para rejeitá-lo; então não acho que o objetivo seja impedir programação baseada em IA.
É interessante que, de um lado, a valuation das empresas de IA se apoia na premissa de que, em um futuro próximo, todo código e todo produto digital serão escritos por IA, enquanto, do outro, praticamente todos os projetos populares de código aberto querem bloquear contribuições de IA. É difícil conciliar as duas coisas.
Eu também, depois de usar bastante em meus projetos open source, estou passando por uma espécie de ressaca de IA. No momento de uso, parece que se ganha um poder enorme, criando em algumas horas uma funcionalidade que levaria semanas; mas, com o tempo, ao olhar o código, começam a aparecer as fissuras e inconsistências sutis deixadas pela ferramenta, o que é desconcertante.
Agora tento usar menos para desenvolver grandes funcionalidades e mais em lugares onde dá para impor guardrails rígidos, como planejamento, depuração e refatorações de escopo estreito. Mesmo assim, o trabalho acelera, mas algo mais perto de 1,5 a 3 vezes, não 10 vezes.
A concentração mental necessária para programar diminui, mas surge um novo tipo de cansaço: ficar conversando com a máquina e não saber como instruções em linguagem natural serão interpretadas. É como operar, por combinações de botões, uma máquina cuja fiação interna muda o tempo todo; não é satisfatório.
O que a IA tornou possível foram contribuições de pessoas que não têm nenhum envolvimento com o projeto. Agora, o simples fato de alguém ter aberto um PR já não permite concluir que “essa pessoa tem algum interesse no sucesso do projeto”.
Quando bem usada, a IA é um amplificador; mas, do ponto de vista de mantenedores open source, é fácil ficar soterrado por uma grande quantidade de “contribuições” de baixo valor despejadas por pessoas que não se importam com o projeto.
Especialmente por causa da tendência bajuladora da IA, ela continua dizendo “boa ideia!”, embora eu saiba muito bem que a maioria das minhas ideias não é grande coisa.
Quando vejo relatos do tipo programar por vibe no celular enquanto está com os filhos, isso quase soa como compulsão.
Para começo de conversa, no open source, ser rápido nunca teve tanta importância, e havia bons motivos para isso.
A estrutura de dopamina que faz a gente recorrer à IA com facilidade demais ao trabalhar ou começar um novo projeto também é um problema.
Agora estou tentando retreinar meu cérebro para voltar a preferir escrever a maior parte do código à mão, em vez de procurar o Claude primeiro. O tempo dirá se isso é uma fase temporária ou se vamos precisar de algo como reuniões anônimas para usuários de LLM.
Existem listas que reúnem software sem IA. Seria bom ver, em um índice ou gráfico, como elas mudam com o tempo.
https://codeberg.org/brib/slopfree-software-index
https://noai.starlightnet.work/list.html
https://hcker.news/?ai=exclude&include_domains=github.com
Do ponto de vista funcional, não me vem à cabeça uma boa razão para uma política no-AI. Se executa, executa, independentemente de quem ou do que criou.
Mesmo evitando lixo gerado por IA, não dá para evitar o lixo gerado por humanos ou por humanos+IA que passa pelo filtro.
Ainda assim, consigo pensar em muitas razões não funcionais, como procedência, responsabilização, prova de trabalho, incentivo para que as pessoas escrevam código diretamente e acompanhamento empírico de como humanos evoluem uma base de código.
A fala da Foundation acerta em cheio: “se o feedback sobre PRs não é usado para orientar uma pessoa que pode se tornar mantenedora no futuro, mas apenas absorvido por uma máquina, fica muito mais difícil justificar gastar tempo livre revisando PRs”
Se você não entende, basta ver isto
https://github.com/godotengine/godot/pull/115280
https://github.com/godotengine/godot/pull/116410
Em um projeto que já sofria com PRs demais para revisar antes da era da IA, não é justo exigir que os mantenedores continuem lidando também com esse tipo de coisa
Por isso, a grande mudança real na política é a parte que impede novos contribuidores de assumir recursos grandes ou refatorações
Só com as informações deixadas no repositório dava para encontrar o apelido e as contas sociais, e era uma criança que ainda nem tinha chegado ao início da adolescência. Parecia ainda não ter o conhecimento básico para entender o problema ou as estruturas sociais envolvidas
É um caso em que a lei de Brandolini funciona exatamente como descrita
Refutar bobagens exige 10 vezes mais esforço do que produzi-las. Revisão de código é refutação, e verificar a exatidão de uma proposição também é
Gerar uma proposição é fácil, mas, para refutá-la, é preciso provar se é verdadeira ou falsa, ou encontrar uma contradição. A energia de mantenedores open source, que já têm pouco tempo, é desperdiçada sem necessidade; concordo totalmente em poupar essa energia e usá-la de forma produtiva
A IA encontrou por acaso um dos recursos mais caros da indústria: o tempo livre das pessoas que mantêm open source à noite, depois do trabalho principal
A Foundation apontou algo que sempre foi verdade, mas que a IA deixou evidente. Qualquer contribuidor, incluindo IA, pode não ser capaz de manter aquele patch no futuro
O ponto central não é o uso de IA em si, mas que isso é um dos sinais de que o autor não entende o que está enviando. Quebrar convenções de nomes de variáveis, mudar APIs que não deveriam ser tocadas ou cometer erros de linguagem imaturos também podem ser motivos para rejeitar um patch, mesmo que ele funcione
Uma saída seria marcar que o PR foi rejeitado por causa da IA e pedir ao autor que destaque uma parte da qual tenha orgulho em especial e explique, com suas próprias palavras, não com uma parede de texto de IA, o que ela faz e por que é boa. O autor precisa mostrar gosto e opiniões que a IA não tem
Aqui, muita gente parece estar reagindo ao título em vez de ler a política de fato. A política diz que um motivo importante é usar revisões de PR para treinar novos contribuidores e descobrir potenciais futuros mantenedores
Independentemente da qualidade das contribuições de IA, essa parte parece difícil de contestar
A menos que você acredite que a IA vai tornar desnecessário todo o conceito de contribuição ou manutenção open source; nesse caso, parece fazer mais sentido fazer um fork da engine e deixar agentes trabalharem nela do que enviar PRs para a Godot
Será que os contribuidores de IA realmente acham que estão ajudando? Será que não percebem que estão prejudicando o projeto com esse “trabalho”?
Não entendo por que gastar dinheiro em algo que ninguém quer e que será rejeitado. Não têm hobbies? Ou são instâncias OpenClaw que o criador esqueceu e que agora vagam livremente por conta própria?
Essas pessoas estão colhendo contribuições para grandes projetos FOSS como enchimento de currículo. O mesmo acontece com relatos de vulnerabilidades
Geradores em massa podem acreditar sinceramente que estão ajudando, ou podem saber que sua “contribuição” é um prejuízo líquido para o projeto. Mas, quando há um incentivo econômico direto e a situação da pessoa é instável, externalidades ficam em segundo plano
O Claude fez em 1 hora, e eu refinei 3 ou 4 vezes, reduzindo a parede de texto e adequando ao estilo do projeto original. A alternativa seria simplesmente deixar de lado ou abrir apenas uma issue e passar o ônus para o mantenedor
Então acho que ajudei. Também encontrei esse caso limítrofe mexendo no meu homelab como hobby
Ambos os PRs eram pequenos e não diferiam de PRs humanos. Continuo acreditando que eram adições valiosas, e evidentemente alguns mantenedores também viram assim
Não querem programar nem melhorar o produto; querem “linhas de código”, “commits” e um perfil verde bonito no GitHub, sem precisar entender os detalhes