Zig は、主要なオープンソースプロジェクトの中でも最も厳格な LLMに対する反対（ポリシー） の1つを持っています:

課題（issues）にLLMを使わない。

プルリクエスト（pull requests）にLLMを使わない。

バグトラッカーでのコメントにもLLMを使わない（翻訳を含む）。英語での投稿が推奨されますが必須ではありません。ご自身の母国語で投稿しても構いませんし、発言内容を解釈するために他の人がそれぞれの翻訳ツールを使うことを前提にしても大丈夫です。

Zigで書かれたプロジェクトとして最も著名なのは、おそらく Bun というJavaScriptランタイムで、これは2025年12月に Anthropicに買収された もので、もちろんAI支援を大いに活用しています。

BunはZigの独自フォークを運用していて、最近は 「llvmバックエンドに並列セマンティック解析と複数のコード生成ユニットを追加した」ことでBunのコンパイルが4倍のパフォーマンス向上を達成した そうです。こちらが そのコード。しかし @bunjavascript が言うには:

現時点では、これをアップストリームする予定はありません。Zigには、LLMが執筆したコントリビューションに対する厳格な禁止があるためです。

Contributor Poker and Zig's AI Ban（Lobste.rs経由）で、Zig Software Foundationのコミュニティ担当VPであるLoris Croは、この厳格な禁止の根拠を説明しています。これは、LLM支援によるコントリビューションを包括的に禁止することについて、私がこれまでに見た中で最もよく言語化されていると思う内容です:

成功しているオープンソースプロジェクトでは、いずれ、処理できる量よりも受け取るPRの数が増えてくる地点に到達します。これまで私が述べたことを踏まえると、作業からの投資対効果（ROI）を最大化するために、完成度に欠けるPRの受け入れをやめるのが理にかなっているように思えるでしょう。しかし、それがZigプロジェクトがやっていることではありません。代わりに、少しでも道のりが必要であっても、新しいコントリビューターが自分たちの成果を取り込めるようにするためにできる限り手を尽くします。私たちはこれを「それが正しいから」だけで行っているのではなく、「それが賢いから」でもあります。

Zigは、コントリビューションそのものよりもコントリビューターを重視します。各コントリビューターは、Zigのコアチームによる投資を表しています。PRをレビューして受け入れて、新しいコードをそのまま取り込むことが主目的というわけではありません。むしろ、時間をかけて信頼できて、かつ継続的に成果を出せるようになる新しいコントリビューターを育てることが主目的です。

LLM支援はそれを完全に壊してしまいます。LLMがあなたのために、Zigへの完璧なPRを提出するのに役立ったとしても、Zigチームがあなたの作業をレビューするのに費やす時間は、彼らがプロジェクト全体として信頼できる新しいコントリビューターを増やすのには何の役にも立ちません。

Lorisはここで、その名前の由来を説明しています:

私が「コントリビューターポーカー」と呼ぶ理由は、実際のカードゲームについて人々が「あなたはカードをプレイするのではなく、その人をプレイするんだ」と言うのと同じで、コントリビューターポーカーでも同様に考えるからです。コントリビューターポーカーでは、最初のPRの中身に賭けるのではなく、そのコントリビューターに賭けるのです。

これは私にもとても納得できます。私が他の場所でも見かけたアイデアに関係しています。もしPRの大部分がLLMによって書かれているのなら、なぜプロジェクトのメンテナーは、そのPRをレビューして議論するために時間を使う必要があるのでしょうか？同じ問題を解くために、自分でLLMを立ち上げればよいのではないでしょうか。