GHCへのAI貢献

GHCへのAI貢献

貢献者ができること、開示しなければならないこと、そしてなぜこのポリシーが合理的だと考えるのか。

GHCはLLM支援による貢献に関する具体的なポリシーを策定しました。10月中旬までには、メンテナーは既にレビューの議論で直接参照していました。Julian Ospaldは「AIポリシー」のP3を引用し、Andreas KlebingerはLLM生成のバグ修正を「問題ない、ポリシー通りだ」と説明しました。

GHC wikiページ自体は今年の夏の議論より前から存在していたため、URLだけでは何が変わったかは分かりません。現在のテキストがそれを物語っています。

このポリシーは、7月に提案された「共有声明」ではなく、Simon Peyton Jonesがghc-devsの議論を通じて開発した文書に従っています。その声明の著者は、それが貢献ポリシーに取って代わるものではないと明確に述べており、Teo Camarasuはそれをポリシーとして扱うことに反対しました。

議論の過程で構造が変更されました。7月27日には、ドラフトは3つのポリシーポイントと1つの推奨事項として要約されていました：マージリクエストをレビューしやすくする、貢献に対して全責任を負う、直接的なLLMの使用を開示する、そして可能であれば最終版を自分で書くこと。現在の文書には4つのポリシーポイントと1つの強い推奨事項があります。「人々とコミュニティを優先する」がP1となり、以前のポイントはP2～P4に移動し、最終版を自分で書くことはP5として残され、要件ではなく推奨事項のままです。

私たちはこの議論に直接的な利害関係を持っています。Vladislav ZavialovとAndrei BorzenkovはSerokellでGHCに取り組んでおり、Andreiはポリシー議論に参加しました。コーディングアシスタントも、私たち自身のエンジニアリングワークフローの一部となっています。

GHCにとって、実用的な問題はレビュアーのコストです。ツール支援による作業は、メンテナーが貢献者の代わりに思考する作業をしない場合にのみ有用です。

GHCには現在、6,500件以上の未解決チケットがあります。中には難しいコンパイラの問題もあります。その他はルーチンですが有用なものです：古いレポートの再現、テストケースの縮小、欠けているベンチマークの追加、またはバグがまだ存在するかどうかの確認です。

ポリシーの内容

このポリシーは、LLMが全体として良いか悪いかについての立場を取りません。プロジェクトにはそのコストとメリットについてコンセンサスがないと明示されています。代わりに、貢献とレビューに対する期待を定義しています。

4つのポリシーポイントと1つの強い推奨事項があります。

P1: 人々とコミュニティを優先する。 貢献者はLLMを使用できますが、レビュアーとの直接の議論は人間であることが期待されます。生成されたテキストは、貢献者自身の判断の代わりとして伝えられるべきではありません。コードベースのナビゲーション、テキストの翻訳、問題の調査のためにLLMを使用することは許可されていますが、ツールはオープンソースプロジェクトが貢献者とメンテナーを育成する会話に取って代わるべきではありません。

P2: マージリクエストをレビューしやすくする。 貢献者は、レビュアーが理解するのに必要な労力よりも、大幅に多くの労力を貢献に費やすことが期待されます。MRは明確な目標、説明された設計、有用な例とテストを持ち、消化しやすいチャンクに分割されるべきです。コンパイルはされるが、レビュアーに推論の再構築をさせるような生成されたパッチは、この基準を満たしません。

P3: 人間の作者と全責任。 全ての貢献には、提出されたコードとドキュメントの各行を理解し、説明できる、識別可能な人間の作者が必要です。生成された素材は、貢献者がそれを注意深くレビューし、責任を負える場合に許可されます。チケットはより緩やかに扱われます。なぜなら、有用なバグレポートは、根本的なコンパイラ障害を理解していない人から来る可能性があるからです。ドラフトMRも、ドラフトであることが明確にマークされ、まだメンテナーにレビューを求めていない場合は、未完成または生成された作業を含むことができます。

