Zig baniu contribuições geradas por IA e trocou o GitHub pelo Codeberg
Andrew Kelley, criador da linguagem Zig, detalhou em entrevista à JetBrains por que o projeto recusa código de IA e por que migrou sua infraestrutura para longe do GitHub.

Em entrevista à JetBrains, reportada pelo InfoQ em 23 de setembro de 2026, o criador da linguagem Zig, Andrew Kelley, detalhou dois movimentos que colocam o projeto na contramão do resto do ecossistema open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →: a proibição formal de contribuições geradas por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → e a migração do repositório principal do GitHub para o Codeberg, plataforma sem fins lucrativos hospedada na Alemanha.
Por que Kelley proíbe PRs de IA
Para Kelley, o problema não é apenas qualidade técnica, mas o custo de revisão que essas contribuições impõem à equipe. Segundo ele, pull requests de IA "invariavelmente são lixo" e têm valor negativo, porque consomem tempo de revisão sem gerar aprendizado real:
"When we get these slop contributions, they take our review time and then after a few reviews, we realize they have no clue what they're doing. They're just pasting what we say back to the chat and then laundering the chat back to pretend that they're not using chat, but we can still tell."
A segunda razão é estrutural: o time de revisores do Zig não escala junto com o volume de código. Kelley chama isso de "contributor poker" — apostar o tempo escasso de revisão em quem tem chance real de crescer dentro do projeto e um dia entrar para o core team. Segundo ele, quem usa IA para gerar contribuições cai automaticamente na categoria de colaborador drive-by, porque não está aprendendo nada:
"So we want to notice: okay, who can we invest our time in to help them become better programmers, better contributors for the project? And who is maybe a drive-by contributor? [...] people who are using AI, they're always in the second category. It's not worth it to invest in them."
Ou seja: para Kelley, revisão de código é investimento de mentoria, não checagem de sintaxe. Um PR de IA quebra essa lógica porque não existe, do outro lado, uma pessoa desenvolvendo habilidade.
O contraponto: Bun trocou Zig por Rust com ajuda de agentes
O caso mais citado no debate é o do Bun, runtime JavaScript que recentemente reescreveu sua base inteira de Zig para Rust com apoio extensivo de agentes de IA, que portaram código, verificaram a tradução e propuseram correções. Kelley reagiu num post próprio, "My Thoughts on the Bun Rust Rewrite", deixando claro que a discordância não é técnica:
"The main issue here had nothing to do with the language features of Zig vs Rust, and everything to do with the diverging value systems of the two projects."
Ou seja, dois projetos de sistemas relevantes hoje representam duas apostas opostas sobre o papel da IA em produção de código: o Bun usa agentes como força de trabalho para acelerar uma reescrita de grande porte; o Zig trata qualquer contribuição automatizada como ruído a ser filtrado antes de chegar ao review.
Por que o Zig saiu do GitHub
A segunda mudança, a migração para o Codeberg, teve motivação mais prática: falhas recorrentes no GitHub Actions, a esteira de CI do projeto. Segundo Kelley:
"GitHub simply stopped working for us. We would not have results for our continuous integration runs anymore. It just would stop working. So we moved to Codeberg and now our continuous integration server works again."
O InfoQ registra que outros desenvolvedores relataram, na mesma época, degradação de desempenho no GitHub coincidindo com o crescimento exponencial de cargas de trabalho ligadas a IA na plataforma — sugerindo que o problema pode não ser isolado ao Zig.
Além da questão técnica, Kelley justifica a escolha por incentivos: ele diz preferir a estabilidade de uma organização sem fins lucrativos à lógica de crescimento trimestral de startups e corporações:
"Codeberg is also a German nonprofit and personally I find using nonprofits to be a more stable business than startups or corporations, because these corporations are always chasing the next thing and trying to make the next quarter more profitable. Nonprofits are just trying to keep doing what they're doing, and that stability is what I want."
De onde veio o Zig
A entrevista também resgata a origem da linguagem. Kelley criou o Zig enquanto tentava construir uma estação de trabalho de áudio digital (DAW) nativa. Cada linguagem candidata falhou por um motivo diferente: JavaScript não dava controle de baixo nível sobre hardware; o Go, com seu garbage collector stop-the-world, introduzia pausas incompatíveis com reprodução de áudio em tempo real; o Rust, ainda antes da versão 1.0, tinha um borrow checker cuja fricção travou semanas de trabalho em renderização de fontes na interface; e o C++ produzia bugs de corrupção de memória que consumiam tempo de debug desproporcional. Kelley deixou o emprego em 2018 para se dedicar ao Zig em tempo integral, apostando numa linguagem sem gerenciamento automático de memória, mas com alocadores explícitos no lugar de um garbage collector ou de um borrow checker.
Hoje o Zig sustenta projetos de peso no nicho de sistemas: o terminal Ghostty, o banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → financeiro de baixa latência TigerBeetle e parte da infraestrutura de cross-compilation da Uber.
O que isso significa para quem mantém (ou contribui com) projetos open source
Para devs brasileiros que mandam PRs em projetos de sistemas ou pensam em criar os próprios, o caso Zig funciona como um estudo de política de contribuição explícita. "Contributor poker" é um jeito de formalizar algo que todo maintainer sênior já sentiu na prática: tempo de review é o recurso mais escasso de um projeto open source, e cada PR automatizado que chega sem domínio real do problema rouba esse tempo de alguém que estava disposto a aprender.
Isso não significa que toda IA em contribuição open source será banida — o próprio contraste com o Bun mostra que times de peso estão apostando o oposto, usando agentes como força de trabalho para reescritas inteiras. O que fica claro é que não existe consenso, e cada projeto vai precisar declarar sua própria regra, do jeito que o Zig fez publicamente. Antes de abrir um PR gerado (ou revisado) por IA em qualquer repositório, vale checar se o projeto tem uma política explícita — porque, cada vez mais, ela vai existir.
Já a saída do GitHub por falhas de CI é um sinal a monitorar para quem depende de GitHub Actions em pipelines críticos: se o crescimento de cargas de IA na plataforma está de fato degradando desempenho, como sugerem os relatos citados pelo InfoQ, times que hoje dependem 100% do GitHub podem querer ter um plano B — Codeberg, sourcehut ou GitLab self-hosted — antes que a esteira pare no meio de um deploy.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Google abre o código do AX, orquestrador de agentes de IA inspirado no Kubernetes
O AX trata agentes autônomos como atores com estado, não como microsserviços ou jobs em lote, e usa CRDs no estilo Kubernetes para suspender e retomar tarefas em menos de um segundo.











