Fundamentos da política anti-IA para contribuições no projeto Zig
(simonwillison.net)- Um dos principais projetos de linguagem open source mantém uma regra rígida que proíbe o uso de LLM em issues, Pull Requests, comentários no bug tracker e traduções
- O uso de inglês é apenas uma recomendação, não uma exigência, e os contribuidores podem escrever em sua língua nativa, enquanto outras pessoas podem interpretar o conteúdo com a ferramenta de tradução de sua escolha
- O Bun adicionou parallel semantic analysis e multiple codegen units ao seu próprio fork de Zig no backend LLVM e alcançou uma melhoria de desempenho de 4x na compilação do Bun, mas atualmente não há plano de upstream por causa da proibição de contribuições escritas por LLM
- A forma de revisão do Zig prioriza ajudar novos contribuidores a chegar a um trabalho que possa ser mergeado, em vez de rejeitar PRs incompletos, e valoriza mais o crescimento do contribuidor do que contribuições individuais
- PRs escritos em sua maior parte por LLM fazem com que o tempo de revisão deixe de ser usado para aumentar o número de novos contribuidores confiáveis, e também criam a opção de o maintainer simplesmente rodar um LLM por conta própria para resolver o mesmo problema
Conflito entre a política e o fork do Bun
- Zig declara em seu Code of Conduct a proibição do uso de LLM em issues, Pull Requests, comentários no bug tracker e traduções
- O uso de inglês é uma recomendação, e os contribuidores podem escrever em sua língua nativa
- Outras pessoas podem interpretar o conteúdo com a ferramenta de tradução de sua escolha
- Um projeto de destaque escrito em Zig é o runtime JavaScript Bun, e o Bun foi adquirido pela Anthropic em dezembro de 2025
- O Bun mantém seu próprio fork de Zig e adicionou “parallel semantic analysis and multiple codegen units” ao backend LLVM, alcançando melhoria de desempenho de 4x na compilação do Bun
- O código relacionado está disponível no link de comparação oven-sh/zig
- Atualmente, o Bun não tem plano de upstream porque o Zig proíbe de forma rígida contribuições escritas por LLM
- Segundo um core contributor do Zig, esse patch seria difícil de aceitar mesmo separando a questão do LLM
- parallel semantic analysis é uma funcionalidade planejada há muito tempo, mas afeta a própria linguagem Zig
Contributor Poker e revisão centrada no contribuidor
- O conceito de contributor poker em Contributor Poker and Zig's AI Ban é a metáfora central para entender a política rígida de proibição do Zig
- Projetos open source bem-sucedidos chegam a um estágio em que recebem mais PRs do que conseguem processar
- Para maximizar o ROI, o Zig escolhe ajudar novos contribuidores a tornar seu trabalho mergeável, em vez de simplesmente rejeitar PRs incompletos
- Essa abordagem é vista não só como “a coisa certa a fazer”, mas também como “a coisa inteligente a fazer”
- O Zig valoriza mais o contribuidor do que a contribuição individual
- O objetivo principal da revisão e aceitação de PRs não é inserir código novo, mas ajudar pessoas que, com o tempo, podem se tornar contribuidores confiáveis e produtivos
- Cada contribuidor se torna um alvo de investimento da core team do Zig
- O suporte de LLM quebra essa estrutura
- Mesmo que o LLM ajude a produzir um PR perfeito, o tempo que a equipe do Zig gasta revisando isso não contribui para aumentar o número de novos contribuidores confiantes e confiáveis
- “contributor poker” vem da metáfora de jogar olhando para as pessoas, não para as cartas
- A ideia é mais próxima de apostar no contribuidor do que no conteúdo do primeiro PR
- Se um PR for escrito em sua maior parte por LLM, surge a opção de o maintainer do projeto, em vez de revisar e discutir esse PR, simplesmente rodar um LLM para resolver o mesmo problema
1 comentários
Comentários no Hacker News
Segundo https://kristoff.it/blog/contributor-poker-and-ai/, contribuições baseadas em LLM foram, em geral, negativas
PRs oportunistas sem valor aumentaram o ruído com código alucinado, não compilavam ou não passavam no CI, e houve até caso de um contribuidor de primeira viagem enviar um PR de 10 mil linhas
Também havia PRs que pareciam aceitáveis e declaravam não usar LLM, mas nas discussões seguintes logo ficava claro que o autor havia consultado um LLM às escondidas e continuava repetindo respostas cheias de erros
hooks não têm uma forma elegante de forçar instalação no clone, mas GHA Workflows ou recursos equivalentes em outros forges podem existir
Para um projeto com certo tamanho e popularidade, isso deveria ser requisito básico
Uma parte considerável do problema de “IA não consegue contribuir” parece poder ser reduzida com verificações automáticas melhores e mais salvaguardas
Tirando o fato de que a IA tornou possível esse novo tipo de spam, a essência não é IA
Mesmo sem IA, se as pessoas contratassem exércitos baratos de desenvolvedores offshore para produzir em massa PRs oportunistas de qualidade mediana, o efeito seria o mesmo
Dá para produzir código bom com IA, mas, como qualquer outra ferramenta, ela precisa ser usada com cuidado
Isso não é uma contribuição feita com critério por alguém que conhece o projeto e o objetivo e usa bem a ferramenta; é spam
O barulho em torno da política de IA parece ter surgido porque desenvolvedores do Bun disseram que não conseguiam upstreamar um PR de performance por causa dessa política
Mas o motivo real aparentemente é que o próprio código do PR não está em bom estado e introduz complexidade pouco saudável https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Segundo a explicação citada, análise semântica paralela já faz parte há muito tempo dos planos explícitos do compilador Zig e influenciou fortemente o design do self-hosted Zig compiler, mas implementá-la corretamente exige mudanças não só na implementação do compilador, como também na própria linguagem Zig
Ela entra em conflito com o roadmap do próprio Zig para obter um resultado melhor e atrapalha a direção de seguir melhorando a linguagem como um todo
A política proíbe explicitamente todo código de LLM, então essa política é obviamente o “motivo real”
O pessoal do Zig parece estar seguindo o caminho do ZeroMQ https://zguide.zeromq.org/docs/chapter6
A direção é “impor a propriedade coletiva do projeto para aumentar os incentivos econômicos dos contribuidores e reduzir o risco de hijack por agentes hostis”
Uma comunidade de contribuidores saudável é mais importante do que simples performance de código, número de recursos ou quantidade de linhas de código
Hoje a “comunidade” do zeromq é rarefeita; ainda existem algumas pessoas ótimas ativas, mas processos e canais de comunicação em escala humana não são bem definidos nem suficientemente operados
Como o libzmq e a maioria dos bindings são estáveis, até dá para tolerar ou justificar um pouco essa falta de atividade e interação humanas, mas a excelente visão de Hintjens foi o que trouxe o zeromq até aqui, e depois da perda dele o projeto passa uma sensação de estar à deriva
Ironicamente para uma visão centrada na comunidade, parece que para conquistar e manter uma comunidade você precisa de um líder carismático e ativo, e isso diz mais sobre a natureza humana do que sobre desenvolvimento de software
Voltando ao caso do Zig, existe a premissa de que o Zig não sofre por falta de PRs, então pode se dar ao luxo de fazer triagem prévia de contribuições sem LLM
Para eles, é uma boa escolha, e a ideia de “contributor poker” faz sentido
Mas se a entrada de gente nova diminuir, o jogo muda, e nesse momento talvez o pessoal do Zig precise ampliar a rede se ainda quiser novos contribuidores
Só que, se esse momento chegar, talvez abrir contribuições assistidas por LLM já seja tarde demais para recuperar isso
O que me intriga em contribuições OSS geradas por IA é o seguinte
Se a IA realmente aumenta tanto a produtividade de desenvolvedores, por que um maintainer iria querer colocar um contribuidor desconhecido entre ele e o LLM?
O maintainer pode simplesmente perguntar direto ao Claude Code
Como disse um colega, “não precisamos de um intermediário para conversar com modelos de IA, e codificação não é o gargalo”
Ele usa IA para criar uma versão inicial ruim, ajusta prompts, faz correções manuais, pede para corrigir outras partes, descobre recursos relacionados e os adiciona, roda benchmark para remover um pequeno recurso ou escolher entre duas implementações parecidas
Também faz mais correções manuais aqui e ali, roda testes automáticos ampliados para achar bugs estranhos em configurações exóticas e os corrige com IA e trabalho manual
Depois de 20 horas, a versão final tem só 50 linhas, e cada linha pode ter sido reescrita 5 vezes
O maintainer só precisa revisar a versão final por cerca de 1 hora
Isso é totalmente diferente de pedir para a IA escrever um patch por 5 minutos e mandar para o maintainer mil linhas que nem compilam sem sequer ler
“Isso é tão fácil que até eu poderia ter feito”
Sim, mas você não fez
Mas não é do tipo em que você pode simplesmente jogar instruções de alto nível como faria com uma pessoa
Suspeito que quem afirma que IA funciona só com instruções de alto nível em geral esteja fazendo projetos “sem reflexão”, em que o desenvolvedor não precisa pensar muito nos detalhes
Espero também que não queira dizer que a única vantagem dos LLMs é gerar código que dá preguiça de digitar à mão
A explicação de que “o Zig valoriza contribuidores mais do que contribuições. O principal objetivo de revisar e aceitar PRs não é inserir código novo, e sim ajudar pessoas a crescerem ao longo do tempo até virarem contribuidores confiáveis e produtivos. Assistência de LLM destrói completamente isso. Mesmo se o LLM ajudasse a submeter um PR perfeito, ainda assim” é o melhor fundamento que já vi até agora
Apoio totalmente a decisão do Zig e valorizo muito essa visão de longo prazo tanto para a comunidade quanto para o projeto em si
Sinceramente, não acho que LLM combine tão bem assim com trabalho mais colaborativo
Vamos ver como isso muda no futuro, mas quando aceito PRs gerados por IA, muitas vezes acabo tendo de refazer eu mesmo e, ironicamente, refaço usando LLM, o que vai me deixando cada vez mais conflitado
Ainda assim, pelo menos pelos próximos 5 anos, acho que a política do Zig é uma boa ideia
Acho que essa é a formulação menos hostil que eles poderiam usar, e respeito como uma decisão sobre o próprio projeto
Ainda assim, continuo achando que isso prende o projeto de forma desnecessária
LLM é uma ferramenta, e pode ajudar a pensar, pesquisar e programar
Dá para exagerar no uso, mas, onde for útil, deveria ser aceito
Não aceitar o PR do Bun por outros motivos é totalmente ok, mas simplesmente proibir todos os PRs escritos com LLM é uma restrição desnecessária
Basta focar na qualidade do trabalho
Se o maintainer usar LLM diretamente para fazer a mesma coisa, provavelmente consegue com design melhor e abordagem mais cuidadosa
O maintainer precisa gastar tempo desenvolvendo, não só fazendo revisão de PR de baixo esforço
A enxurrada de código de LLM está desequilibrando a balança contra maintainers, e entendo perfeitamente por que eles querem simplesmente proibir
Minha impressão geral depois de um tempo rodando LLMs e coding agents é que isso é uma ferramenta elétrica ou um guindaste, não uma ferramenta de tomada de decisão
Pessoas dentro de uma organização que têm ótima compreensão conceitual e grande profundidade de engenharia ficam explosivamente mais produtivas
Já quem tem pouca compreensão, ou é iniciante, ou junior, está produzindo código infernal achando que, se funciona, então acabou
LLMs criam uma lacuna intelectual dentro das organizações, e quanto mais se usa, mais essa lacuna aumenta
Mais tarde, talvez a organização nem consiga confiar no que ela mesma produziu por causa do código gerado
IA em geral amplifica o skillset, tanto no lado bom quanto no lado ruim
Um caso de uso recente e excelente foi redigir o concept de um authentication daemon
Conversando com o Codex, selecionando sugestões, cruzando com buscas normais na web e definindo o rascunho final antes de discutir com colegas
Esse tipo de planejamento conversacional com busca web integrada é extremamente útil, e também vejo benefício puro em revisar código já escrito com IA
Mas a principal caveat da IA continua sendo que você precisa ser mais inteligente do que a ferramenta
Se o Codex sugere usar tech stack X, você precisa investigar por que isso é realmente bom, entender completamente e comparar com outras soluções
Muita gente pula essa etapa, e daí surgem inúmeros problemas, o que é fatal
Depois que a conversa acaba, você precisa ter ficado mais inteligente do que a IA e ser capaz de entender completamente e criticar o que ela disse
Depois que a arquitetura está definida, o LLM executa a implementação muito bem
Em geral dá para fazer a IA produzir código excelente e bem testado, e às vezes muito melhor do que eu faria sozinho no mesmo tempo
Mas continuar acompanhando todo o conhecimento sobre tudo o que a IA produziu é um desafio
A lógica de que “se o PR é majoritariamente escrito por LLM, será que o maintainer não faria melhor em gastar o tempo de revisão e discussão ligando o próprio LLM e resolvendo o mesmo problema?” também se aplica ao próprio open source
Por que usar o projeto dos outros se um robô pode escrever direto para você?
Ainda mais se esse projeto open source foi vibe coded
IA e tecnologia em geral tornam a personalização barata e fácil
Antes, todo mundo tinha de usar produtos de massa que servissem mais ou menos para todos, mas agora existe a esperança de obter algo excelente só para mim
Além disso, várias pessoas em vários lugares podem refazer projetos open source com LLM, o que também mexe com a economia do trabalho
Um LLM consegue cuspir isso em poucos minutos
O que eu mais quero é histórico de uso
Quero usar software que outras pessoas já usaram antes de mim, e espero que elas já tenham encontrado bugs e arestas e aparado isso
A ideia era que ninguém mais compraria coisas, porque daria para baixar modelos, imprimir em casa e customizar infinitamente
A razão de termos civilização é justamente poder empurrar a maior parte dos problemas da vida para outra pessoa resolver e, nós mesmos, focar em fazer bem uma única coisa
Se você é dentista ou toca uma muffler shop, seu tempo por dia é limitado, e provavelmente você prefere pagar um SaaS vendor a aprender vibecoding e supervisionar um subordinado estranho e trabalhoso
Existem exceções, mas são exceções
Se o vendor fizer um produto razoável e competente, eu pago com prazer
Com open source é a mesma coisa
Mesmo que um LLM consiga fazer de forma confiável um sistema operacional novo do zero, será que eu realmente quero isso?
Eu não quero manter um OS, não quero gerenciar alguém que mantém um OS, e nem acredito que eu mesmo tenha uma visão consistente sobre OS para começo de conversa
Depois de certo nível de complexidade, é difícil esperar que um robô leia minha mente bem o suficiente para entregar um resultado de alta qualidade “excelente só para mim”
O projeto Zig claramente está muito além desse alcance
Tem gente que não consegue arcar com o custo e, mesmo para quem tem acesso, há problemas como indisponibilidade do Claude ou degradação geral de desempenho com o tempo, às vezes frequente ou constante
Alguns meses atrás, quando comecei a usar Claude, consegui avançar facilmente em vários projetos em uma semana, mas hoje em dia parece que quase só vejo spinner e a qualidade do código despencou, então mal consigo fazer qualquer coisa
Tenho alguns repositórios com algo em torno de 100 stars, nada demais, mas até o ano passado eu ainda recebia PRs ocasionais; neste ano, até agora, quase nenhum
Minha hipótese é que LLMs preferem se apoiar em projetos mainstream
Como muitos desenvolvedores agora dependem muito de LLMs, surge um viés para ignorar a maior parte do que eu ofereço
Também há muito mais reinvenção da roda com LLM, porque o custo de criar algo novo ficou barato
Então ficou mais fácil simplesmente gerar o que você precisa do que usar alguma coisa obscura do GitHub, como as minhas
Vejo o mesmo fenômeno nas minhas escolhas de dependências
A menos que exista um motivo muito forte, há uma tendência de simplesmente aceitar o que o LLM sugere
Concordo em certo grau, mas não totalmente
É verdade que cultivar contribuidores é a prioridade correta
Mas vejo a IA como uma tecnologia assistiva
Algo parecido com screen reader ou magnifying glass, embora obviamente haja muitas diferenças
Dá para pensar nela como um exoesqueleto robótico
Vai ser usada para coisas ruins e burras, mas também servirá para ajudar pessoas a fazer coisas boas que antes não conseguiam ou a se tornarem mais capazes
Para algumas pessoas, a IA torna possível programar de um jeito que antes elas não conseguiam; para muitas, torna-se um meio de aprender programação observando o que a IA faz; para outras, faz com que programem muito mais rápido ou melhor
Em alguns casos, certas habilidades podem atrofiar, enquanto outras se desenvolvem
Com exoesqueletos haveria problema parecido se um produto razoável chegasse ao mercado, mas, no geral, ainda seria uma ferramenta capacitadora
Não vejo por que cultivar contribuidores que usam tecnologia assistiva seria pior do que cultivar os que não usam
Claro, pode ser mais difícil
LLMs não são tão inteligentes quanto os vendors de LLM alegaram
Se fossem, já seriam totalmente autônomos e nem estaríamos tendo essa conversa
Pessoas que submetem cegamente código gerado por LLM ou deixam de revelar que usaram isso realmente precisam parar
O problema que resta é que isso continua sendo uma ferramenta
Se você pedir a um desenvolvedor qualquer “faça o Zig ficar rápido em um PR one-shot”, o resultado também não vai ser bom
No passado, projetos OSS faziam uma auto-seleção porque você precisava ser capaz de produzir código funcional e, a esse ponto, geralmente já tinha aprendido por alguns anos e normalmente fazia a coisa certa, com algum raciocínio próprio sobre funcionalidade ou necessidade
Hoje, mesmo que o LLM seja perfeito e tenha bom reasoning, no fim ele executa as instruções de quem o está usando
Essa auto-seleção deixou de existir
Para os desenvolvedores do Zig, provavelmente também é difícil julgar o que é código feito por LLM e o que é código feito por gente
Pode ser que já exista código gerado por LLM ali dentro, mas pelo menos esse submissor humano ainda precisa saber lidar razoavelmente bem com o código
No fim, fico curioso se vamos para algo como “só humanos com um trusted badge of honor podem dar commit” ou para um estágio em que “o LLM tenha reasoning suficiente para dizer ‘não, cai fora. Esse recurso/plano/ideia é lixo e eu não vou construir isso’”
Se não houver uma forma eficaz de fazê-los realmente sentir as consequências quando fizerem isso, não sei o que vai detê-los