The Zig project's rationale for their anti-AI contribution policy

Original Article ↗ Hacker News Discussion ↗

Zig’s maintainers have adopted a strict ban on AI-generated pull requests, arguing that their scarce review time is better spent cultivating human contributors who deeply understand the language and compiler rather than triaging “LLM slop.” Commenters highlight how large language models enable cheap, low-quality drive‑by PRs that are hard to review, raise legal and architectural risks, and can erode the hard-won knowledge embodied in mature codebases. Others counter that LLMs are powerful assistive tools that can greatly boost productivity and will be integral to how the next generation codes, warning that policies like Zig’s may trade long-term contributor diversity for short-term noise reduction.

Zig’s anti-AI contribution policy

  • Core rationale: the project values cultivating long‑term human contributors over landing individual patches. Review time is seen as an investment in people, not just code.
  • LLM-authored PRs correlate with low-quality “drive‑by” contributions: non‑compiling code, hallucinations, huge first‑time PRs, and authors who can’t explain or defend the changes.
  • Maintainers want contributors who deeply understand the codebase and language; relying on LLMs is seen as undermining that learning and trust-building.
  • LLM output is viewed as non‑deterministic and hard to constrain to a narrow diff, making review more costly.

Bun fork and performance PR debate

  • A high‑profile Bun fork claimed large Zig compile-time speedups; its PR was rejected.
  • Some commenters say Zig’s AI policy made merging impossible “no matter how good” the code is.
  • Others point out core devs examined the PR deeply and argued it conflicted with Zig’s planned design (parallel semantic analysis requires language-level changes, avoid long‑term cornering of the compiler).
  • Zig already shipped significant compile-time improvements via different mechanisms, making the Bun approach look narrow and unstable for general Zig.

LLM capabilities and limits for coding

  • Supporters: LLMs can dramatically speed up CRUD apps, small tools, refactors, tests, docs, and exploration of design space; experienced devs report 2–3× or more speedups.
  • Critics: LLMs struggle with complex systems (compilers, CAD, OSs); they miss long‑tail usage patterns, invariants, and “battle‑tested” nuance accumulated over years.
  • Worry that AI encourages “vibecoding”: people who can’t specify requirements or review code still shipping large changes.
  • Some heavy users report reduced internal understanding of their own projects over time.

Maintainer workload and review strategies

  • Open source already had a review bottleneck; LLMs multiply low‑effort PRs.
  • Suggestions: more automated checks, linters, CI, AI-assisted code review, contributor reputation systems.
  • Counterpoints: CI is expensive and abusable; AI review can’t judge architecture and can itself generate noisy feedback.

Community, IP, and trust

  • Policy is framed as community-building and risk management, not pure “anti‑AI”: easier to bet on humans who clearly own and understand their changes.
  • Some raise IP/copyright concerns around LLM‑generated code and note other projects formally restrict it.
  • Others argue that focusing on provenance instead of quality is overly restrictive and will push AI‑native developers elsewhere.

Broader attitudes toward AI in software

  • Sentiment ranges from outright hostility (“bullshit machine”, technical‑debt bomb) to enthusiasm (AI as exoskeleton/mech suit, ultimate tutor and code assistant).
  • Many agree AI strongly amplifies both good and bad programmers; the main danger is not the models themselves but how people choose to use them.