P4: 直接的なLLM生成を開示する。 LLMがコード、ドキュメント、テスト、またはレビューに提出されたその他の素材のいかなる部分を生成した場合、その使用を開示する必要があります。貢献者はプロンプトを公開したり、全てのやり取りを説明したりする必要はありません。探求、デバッグ、または設計アイデアのためのプライベートな使用は開示を必要としませんが、ポリシーはそれを奨励しています。提出された素材については、宣言は課題またはMRの説明、およびコミットメッセージ（通常はAssisted-By:行付き）に表示されるべきです。

P5: 可能であれば最終版を自分で書く。 生成されたコードは引き続き許可されます。文書は、最終版を書き直すことが、貢献者が全ての行を考え抜き、パッチを小さく保ち、不要な文章を削除する最も簡単な方法であることが多いと主張しています。GHCのNoteは、数年後に重要となる可能性のあるアーキテクチャ上の推論を保持するため、特に注意が払われています。生成された素材は、レビューおよび改訂されてP3を満たすように密接に作業された場合、引き続き提出できます。

LLM支援によるレビューも同様のルールに従います。文書は、将来同じ役割を果たすエージェントを含む、将来のシステムを広くカバーするように「LLM」を使用しています。

ドラフトからの変更点

最終ポリシーは、Simonのドラフトの中心的な位置を維持しています：支援された貢献は許可され、直接生成は開示され、責任は人間の貢献者に残ります。

主な構造変更は、コミュニティが独自のポリシーポイントになったことです。7月のドラフトでは既に人間の会話と貢献者コミュニティの健全性について議論されていましたが、現在の文書ではその懸念がP1に昇格し、その下の運用ルールが再番号付けされています。

最終版を自分で書くという推奨事項も維持されました。一部の参加者は、これを緩和すべきだと議論しました。最終的なテキストは強い言葉遣いを維持していますが、境界線を明確にしています：P5は推奨事項です。貢献は、人間の貢献者が全ての文字を入力したかどうかではなく、ポリシーポイントの下で評価されます。

したがって、このポリシーはLLMに関するより広範な議論を解決しようとはしません。貢献がレビュー時間の消費準備ができた条件を定義しています。

レビューは希少なリソース

メンテナーの時間こそが主な制約です。

GHCには既に、レビューできる人よりも多くの作業が待っています。パッチ生成が安価になっても、レビューがより高価になればあまり助けになりません。20分で生成されたパッチでも、メンテナーが理解するのに2時間かかる可能性があります。

LLVMはこれを抽出型貢献と呼んでいます。Nadia EghbalのWorking in Publicからのアイデアを借りています：貢献者は何かを提出することの利益を受け取りますが、プロジェクトはレビューと統合により多くの労力を費やします。これは貢献の価値以上です。

この問題はLLMより前から存在していました。誰でも、ほとんど理解していない2,000行のパッチを提出できました。それを生成することが、今でははるかに容易になりました。

商用開発でも同様のパターンが見られます。Farosは、AIの採用が多いチームほど、プルリクエストの数とサイズが増加し、レビュー時間も増加したことを発見しました。データは観察的なものであり、企業のエンジニアリング組織はGHCと直接比較できませんが、ボトルネックは同じです：コード生成は開発プロセスの一部に過ぎません。

GHCのレビューは、プロジェクトの履歴にも大きく依存します。パッチは単独では正しく見えるかもしれませんが、4年前の提案と矛盾したり、古いパフォーマンス回帰を再導入したり、計画されたコンパイラ変更を困難にしたりする可能性があります。人間が周囲の履歴を十分に知らない場合、全く同じ間違いを犯す可能性があります。LLMは、 plausibilityのあるものを生成できるようになる前に、必要なコンテキストの量を主に削減します。

メンテナンスも同様にコンテキストへの依存性があります。マージから6ヶ月後、重要な質問は、誰かがその行が存在する理由を理解しているかどうかです。

新しいメンテナーの育成はどうなるのか？

オープンソースへの貢献は、将来のメンテナーを育成する役割も果たします。

