↓ Skip to main content

Ban It, Ship It, or Own It

·1271 words·6 mins
Author
Yang Chung

I’ve spent the last few months learning Go with an AI assistant open in the next pane, and my verdict is boring. It’s great at some things, useless at others, and the whole skill is knowing which is which. So I’ve been watching two open-source projects come to opposite conclusions this year.

Zig bans AI-assisted contributions outright. No LLM-written code or prose, no paraphrasing it, no using it to find bugs, not even brainstorming with it. The ban was in place by April, and in late May its president, Andrew Kelley, called AI-assisted contributions “invariably garbage” on a podcast. Meanwhile Bun, the Anthropic-owned JavaScript runtime written in Zig, used Claude to rewrite itself in Rust. The work ran May 3 to 14 and was announced in July. It was over a million lines in 11 days, about $165,000 at API pricing, with dozens of Claude agents running in parallel. Kelley called it “unreviewed slop.”

It’s tempting to file this as a culture war between AI believers and AI refuseniks. I think the Amish are a better model. They aren’t the Luddites people assume. They ask whether a new technology serves the community, and refuse the ones that would hurt it. For code, I think the question is simpler. When this breaks at 2 a.m., is there a human who can explain why it was written this way? Zig, Bun, and Rust each answer that differently. I think Zig’s answer is right for Zig, Bun’s answer doesn’t hold up, and Rust’s is the one other projects should copy.

Why Zig banned it
#

Kelley’s reasons are better than the soundbite. The first one is arithmetic. Zig had 200 open pull requests at the time, and more pull requests than reviewers. A model produces plausible patches faster than people can check them, and a patch nobody has time to understand is a liability. The second is mentorship, which Kelley says is part of Zig’s core mission. Accepting code the contributor didn’t write works against that.

There’s a third reason Kelley leans on less. Zig is still a small language, so it’s thin in the training data next to Python, JavaScript, or Rust. It’s also pre-1.0 (0.16 as I write this), and the standard library keeps changing. The 0.15 release notes call the new reader and writer changes “extremely breaking.” I’d expect a model trained on a small, partly outdated corpus to be noticeably worse at Zig, and when Kelley calls the submissions garbage, I don’t think he’s exaggerating about his own codebase.

But that’s also why the ban doesn’t travel. “AI is bad at Zig” is true largely because Zig is small and moving fast, which is a fact about the training data, not about AI. Take the same rule to Go or TypeScript, where the models are strong, and a blanket ban throws away real help to avoid a review problem. It makes sense for Zig. It doesn’t make sense as a rule for everyone.

Why Bun worries me
#

Bun is harder. By my own rule, it looks like a good use of AI, a mechanical port of a codebase people already understood. Bun’s post says “Anyone who understands the original Zig code understands the mechanically translated Rust code.” Every line was reviewed by two adversarial reviewers (also Claude), a human read a lot of it side by side with the Zig, and the result passed 100% of the test suite on every platform with no tests skipped or deleted. That’s over 1.3 million assertions on Linux alone.

Still, I think it breaks down at this scale. A port a person could check file by file becomes something nobody can own when it’s a million lines in 11 days. The tests show the new code behaves like the old code, but they don’t give anyone a mental model of it. Kelley asked why the test suite is “not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in [a] million lines of unreviewed slop?” The problem is that AI wrote code faster than any person could understand it, and the reviewers who read every line were also AI.

What Rust got right
#

Rust’s approach makes more sense to me. In August, rust-lang/rust adopted an LLM policy that covers the compiler and a few tools like cargo and clippy. It doesn’t ban the tools. It aims them. The core principle is “It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.”

The part I like most is the exception. Rust allows LLM-written code as an experiment, if it’s pre-arranged with a reviewer, non-critical, well-tested, and disclosed, and if the author and reviewer both commit to fully understanding it. So AI can write the code, as long as a named human agreed in advance to own it. That’s the Amish question again, applied to code.

The Linux kernel’s guidance for AI coding assistants lands in the same place. The human who submits an AI-assisted patch is responsible for “Reviewing all AI-generated code” and “Taking full responsibility for the contribution.” So Zig, Rust, and Linux all keep a human who owns the result. Zig just does it by refusing the tool.

What I do
#

This matches my own work. I point it at mechanical, machine-checkable stuff like boilerplate, tedious refactors, and test scaffolds, where it’s fast and where go build, the tests, and CI will catch it if it’s wrong. I keep for myself what a model can’t know, like why the system is shaped the way it is and what’s even worth building. I think Bun adds one more condition. The job has to be small enough that I can still read what comes out.

So I don’t think the projects that thrive will be the ones that ban AI or the ones that turn it loose. I think they’ll be the ones that scale understanding as fast as they scale generation, and never ship more code than a human can still answer for. We’ve gotten very good, very fast, at making machines write code. Are we getting any better at making sure someone still understands it?

However that shakes out, one thing feels certain. We, programmers and everyone else who makes things, truly live in an unprecedented and interesting time.

Update (September 28, 2026): I revised this post after going back through the sources. A few things were wrong. Zig’s ban was already in place by April, not May. Bun’s rewrite ran in May and was only announced in July, so it wasn’t “two months later.” The Neo-Catholics who refuse to be resleeved come from the Netflix version of Altered Carbon, not Richard Morgan’s novel, so I cut that example. And the Torvalds quote I used was about an AI code review tool, not AI-written patches, so I replaced it with the kernel’s actual guidance for AI-assisted contributions. Rust’s policy, which I called emerging, was formally adopted in August, and it turned out to include a pre-arranged exception for LLM-written code, which makes my point better than I did. I also gave Bun a fairer hearing and backed off saying only one project got it right. I still think Rust’s approach is the one to copy.