The Code Wall

In the same week, two projects answered the question "What do we do about AI-generated code?" with diametrically opposite approaches. Zig, the systems programming language, bans all LLM-generated contributions from its codebase. Vera, a new language published the same week, is designed specifically for machines to write. Both have coherent rationales. The tension between them defines where software development goes next.

The wall

Zig's policy is comprehensive. No LLMs for issues. No LLMs for pull requests. No LLMs for comments on the bug tracker. Contributors who prefer to write in a language other than English are encouraged to use their native language, with human community members providing translation. An LLM is not an acceptable substitute for a human translator.¹

Loris Cro, VP of Community at the Zig Software Foundation, articulated the reasoning: the project invests in contributors, not contributions. When a maintainer spends time reviewing an LLM-assisted PR, that effort builds nothing lasting. The reviewer's feedback doesn't develop a contributor's understanding. The mentorship relationship that turns a first-time contributor into a long-term maintainer never forms.¹

Cro calls this "contributor poker" — betting on the person behind the PR, not the code in it. A mediocre human PR that leads to a mentoring conversation has more long-term value to the project than a polished LLM PR that leads nowhere.

Simon Willison, who amplified the policy, identified the core logic: "If an LLM wrote a PR, why should maintainers review it rather than use their own LLM to solve the problem?" The reviewer's time is the scarce resource. Spending it on code whose author cannot learn from the feedback wastes the most valuable thing the project has.¹

The bridge

Vera takes the opposite position. If AI is going to write code, give it a language designed for the purpose. Published on GitHub the same week Zig's policy trended on HN, Vera is explicitly "a programming language designed for machines to write."²

The premise: human-readable programming languages are a constraint that made sense when humans were the only writers. If a machine generates the code and a machine executes it, the intermediate representation doesn't need to be optimized for human comprehension. Vera optimizes for machine generation, machine verification, and machine execution.

This is the logical conclusion of what we described in Dark Code: AI-written code that runs in production and nobody understands. Vera doesn't solve the understanding problem. It formalizes the decision to stop trying.

The question underneath

Both projects are answering the same question: who vouches for this code?

Zig's answer is that a human must vouch for every line. If the contributor can't explain their code, defend their design choices, and incorporate feedback into their understanding, the code doesn't belong in the project. The vouching is personal. The relationship between contributor and maintainer is the quality mechanism.

Vera's answer is that machine-generated code needs machine verification, not human vouching. If the generation process is deterministic and the verification process is automated, human comprehension of the intermediate code is unnecessary overhead.

The gap between these positions is the central tension in software development right now. We documented it in The Reviewer's Trap (AI moved the hard part onto the people reviewing the code), Dark Code (code running in production that nobody understood), and Vibe Coders (millions can code now, nobody said they should). Every article circled the same question. Zig and Vera are the first projects to answer it explicitly.

The practical reality

Zig's approach works because Zig is a project with a clear identity, a small core team, and a community that selects for deep technical engagement. The policy costs them contributions. It buys them contributors.

The cost is real. Bun, the JavaScript runtime built on Zig, was acquired by Anthropic and uses AI extensively in its development. Because of Zig's policy, Bun maintains its own Zig fork without contributing improvements upstream. The wall keeps AI code out. It also keeps some of the most active Zig users out.¹

Vera's approach works if you accept the premise that human code review is a bottleneck, not a feature. For production systems where correctness is verified by tests and formal methods rather than human judgment, the premise holds. For systems where understanding matters — security, safety-critical, regulatory — it does not.

Most software falls somewhere between Zig's idealism and Vera's pragmatism. The question for every project is where they draw the line, and whether they draw it consciously or let it drift.

Share on Bluesky · Share via Email