小さな課題は、貢献者がそれらを乗り越える必要があるという点で有用です。レビュアーは、明白な解決策がなぜ失敗するのかを説明し、貢献者はシステムの別の部分を学び、十分な反復の後には他の人の作業をレビューできるようになるかもしれません。

Loris Croは、Zigのポリシーの説明でこれをコントリビューターポーカーと呼んでいます。メンテナーの時間は投資であり、Zigはそれをプロジェクトに長く留まる可能性のある人々、LLMで安価に生成されたドライブバイパッチではなく、そちらに費やすことを好みます。

LLVMは、同じ立場のより狭いバージョンを取っています。そのポリシーは、プロジェクトへの導入を目的としているため、AIツールがgood first issueタスクを解決することを許可していません。

生成されたパッチが他の貢献者を排除したり、レビュアーの注意の大部分を消費したりする場合、これは実際の問題となります。私たちは今日、GHCでその兆候をあまり見ていません。プロジェクトにはレビュアー不足がありますが、低品質なLLM提出物が、同じチケットを競合する多数の人間の貢献者と争っているような状況ではありません。

状況が変われば、ポリシーを強化できます。現時点では、包括的な禁止は、まだ大規模には見られない問題に向けられたものになります。

禁止は施行が難しい

OpenJDKはより厳格なルートを取りました。その暫定AIポリシーは、LLMによって全体または一部が生成された貢献素材を除外していますが、コードの理解、研究、デバッグ、レビューのためのプライベートな使用は許可しています。

OpenJDKは、施行の問題も認識しています：生成されたコンテンツと人間が書いたコンテンツを確実に区別することは、一般的に不可能です。

それでも、そのルールは目的を果たすことができます。プロジェクトは明確な規範を望むかもしれませんし、法的および出所の懸念からより厳格な境界線を正当化するかもしれません。実用的なインセンティブはそれほど整然としていません：モデルの使用を開示できる貢献者は即座に拒否される可能性がありますが、同じツールをプライベートに使用して何も言わない別の貢献者は、区別がつかないかもしれません。

GHCは異なるルートを取ります。開示はレビュアーにコンテキストを与えますが、貢献を自動的に失格させるわけではありません。

他のプロジェクトも異なる選択をしています。GCCは、生成された素材を含む、または派生した法的に重要な貢献を拒否しますが、調査とレビューのためのAIの使用は許可しています。LLVMは、人間が結果をチェックし、責任を負う場合に支援された貢献を受け入れます。GraalVMは、提出者が変更を十分に理解し、その後メンテナンスできることを期待しています。

Linuxカーネルには、コーディングアシスタント向けの明示的なガイダンスがあります。AI支援による貢献は許可されています。人間の貢献者はコードをレビューし、それに責任を負い、DCOを証明します。支援はAssisted-by:タグで記録されます。

関数型言語プロジェクトも意見が分かれています。OCamlは条件付きでAI支援による貢献を許可し、貢献の大部分が生成された場合は開示を求めています。ClojureはLLM生成コードを拒否しています。Agdaは生成された貢献の包括的な禁止について議論しましたが、その提案は採用されずに閉じられました。

GHCにはコピーすべき確立されたコミュニティ標準がありませんでした。

より厳格な立場のいくつかは、法的懸念によって推進されています。GCCは、FSFのライセンス主張が明確な出所に依存するため、「法的に重要な」貢献の線引きをしています。OpenJDKも、貢献素材の所有権に関する貢献者契約の要件に言及しています。GHCの議論は8月に同じ問題に達し、ある貢献者がHaskell Foundationに、モデルプロバイダーからのコンテンツ権利放棄が有効かどうかについての法的アドバイスを資金提供するよう依頼しました。理事会は、その質問はHaskell固有ではなく、まだ裁判で十分にテストされていないとして、これを拒否しました。

著作権譲渡または貢献者契約を持つプロジェクトは、ここでより保守的になる強い理由があります。GHCは異なるライセンスモデルを使用しており、異なるバランスを選択しています。

