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

Original Article ↗ Hacker News Discussion ↗

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.