Zig banned AI-generated contributions and swapped GitHub for Codeberg

In an interview with JetBrains, reported by InfoQ on September 23, 2026, Zig language creator Andrew Kelley detailed two moves that put the project at odds with the rest of the open source ecosystem: the formal ban on AI-generated contributions and the migration of the main repository from GitHub to Codeberg, a nonprofit platform hosted in Germany.

Why Kelley bans AI PRs

For Kelley, the problem isn't just technical quality, but the review cost these contributions impose on the team. According to him, AI pull requests "invariably are slop" and have negative value, because they consume review time without generating any real learning:

"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."

The second reason is structural: the Zig review team doesn't scale alongside code volume. Kelley calls this "contributor poker," betting the team's scarce review time on people who have a real chance of growing within the project and one day joining the core team. According to him, anyone who uses AI to generate contributions automatically falls into the drive-by contributor category, because they aren't learning anything:

"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."

In other words: for Kelley, code review is mentorship investment, not syntax checking. An AI PR breaks that logic because there's no person on the other end developing a skill.

The counterpoint: Bun swapped Zig for Rust with the help of agents

The case most cited in the debate is Bun, the JavaScript runtime that recently rewrote its entire codebase from Zig to Rust with extensive support from AI agents, which ported code, verified the translation, and proposed fixes. Kelley responded in a post of his own, "My Thoughts on the Bun Rust Rewrite," making clear the disagreement isn't technical:

"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."

In other words, two relevant systems projects today represent two opposing bets on the role of AI in code production: Bun uses agents as a workforce to speed up a large-scale rewrite; Zig treats any automated contribution as noise to be filtered out before it reaches review.

Why Zig left GitHub

The second change, the migration to Codeberg, had a more practical motivation: recurring failures in GitHub Actions, the project's CI pipeline. According to 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."

InfoQ notes that other developers reported, around the same time, performance degradation on GitHub coinciding with the exponential growth of AI-related workloads on the platform, suggesting the problem may not be isolated to Zig.

Beyond the technical issue, Kelley justifies the choice on incentives: he says he prefers the stability of a nonprofit organization to the quarterly growth logic of startups and corporations:

"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."

Where Zig came from

The interview also revisits the language's origin. Kelley created Zig while trying to build a native digital audio workstation (DAW). Each candidate language failed for a different reason: JavaScript didn't offer low-level control over hardware; Go, with its stop-the-world garbage collector, introduced pauses incompatible with real-time audio playback; Rust, still before version 1.0, had a borrow checker whose friction stalled weeks of work on font rendering in the interface; and C++ produced memory corruption bugs that consumed a disproportionate amount of debugging time. Kelley left his job in 2018 to work on Zig full-time, betting on a language without automatic memory management, but with explicit allocators in place of a garbage collector or a borrow checker.

Today Zig underpins heavyweight projects in the systems niche: the Ghostty terminal, the low-latency financial database TigerBeetle, and part of Uber's cross-compilation infrastructure.

What this means for those who maintain (or contribute to) open source projects

For developers who submit PRs to systems projects or are thinking of starting their own, the Zig case works as a case study in explicit contribution policy. "Contributor poker" is a way of formalizing something every senior maintainer has already felt in practice: review time is the scarcest resource in an open source project, and every automated PR that arrives without real command of the problem steals that time from someone who was willing to learn.

That doesn't mean all AI in open source contributions will be banned, the very contrast with Bun shows that heavyweight teams are betting on the opposite, using agents as a workforce for entire rewrites. What's clear is that there's no consensus, and every project will need to declare its own rule, the way Zig did publicly. Before opening an AI-generated (or AI-reviewed) PR in any repository, it's worth checking whether the project has an explicit policy, because, increasingly, it will.

Meanwhile, the departure from GitHub over CI failures is a signal worth monitoring for anyone who depends on GitHub Actions in critical pipelines: if the growth of AI workloads on the platform is indeed degrading performance, as the reports cited by InfoQ suggest, teams that today rely 100% on GitHub may want to have a plan B, Codeberg, sourcehut, or self-hosted GitLab, before the pipeline stops mid-deploy.