ポリシーも時代と共に古くなる

モデルの現在の品質に密接に関連するルールは、すぐに時代遅れになる可能性があります。

QEMUは有用な例です。公開されているポリシーは依然としてAI生成貢献を拒否していますが、Paolo Bonziniは代替案に取り組んでいます。5月には、LLMの出力が大幅な書き直しなしではほとんど役に立たなかった頃は、禁止が正当化しやすかったと主張しました。9月までに、その提案は、リポジトリ内で動作するAIエージェントの指示を含む、より広範なポリシーに拡大されました。

代替案はまだ議論中ですが、議論の範囲は変化しています。問題は、生成された作業を排除すべきかどうかだけではなくなりました。それは、リポジトリ内でエージェントがどのように振る舞うべきかについてもカバーしています。

curlはさらに速いシフトを経験しました。2026年1月末、プロジェクトはメンテナーが低品質なセキュリティレポート（多くはAIの使用に関連していた）に圧倒されたため、バグバウンティを終了しました。歴史的に、レポートの15%以上が確認された脆弱性につながっていましたが、その割合は5%を下回っていました。

curlは3月にHackerOneに戻りました。バウンティが再開されたからではなく、HackerOneがGitHubよりもセキュリティレポートを処理するのに適した場所だったからです。4月22日、Daniel Stenbergは「より高いボリューム、より高い品質」と題した記事で、ほぼ全ての受信したセキュリティレポートが何らかの形でAIに関与しているようだが、低品質なゴミはもはや主な問題ではないと書いています。確認された脆弱性の割合は、約15～16%に戻りました。

約2ヶ月以内に、AI支援レポートはバウンティを閉じる決定に寄与したものから、プロジェクトの歴史的な標準に非常に近い品質レベルに達するものへと変化しました。より良いモデルとそれらのモデルのより良い使用を分離することはできませんが、その区別はポリシーにとってあまり重要ではありません。入力品質は急速に変化しました。

現在のツールが悪い出力を生成するという主張に基づいたルールは、頻繁な改訂が必要になるでしょう。

広範な制限には機会費用もあります。Bunは独自のZigコンパイラフォークを維持しており、並列セマンティック分析とLLVMコード生成の複数のユニットへの分割後、デバッグコンパイル時間の大きな改善を報告しました。チームは、ZigがLLM作成の貢献を禁止しているため、その作業をアップストリームにマージする予定はないと述べています。

重要な注意点があります。Zigのコア開発者は後に、Bunの実装における技術的な問題、特に並列セマンティック分析に関連する決定論的でない動作を指摘しました。それはZigがAIなしで書かれた場合に受け入れるであろう洗練されたパッチではありませんでした。

それでも、Zigのポリシーは、その実装を通常のアップストリームレビュープロセスから現在の形では除外しています。アイデアの一部はレビューを生き残るかもしれませんが、何も生き残らないかもしれません。Zigはそのコストを受け入れています。GHCは異なる選択をしました。

スピードはここではあまり参考にならない

コーディングアシスタントの議論は、しばしば生産性をパーセンテージに還元します：20%高速、タスクの2倍の量、いくつかの追加プルリクエスト。

これらの測定値は、コンパイラ作業においては解釈が困難です。最初の試みがその問題について知っていることを変えるため、同じ問題を同一の条件下で2回解決することはできません。実装に時間が半分かかったとしても、レビューコストや3年間のメンテナンスについてはほとんど何も語りません。

GHCのバックログにとって、そのタスクがそもそも完了したかどうかを問う方が有用な場合が多いです。

古いバグレポートを考えてみましょう。誰かがそれを現在のGHCで再現し、それがもはや発生しないことを発見し、それを修正した変更を見つけ、履歴を接続し、チケットを閉じる必要があります。または、500行のレプリデューサーを、別のコンパイラエンジニアが推論できるものに縮小します。

