Zigプロジェクトの anti-AI 貢献ポリシーの根拠
(simonwillison.net)- Zigは、Issue、Pull Request、バグトラッカーのコメント、翻訳における LLMの使用 を禁止する強いルールを運用している
- 英語の使用は推奨事項にすぎず必須ではなく、貢献者は 母語での記述 が可能で、他の人は各自が選んだ翻訳ツールで内容を解釈できる
- Bunは独自のZig forkでLLVM backendに parallel semantic analysis と multiple codegen units を追加し、Bunのコンパイルで4倍の性能向上を達成したが、LLM作成の貢献を禁止しているため、現時点でupstream化の計画はない
- Zigのレビュー方式は、不完全なPRを拒否するよりも、新しい貢献者がmerge可能な作業に到達できるよう支援し、個別の貢献物より 貢献者の成長 を重視する
- LLMが大半を書いたPRは、レビュー時間が信頼できる新しい貢献者を増やすことに使われなくなり、maintainerが自分でLLMを実行して同じ問題を解決するという選択肢も生まれる
ポリシーとBun forkの衝突
- Zig は Code of Conduct で、Issue、Pull Request、バグトラッカーのコメント、翻訳における LLMの使用禁止 を明記している
- 英語の使用は推奨事項であり、貢献者は母語で記述できる
- 他の人は各自が選んだ翻訳ツールで内容を解釈できる
- Zigで書かれた代表的なプロジェクトとして Bun JavaScriptランタイムがあり、Bunは2025年12月に Anthropicに買収された
- Bunは独自のZig forkを運用しており、LLVM backendに “parallel semantic analysis and multiple codegen units” を追加して、Bunのコンパイルで 4倍の性能向上 を達成した
- 関連コードは oven-sh/zig 比較リンク で公開されている
- Bunは、Zigが LLM作成の貢献 を厳格に禁止しているため、現時点でupstream化の計画はない
- Zig core contributor によると、このパッチはLLMの問題とは別に、そもそも受け入れられにくい
- parallel semantic analysis は以前から計画されていた機能だが、Zig言語そのもの に影響を与える
Contributor Poker と貢献者中心のレビュー
- Contributor Poker and Zig's AI Ban における contributor poker は、Zigの厳格な禁止ポリシーを理解するための重要な比喩である
- 成功したオープンソースプロジェクトは、処理可能な量を超えるPRを受け取る段階に到達する
- ZigはROIを最大化するため、不完全なPRを拒否するよりも、新しい貢献者が作業をmergeできるよう支援する方式を選んでいる
- この方式は「正しいこと」であるだけでなく「賢いやり方」でもあると見なされている
- Zigは個別の貢献物より 貢献者 を重視する
- PRレビューと受け入れの第一の目標は新しいコードを入れることではなく、時間をかけて信頼でき生産的な貢献者へ成長する人を支援することにある
- 各貢献者はZig core teamの投資対象となる
- LLM支援はこの構造を壊す
- たとえLLMが完璧なPR作成を助けたとしても、Zigチームがレビューに使う時間は、新しく自信があり信頼できる貢献者を増やすことにはつながらない
- “contributor poker” は、カードではなく人を見てゲームをするという比喩から来た表現である
- 最初のPRの内容より 貢献者に賭ける という意味に近い
- LLMが大半を書いたPRであれば、プロジェクトのmaintainerはそのPRをレビューして議論する代わりに、自分で直接LLMを実行して同じ問題を解決するという選択肢を持つ
1件のコメント
Hacker Newsの意見
https://kristoff.it/blog/contributor-poker-and-ai/によると、LLMベースの貢献は総じて否定的だったとのこと
価値のない drive-by PR が幻覚コードで雑音を増やし、コンパイルすら通らなかったり CI を通過できなかったりし、初投稿の人が1万行の PRを送ってくることもあった
見た目は問題なく、LLMを使っていないと明記していた PR もあったが、その後の議論で、作者がこっそり LLM を参照しつつ誤りの多い回答を繰り返していることがすぐに露呈したという
hooks は clone 時にインストールを強制するきれいな方法がないが、GHA Workflows や他の forge の同等機能はあるかもしれない
ある程度の規模と人気があるプロジェクトなら、こうしたものは基本要件だと思う
「AI は貢献できない」という問題のかなりの部分は、より良い自動チェックやガードレールである程度減らせそうだ
AI がこの新しい種類のスパムを可能にしたという点を除けば、本質は AI ではない
AI がなくても、人々が安価な海外開発者の大部隊を雇って中程度の品質の drive-by PR を大量生産させれば、効果は同じだろう
AI でも良いコードは書けるが、他の道具と同じく慎重に使う必要がある
これはプロジェクトと目標を理解した人が道具をうまく使って慎重に作った貢献ではなく、スパムだ
AI ポリシーをめぐる騒ぎは、Bun の開発者たちがそのポリシーのせいで性能 PR を upstream できないと言ったことで生じたようだ
しかし実際の理由は、その PR のコード自体の状態が良くなく、不健全な複雑さを導入するために見える https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
引用された説明によれば、並列 semantic analysis はずっと以前から Zig コンパイラの明示的な計画であり、self-hosted Zig compiler の設計にも大きな影響を与えてきたが、正しく実装するにはコンパイラ実装だけでなくZig 言語そのものにも変更が必要だという
Zig がより良い結果を得るための独自ロードマップと衝突し、言語全体を継続的に改善しようとする方向を妨げるからだ
ポリシーがあらゆるLLM コードを明示的に禁止しているのだから、そのポリシーこそが当然「本当の理由」だ
Zig 側は ZeroMQ の道をたどっているように見える https://zguide.zeromq.org/docs/chapter6
「プロジェクトの集団所有権を強制して貢献者の経済的インセンティブを高め、敵対的主体による hijack のリスクを下げる」という方向だ
健全な貢献者コミュニティは、単なるコード性能、機能数、コード行数よりも重要だ
今日の zeromq の「コミュニティ」は希薄で、今も活動している優れた人は何人かいるが、人間的なプロセスやコミュニケーションチャネルは明確に定義されておらず、十分に運用もされていない
libzmq とほとんどの binding が安定しているため、こうした人間的活動や相互作用の不足はある程度許容、あるいは正当化されるのかもしれないが、Hintjens の素晴らしいビジョンが zeromq をここまで導き、彼を失って以降プロジェクトは漂流しているように感じる
コミュニティ中心のビジョンとはやや皮肉なことに、コミュニティを得て維持するにはカリスマ的で活動的なリーダーが必要らしく、それはソフトウェア開発よりも人間の本性について多くを語っている
Zig の話に戻すと、Zig は PR 不足ではないので、no-LLM の貢献をあらかじめ選別できるという前提がある
それは彼らにとって良い選択であり、「contributor poker」という考え方も理解できる
ただし新規流入が減ればゲームは変わり、そのときも Zig の人たちが新規貢献者を求めるなら、網を広げる必要があるかもしれない
ただ、その時点では LLM 支援の貢献を解禁しても回復には遅すぎる可能性がある
AI 生成の OSS 貢献について疑問なのはこれだ
AI が開発者の生産性をそれほど大きく上げるなら、なぜ OSS maintainer が自分と LLM の間に見知らぬ貢献者を挟みたがるのか?
maintainer が直接Claude Codeに問い合わせればいい
同僚の言葉を借りれば、「私たちに必要なのは AI モデルと対話する仲介者ではないし、コーディングがボトルネックでもない」だ
AI で最初の悪い版を作り、プロンプトを調整し、手で修正し、別の部分も直させ、関連機能を見つけて追加させ、benchmark を回して小さな機能を削ったり似た実装のどちらかを選んだりする
あちこちさらに手で直し、拡張された自動テストを回して変わった設定の奇妙なバグを見つけ、AI と手作業で修正する
そうして 20 時間後、最終版は 50 行しかなく、各行が 5 回ずつ書き直されているかもしれない
maintainer は最終版だけを 1 時間ほどレビューすればいい
5 分間 AI にパッチを書かせて、コンパイルすらできない 1000 行を読んでもいないまま maintainer に送るのとはまったく違う
「それは簡単すぎて、自分にもできたはずだ」
その通りだが、実際にはやっていない
ただし、人間にするように高水準の指示だけ投げれば済むような種類のものではない
AI が高水準の指示だけで動くと主張する人たちは、たいてい「考えなくていい」プロジェクトをやっていて、細部に入る開発者があまり悩む必要のないケースなのではないかと思う
LLM の唯一の利点が、手で打つのが面倒なコードを生成することだけだという意味でもないことを願う
「Zig は貢献より貢献者を重視する。PR をレビューして受け入れる主目的は新しいコードを入れることではなく、時間をかけて信頼でき生産的な貢献者へと成長できるよう助けることだ。LLM 支援はこれを完全に壊す。LLM が完璧な PR を提出するのを助けたとしても同じだ」という説明が、今まで見た中で最良の根拠だ
Zig の決定を全面的に支持するし、コミュニティと実際のプロジェクトの両方に対する長期的ビジョンを高く評価する
正直なところ、LLM がもっと協調的な作業にそれほど向いているとは思わない
今後どう変わるかは見るとしても、AI 生成 PR を受け取ると結局自分でやり直すことが多く、皮肉なことにそのやり直しに LLM を使うことになって、だんだん葛藤を感じる
それでも少なくとも今後 5 年くらいは、Zig のポリシーは良いアイデアだと思う
彼らが言える中で最も敵対的でない表現だと思うし、自分のプロジェクトについての決定として尊重する
ただ、それでもなおプロジェクトを不必要に縛っている感じもする
LLM は道具であり、考えたり調べたりコーディングしたりするのを助けてくれる
使いすぎることはあっても、役立つところでは受け入れるべきだ
Bun の PR を別の理由で受け入れないのはまったく構わないが、すべてのLLM 作成 PRを単純に禁止するのは不必要に制限的だ
ただ仕事の質に集中すればいい
maintainer が自分で LLM を使って同じことをすれば、おそらくもっと良い設計と、もっと慎重なアプローチでできるだろう
maintainer は低労力 PR のレビューだけをしているわけではなく、開発に時間を使わなければならない
LLM コードの洪水は maintainer に不利な方向へバランスを変えており、ただ禁止したくなる理由は十分理解できる
しばらく LLM と coding agent を回してみた全体的な印象は、これは電動工具やクレーンであって意思決定ツールではない、ということだ
組織の中で概念理解と深いエンジニアリング理解に優れた人たちは、生産性が爆発的に伸びる
逆に理解が浅い人や新参、junior は、とにかく動けば終わりだと思って地獄のようなコードを作っている
LLM は組織の中に知的格差を作り、使えば使うほどその格差を広げる
後になると、生成されたコードのせいで組織内部の成果物を信頼できなくなるかもしれない
AI はたいていスキルセットを増幅し、良い面も悪い面もすべて大きくする
最近とても良かった使用例は authentication daemon の concept を書くことだった
Codex と対話しながら提案を選び、通常の Web 検索でクロスチェックし、最終ドラフトを固めたうえで同僚たちと議論した
こうした統合 Web 検索付きの対話型 planningは非常に有用で、すでに書かれたコードを AI でレビューするのも純粋に利点があると思う
ただし AI の核心的な caveat は、結局のところ道具より賢くなければならないことだ
Codex が tech stack X を使えと提案したら、なぜ本当に良いのか調べて完全に理解し、他の解決策とも比較しなければならない
多くの人がこの段階を飛ばすために無数の問題が生じており、それは致命的だ
対話が終わった後には AI より賢くなっていなければならず、AI が言ったことを完全に理解し批判できなければならない
アーキテクチャが決まった後は、LLM は実装をかなりうまくこなす
概して素晴らしく、テストもよくされたコードを作らせることはできるし、同じ時間で一人でやるよりずっと良いこともある
だが AI が作ったものすべてについて知識を追い続けるのは挑戦だ
「PR の大半が LLM の書いたものなら、maintainer はその PR をレビューして議論する時間で自分の LLM を起動して同じ問題を解けばいいのでは?」という論理は、オープンソースそのものにも当てはまる
ロボットが直接書いてくれるのに、なぜ他人のプロジェクトを使うのか?
特にそのオープンソースプロジェクトが vibe coded ならなおさらだ
AI と技術全般は、個人化を安価かつ容易にする
以前は、みんながそこそこ満足できる量産品を使うしかなかったが、今は自分だけにとって優れた何かを得られる希望がある
また、多くの人があちこちで LLM を使ってオープンソースプロジェクトを作り直すようになり、労働経済も刺激される
LLM はそういうものを数分で吐き出せる
自分が最も欲しいのは使用実績だ
自分より前に他の人たちが使ったソフトウェアを使いたいし、その人たちがバグや尖った部分に遭遇して磨き上げていてほしい
家でモデルをダウンロードして出力し、無限にカスタマイズできるのに、誰が物を買うのかという話だった
文明がある理由は、人生の大半を誰か別の人の問題として引き受けてもらい、自分は一つのことをうまくやるのに集中できるからだ
歯科医であれ muffler shop の経営者であれ、一日の時間は限られており、おそらく vibecoding を学んで奇妙で手のかかる部下を監督するより SaaS vendor に金を払いたいだろう
例外はあるが、あくまで例外だ
vendor が合理的で有能な製品を作るなら、喜んで金を払う
オープンソースも同じだ
LLM がゼロから新しいオペレーティングシステムを安定して作れるとしても、自分は本当にそれを望むだろうか?
OS を保守したくないし、OS を保守する誰かを管理したくもないし、そもそも自分が OS について一貫したビジョンを持っているとも思わない
ある程度の複雑さを超えると、ロボットが自分の意図を十分に読み取って「自分だけにとって優れた」高品質な結果を返してくれると期待するのは難しい
Zig プロジェクトは明らかにその能力範囲をはるかに超えている
費用を負担しにくい人もいるし、アクセス権があっても Claude の障害や、時間が経つにつれて全体的な性能が落ちるような問題が時々、あるいは継続的にある
数か月前に Claude を使い始めたばかりの頃は、1 週間のうちに複数のプロジェクトで簡単に前進できたが、今ではたいてい spinner しか見えず、コード品質も急落したように感じていて、ほとんど何もできない
star が 100 個ほどのリポジトリをいくつか持っていて、大したものではないが、去年までは時々 PR を受け取っていたのに、今年はこれまでほとんどない
自分の仮説では、LLM は mainstream なプロジェクトに寄り添う傾向がある
多くの開発者が今では LLM に大きく依存していて、自分が提供しているものの大半を無視する方向に bias がかかっている
LLM でwheel reinventionが増える理由も、新しく作るコストが安くなったからだ
そのため GitHub の obscure なもの、たとえば自分のようなものを使うより、必要なものをその場で生成する方が簡単になっている
自分の dependency 選択でも同じ現象を見ている
よほど良い理由がない限り、LLM が勧めるものをそのまま選ぶ傾向がある
ある程度は同意するが、完全には同意しない
貢献者を育てることが正しい優先順位だというのはその通りだ
ただ、AI は支援技術だと考えている
screen reader や magnifying glass に似ているが、もちろん違う点も多い
ロボット外骨格のようなものと考えられる
悪いことや愚かなことにも使われるだろうが、本来できなかった人が良いことをしたり、より有能になったりするのを助けるためにも使われるはずだ
ある人にとっては AI が以前はできなかったコーディングを可能にし、多くの人にとっては AI のやることを見ながらコーディングを学ぶ手段になり、別の人にとってはずっと速く、あるいはもっと上手にコーディングできるようにしてくれる
一部の人にとっては、特定の技能が退化する代わりに別の技能が発達することもあるだろう
外骨格も、まともな製品が市場に出れば同じ問題はあるだろうが、全体としては可能にする道具になる
支援技術を使う貢献者を育てることが、そうでない貢献者を育てることよりなぜ悪いのかわからない
もちろん、より難しくはあるかもしれない
LLM vendor たちが主張したほどLLM は賢くない
本当にそうなら完全自律になっているはずで、こんな会話はしていないだろう
LLM 生成コードを盲目的に提出したり、使った事実を明かさなかったりする人たちは、本当にやめるべきだ
残る問題は、やはり道具だという点だ
任意の開発者に「one-shot PR で Zig を速くしろ」と言っても、良い結果にはならない
以前の OSS プロジェクトは、working code を作れなければならなかったため自己選別が働いており、そこまで来ると数年学んできたおかげで、たいてい正しいことをしていて、機能や必要性についてそれなりの reasoning もあった
今日の LLM が完璧で reasoning が優れていたとしても、結局は prompter の指示を実行する
もはや自己選別が消えてしまったのだ
Zig 開発者たちにとって、何が LLM の作ったコードで何が人間の作ったコードかを実際に判断するのも難しいだろう
すでに LLM 生成コードが入り込んでいる可能性はあるが、少なくともそうした人間の提出者は、なおコードをかなりうまく扱えなければならない
最終的に「信頼の badge of honor を持つ人間だけが commit 可能」へ向かうのか、それとも「LLM が十分に reasoning して『いや、失せろ。この機能・計画・アイデアはゴミだから作らない』と言う」水準になるのか、気になる
そうしたときにきちんと痛い目を見せる方法がないなら、何が彼らを止めるのかわからない