Zig Creator on AI Code Ban: You Can Smoke, But Not in My House

Background: Why the Zig Project Bans AI Code Contributions

Zig programming language creator Andrew Kelley recently posted a thought-provoking comment on the Lobsters forum regarding Zig's ban on AI-assisted code contributions. The statement quickly sparked heated discussion in the developer community, as it strikes at a core controversy in the open-source world: Should projects accept code assisted by large language models (LLMs)?

To understand why Kelley holds such a firm stance, you first need to understand Zig's unique positioning. Zig is a systems programming language born in 2015, aimed at being a modern replacement for C. Unlike Rust, which guarantees memory safety through a complex ownership system, Zig takes a more minimalist path—it retains manual memory management capabilities but uses compile-time computation (comptime), explicit error handling, and elimination of implicit behavior to let programmers write code that is both high-performance and predictable. Zig's compiler can even serve as a cross-compilation toolchain for C/C++, which has earned it growing attention in embedded systems, game engines, and infrastructure software. Precisely because Zig pursues the ultimate transparency of "no hidden control flow, no hidden memory allocations," the project demands extreme clarity of intent for every line of code—contributors must precisely understand what every character they write means.

"Digital Smell": Why AI-Generated Code Is Instantly Recognizable

In his comment, Kelley first pushed back against a common claim—"nobody can tell whether code was written by AI." His judgment was direct:

The mistakes humans make are fundamentally different from LLM hallucinations, which makes them easy to identify.

This point deserves elaboration. When human programmers write bugs, it's usually because they didn't think through the logic, were careless, or had knowledge gaps. Errors produced by LLMs are an entirely different beast—they'll confidently call APIs that don't exist, fabricate plausible-sounding function names, or make completely unfounded assumptions about certain behaviors. The error patterns are starkly different, and experienced maintainers can quickly sniff out the difference.

It's worth explaining what "hallucination" actually means at a technical level. A large language model is fundamentally a probabilistic prediction system—given a preceding text sequence, it predicts the next most likely token. The model doesn't "understand" code semantics or runtime behavior; it makes inferences based on statistical patterns in its training data. When the model encounters scenarios insufficiently covered by training data, or when multiple statistical patterns conflict, it "hallucinates" content that seems plausible but is actually wrong. In code generation scenarios, this hallucination is particularly dangerous: the model might generate a function call with a perfectly correct signature but completely wrong semantics, confuse parameter orders across different API versions, or conjure up a method name that doesn't exist in any library. What makes it trickier is that these hallucinations are often wrapped in well-formatted, reasonably-named code structures that show no surface abnormalities—problems only surface during actual execution or deep review.

Kelley also introduced a vivid concept: "digital smell." He believes that people who rely heavily on AI agent programming develop a specific stylistic trace in their code. The coder themselves can't smell it, but for those who don't use AI tools, the scent is quite obvious.

This "digital smell" has several identifiable characteristics in practice: overly verbose comments (especially the style that explains obvious code line by line), unusually uniform but personality-less variable naming, "textbook-style" handling of edge cases that covers everything yet ignores project-specific constraints, and a certain "averaging" tendency in code structure—neither particularly elegant nor particularly clumsy, but presenting the statistical median style of training data. For maintainers who have been immersed in a specific codebase for a long time, these traces are like a stranger's handwriting mixed into a handwritten diary—the incongruity is immediate.

The Smoker Analogy: A Project Stance with Clear Boundaries

The most viral part of the comment was Kelley's analogy:

It's like a smoker walking into a room—every non-smoker notices immediately.

He then delivered his conclusion:

I'm not telling you not to smoke, but I am telling you not to smoke in my house.

This analogy spread widely because it expresses Zig's stance both clearly and with restraint: We won't interfere with how you use AI in your own projects, but in Zig's codebase, AI-assisted contributions are not accepted. The attitude is explicit, the boundary is clear, and there's no hostility.

The AI Governance Challenge for Open Source Communities

Behind this issue lie several deep problems that open-source communities are confronting.

Code Quality Control

LLM-generated code may look fine on the surface but often lacks genuine understanding of project context, design philosophy, and long-term maintainability. Zig is a systems programming language that pursues excellence, with extremely high code quality requirements—every line of code needs the contributor to truly internalize what it's doing.