GHCにはこの種の作業が豊富にあります。それは重要ですが、貢献者を安定して引き付けるものではありません。アシスタントが誰かをそれに午後を費やす気にさせるなら、結果に添付できるきれいな生産性パーセンテージがなくても、それは有用です。

一部の問題は、バックログのクリーンアップよりもはるかに困難です。GHCには最近の例があり、モデル支援が、既に数人の経験豊富なコンパイラエンジニアが取り組んでいた問題に入り込みました。

Coercion Zapping

型レベル計算が多いプログラムでは、GHCのCore表現におけるcoercionが膨大になり、コンパイラパフォーマンスが著しく低下する可能性があります。Ben Gamari、Adam Gundry、Sam Derbyshire、Richard Eisenbergは既にいくつかの方法を検討していました。一部は特定のケースに役立ちましたが、他のケースでは回帰を引き起こしました。

7月、Sylvain HenryはClaude Fableを使用した概念実証を作成しました。Well-Typedレポートでは、これをいくつかの以前の試みのアイデアを組み合わせたものと説明しています。新しい要素の1つは、coercion変数の間の依存関係をミュータブル変数で追跡することでした。これにより、zappingされるcoercion自体が強制される必要がなくなりました。

その後、Sam Derbyshireは実装を一から書き直し、調査を続け、GHCの型ファミリーリライターでさらなる最適化を見つけました。

モデルは研究問題を独立して解決したわけではありません。問題の定義、以前の試み、そして結果を評価するために必要な判断は、コンパイラを知っているエンジニアから来ました。概念実証は、以前のアプローチが停滞していた問題に対する別のルートを提供しました。

よりルーチンな例もあります。Simon Jakobiは、Assisted-by: Claude Fable 5やAssisted-by: Claude Fable 5.1のようなトレーラー付きのGHCパッチを送信しています。これらは通常のコンパイラおよびテストスイートの変更であり、他のパッチと同様にレビューされます。

AI支援はパッチの外にも現れています。最近、停滞しているGHC計画のステータスについて尋ねられた際、Simon Peyton Jonesは、サイクル不足で停滞していると述べました。彼はバグレポートに埋もれていましたが、その多くはAI生成でしたが、ほぼ全てが正確でした。ここでは、モデルはコードジェネレーターというよりは、テストまたは分析ツールに近いものです。レポートは、同じ少数のメンテナーが読み、対応する必要があります。

私たち自身の経験はまだ限られています。Serokellによるvisible forall、RequiredTypeArguments、名前空間指定インポート、および依存型へのより広範なパスへの取り組みは、現在使用しているコーディングアシスタントワークフローよりも前のものです。古い難しいパッチを見て、現在のモデルがそれを生成できたかどうかを尋ねても、あまり多くのことは分かりません。

したがって、AIがコンパイラ開発を変えるという証拠として、私たち自身のGHC作業を使用することはありません。まだ十分な経験がありません。

私たちの見解

現在のポリシーは合理的だと考えます。

GHCには6,500件以上の未解決チケットがあり、メンテナーの時間は限られており、十分なボランティアを引き付けられない有用な作業が大量にあります。コーディングアシスタントがこのバックログを解決することはありません。禁止も根本的な不足を解決しません。

貢献に対するハードルは、現状維持されるべきです。貢献者は、その設計を説明し、レビュー担当者を説得してGHCに含める価値があると思わせるのに十分なほどパッチを理解する必要があります。モデルの使用によって、その責任がレビュアーに移ることはありません。

このポリシーは、メンテナーが不十分な支援作業を拒否するための十分な余地を残しています。説明できない人物からの大きなパッチは悪い貢献です。それが記述されている不変条件を理解していない作者による洗練されたNoteも同様です。古いバグの再現、テストケースの縮小、ベンチマークの構築、またはコンパイラの問題の調査のためにモデルを使用することは異なります。ツール自体が結果の作業をそれほど有用でなくすることはありません。

標準は通常通りです：貢献者は作業を理解し、パッチはレビュー可能であり、変更はメンテナンスの負債を削除する以上のものを追加せずにGHCを改善します。