Proibição da IA Zig: Confiança do Revisor Acima da Produtividade do LLM

Um pull request nunca é apenas um pull request. É uma pequena fatura enviada aos mantenedores, pagável em atenção, contexto e aquelas horinhas amaldiçoadas depois do jantar, quando o open source realmente acontece. O Zig carimbou uma categoria de fatura com um “não” vermelho e brilhante: contribuições assistidas por grandes modelos de linguagem estão fora. Isso torna o projeto Zig um estudo de caso útil para quem constrói IA e ML, porque o argumento não é realmente sobre se assistentes de código conseguem produzir código. É claro que conseguem. Estagiários também conseguem, assim como arqueologia no Stack Overflow e uma pessoa engenheira sênior privada de sono movida a café de aeroporto. A pergunta é quem paga para verificar o resultado.

A proibição é mais ampla do que código, segundo Simon Willison e

a Business Insider Simon Willison descreve o Zig como tendo uma das políticas anti-LLM mais rígidas entre grandes projetos open source, e cita diretamente a linguagem do projeto: “Sem LLMs para issues.” Ele também cita: “Sem LLMs para pull requests.” A mesma linguagem da política, conforme citada por Willison, cobre comentários no rastreador de bugs, incluindo tradução, ao mesmo tempo em que incentiva contribuidores a postar em seu idioma nativo e deixar que outras pessoas usem ferramentas de tradução se necessário.

A Business Insider relata que o Zig proíbe contribuidores de usar IA para programar, depurar ou fazer brainstorming, e sua manchete cita o presidente do Zig, Andrew Kelley, chamando contribuições de código feitas com IA de “invariavelmente lixo.” A frase apimentada ganha os cliques, porque é claro que ganha, mas o mecanismo importa mais do que o tempero. O Zig está tratando a proveniência como parte da revisabilidade: se mantenedores não confiam em como um artefato foi produzido, podem optar por não gastar o escasso tempo de revisão desembaraçando-o.

A Let’s Data Science acrescenta que a regra cobre código, edições, traduções, brainstorming, descoberta de bugs e até mencionar o uso de LLMs nos espaços do projeto. A AI Weekly também diz que a proibição cobre artefatos tocados por LLMs, incluindo issues, comentários e pull requests. Em outras palavras, o Zig não está apenas dizendo: por favor, não cole código de chatbot no compilador. Ele está dizendo que o próprio canal de comunicação do projeto tem um requisito de qualidade de fonte, o que é governança vestindo um moletom de compilador.

A largura de banda dos revisores é o recurso escasso, segundo Loris Cro e

a Let’s Data Science Loris Cro, escrevendo a partir da experiência com a Zig Software Foundation, enquadra contribuições open source como uma troca, não como uma cesta de presentes. Ele argumenta que pull requests podem, por si só, virar trabalho extra e atrito, e que é comum um mantenedor gastar menos esforço implementando uma mudança diretamente do que revisando um patch enviado. Essa é a parte que muitos debates sobre programação com IA contornam educadamente, como um Roomba evitando uma meia.

A Let’s Data Science relata que o Zig tinha cerca de 200 pull requests abertos e um pequeno grupo principal de revisores quando a política foi articulada. Esse contexto faz a proibição parecer menos uma pureza estética e mais um gerenciamento de fila. Se um projeto já tem mais demanda de revisão do que oferta de revisores confiáveis, submissões geradas podem se comportar como testes de carga sintética para humanos, exceto que ninguém apresentou um plano de capacidade.

A AI Weekly diz que Kelley enquadrou a política como triagem de recursos, citando o valor negativo de revisão das submissões de IA. Essa frase é a viga de sustentação aqui. Um patch gerado pode ser localmente barato para o contribuidor e globalmente caro para os mantenedores, o que é basicamente a tragédia dos comuns, mas com autocompletar e mais YAML.

O Bun mostra

o risco upstream, segundo a AI Weekly e Simon Willison

A AI Weekly relata que a Bun, de propriedade da Anthropic, que depende de fluxos de trabalho assistidos por IA, fez um fork do Zig depois de não conseguir enviar mudanças para o upstream. Simon Willison também observa que a Bun opera seu próprio fork do Zig e diz que a Bun foi adquirida pela Anthropic em dezembro de 2025.

Para equipes que constroem produtos comerciais sobre fundações open source, essa é a lição de governança com dentes. A fantasia corporativa usual é que o upstream é uma esteira amigável: contribua melhorias, faça com que sejam incorporadas, reduza a divergência, todo mundo bate as mãos em comemoração no corredor de uma conferência. A política do Zig mostra um modo de falha diferente. Se o seu fluxo de trabalho de engenharia depende de assistência de IA e um projeto upstream rejeita contribuições de autoria de LLM, talvez você precise manter um fork, reescrever o trabalho manualmente ou mudar como as contribuições são preparadas.

Isso não torna o Zig anti-produtividade em algum sentido cósmico. Significa que o Zig está otimizando para a confiança dos mantenedores em vez da vazão de contribuidores. Esses dois são valores reais, e fingir que nunca entram em conflito é como você acaba com um backlog com formato de formação geológica.

Isto é maior do que o Zig, segundo a Research Information A Research

Information relata que o arXiv alertou autores de que eles poderiam enfrentar uma proibição de submissão de um ano por trabalhos contendo evidências claras de saída de grandes modelos de linguagem não verificada. Esse não é o mesmo domínio de pull requests de compiladores, mas o padrão rima alto. Instituições estão saindo de uma etiqueta de IA baseada em impressões e indo para regras explícitas de responsabilidade.

Para quem constrói IA, a conclusão prática não é entrar em pânico nem realizar um banimento ritual de chatbots sob a lua cheia. É projetar fluxos de trabalho de contribuição que tornem a revisão mais barata: divulgar o uso de ferramentas quando permitido, manter patches pequenos, fornecer testes, explicar a intenção e estar pronto para assumir cada linha como se um papagaio estocástico não a tivesse sussurrado à existência. Se um projeto proíbe assistência de LLM, respeite esse limite ou contribua em outro lugar.

A próxima coisa a observar é se mais projetos open source vão copiar a linha clara do Zig ou escolher regras mais suaves em torno de divulgação e verificação. De qualquer forma, ferramentas de programação com IA estão saindo do palco de demonstração e entrando na planilha de governança. Acontece que a parte mais difícil do código gerado ainda são os humanos que precisam acreditar nele.