In systems programming, code quality means far more than "it works." A piece of code operating on a memory allocator must not only be functionally correct but also consider alignment requirements, cache locality, behavioral consistency across different architectures, and interaction effects with other subsystems in the project. These deep constraints are rarely written explicitly in documentation but exist as "implicit knowledge" in the minds of maintainers and in code review traditions. LLMs cannot access this context—even if their generated code compiles and passes tests, it may plant hidden dangers in performance characteristics, error propagation paths, or future extensibility. For a project like Zig, where the standard library is still actively evolving and APIs haven't fully stabilized, every code merge requires contributors to have clear judgment about "why this approach and not that one."

Contributor Learning and Growth

Participating in open source isn't just about submitting code to a repository—it's also a process of learning and growth for the contributor. If someone generates code with AI and submits a PR directly without understanding the underlying logic, such a "contribution" offers no substantial value to either the project or the individual.

It's worth explaining the Pull Request (PR) workflow in open-source projects here, as it directly relates to the challenges AI code brings. In typical open-source collaboration, contributors first fork the project repository, make changes on their own branch, then submit a PR requesting that changes be merged into the main branch. Then comes the critical step—Code Review: maintainers inspect changes line by line, suggest modifications, and contributors need to respond to this feedback and explain their design decisions. This back-and-forth discussion process is itself the core mechanism for knowledge transfer and quality control. However, when contributors use AI to generate code, they often cannot effectively answer questions like "why did you choose this implementation approach" during code review, because the design decisions didn't come from their own thinking. This not only reduces review efficiency—maintainers need to spend more time verifying every assumption in the code—but also undermines code review's function as a channel for knowledge exchange.

Trust and Accountability

Open-source project operations are built on trust: maintainers need to believe that contributors can take responsibility for every line of code they submit. When AI is deeply involved in the code writing process, "who actually wrote this code and who can be accountable for its correctness" becomes a gray area, eroding the community's foundation of trust.

This problem also extends to legal and licensing dimensions. Open-source projects typically require contributors to sign a Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO), declaring that the submitted code is their own original work or that they have the right to submit it. When code is generated by an LLM, the legal force of this declaration becomes murky—LLM training data may contain code under various licenses, and whether the generated output constitutes a derivative work of the training data remains legally unresolved. For a project like Zig that uses the MIT license, if merged code inadvertently contains fragments protected by strongly copyleft licenses like GPL, it could trigger serious compliance risks.

Different Projects, Different Choices

It's worth noting that Zig's approach doesn't represent a consensus across all open-source projects. In fact, many projects maintain an open or even welcoming attitude toward AI-assisted code, valuing the final code quality and the contributor's understanding of the code over how it was produced.

The open-source community currently displays a clear spectrum on AI code policies. On the strict end, besides Zig, the Linux kernel community is also cautious about AI-generated code—some core maintainers have explicitly stated they won't accept AI code that hasn't been thoroughly reviewed and understood by humans, and Gentoo Linux passed a formal policy requiring disclosure of AI tool usage as early as 2023. At the other end of the spectrum, many web application and tooling projects are open to AI assistance, with some even encouraging the use of GitHub Copilot, Cursor, and other AI programming tools in their contribution guidelines to improve efficiency, provided contributors can take responsibility for the submitted code. The middle ground consists of numerous projects adopting a default "don't ask, don't tell" strategy—neither explicitly prohibiting nor explicitly allowing AI use, effectively relying on the code review process itself to control quality. Notably, the current ecosystem of mainstream AI programming tools is already quite large: GitHub Copilot has over a million paid users, Cursor editor rapidly rose in 2024 as a representative AI-native IDE, and there are many other options including Codeium, Tabnine, and Amazon CodeWhisperer. The proliferation of these tools means that AI-assisted programming is not a topic that can simply be avoided—every open-source project will sooner or later need to form its own clear stance.

But Kelley's statement reminds us of something important: Project maintainers have the right to set rules for their own "house," and the community should respect that autonomy. Every project has different positioning, quality standards, and cultural atmosphere—a one-size-fits-all policy isn't realistic.

Final Thoughts

As AI programming tools become increasingly prevalent, finding the balance between development efficiency, code quality, and community culture is a question every open-source project will eventually need to answer. Andrew Kelley's "smoking analogy" offers a worthwhile approach: acknowledge the value of the tool itself, but draw clear boundaries for specific collaborative spaces.

Your project, your rules. That itself is part of the open-source spirit.