- OCamlネイティブコンパイラに DWARF v5デバッグ情報 を追加し、macOSとLinuxで GDB・LLDBによるソースレベルデバッグ をサポートする1万3千行規模の大規模PRが提出された
- 実装内容には 関数・行単位のブレークポイント、引数およびローカル変数の追跡、基本型情報の表示、AMD64・ARM64対応 などが含まれる
- 作成者は、このコードが Claude Sonnet 4.5とChatGPT 5(Codex) などのAIモデルの協業で生成された結果であり、自身はコードを書く代わりに AIを指揮・レビュー したと明かした
- OCamlメンテナは 著作権問題、設計議論の欠如、保守負担、AIコードレビューの難しさ などを理由にマージを拒否し、PRを終了した
- 今回の議論は、AI生成コードの品質・著作権・協業プロセス をめぐるオープンソースコミュニティの新たな課題を浮き彫りにした事例となった
DWARF v5デバッグ対応PRの概要
- PRはOCamlネイティブコンパイラに DWARF v5デバッグ情報 を追加し、GDBとLLDBで ソースレベルデバッグ を可能にする
- 関数名・ファイル・行ごとのブレークポイント設定、変数名の表示、型情報の提供
- AMD64・ARM64 アーキテクチャをサポートし、32ビットプラットフォームは非対応
- macOS(Mach-O)とLinux(ELF)の両方で、セクション相対再配置 を用いた完全なDWARFサポートを実装
- LLDBプラグイン(ocaml_lldb.py) を追加し、OCaml値の出力コマンド(
ocaml print)を提供
- テストは9項目で構成され、機能・型・行デバッグ を検証する
実装の詳細
- DWARF v4からv5へアップグレードし、DW_FORM_string を使ってリンクエラーを防止
- 複数コンパイルユニット(CU) をサポートし、文字列テーブルの重複を除去
- ローカル変数・引数の追跡、レキシカルブロック、基本型情報 をDWARF構造に反映
- Var_lifetime モジュールで変数のライフサイクルを追跡し、fun_var_info フィールドでコンパイルパイプライン全体に変数情報を渡す
- DW_TAG_lexical_block を通じてネストしたスコープを表現
- テストスクリプト はGDB・LLDBでブレークポイントと型表示を検証する
AI生成コードをめぐる論争
- 作成者は「Claude Sonnet 4.5が大半を書き、ChatGPT 5(Codex)がレビューした」と説明
- 自身は「AIを指導しレビューしただけで、1行も直接書いていない」と述べた
- 一部ファイルに Mark Shinwell の名前が著者として含まれており、著作権上の出典をめぐる論争 が発生
- 作成者は別の分析レポートで「OxCaml実装とは構造・命名・型システムが異なり、複製ではない」と主張
メンテナたちの反応
- gasche: 設計議論なしに1万3千行超のコードが提出され、レビュー・保守の負担 が大きいと指摘
- AI作成コードは「レビューがより難しく、法的リスクがある」としてマージ不可を決定
- dra27: 「AIがコードを理解する」という表現を批判し、LLMは理解ではなく パターン生成ツール だと強調
- bluddy と tmcgilchrist: DWARFコードは別ライブラリとして分離すべきで、コンパイラ内部に含めると 保守負担 が増えると述べた
- 議論が過熱すると、PRは 「too heated」状態 としてロックされた
AIとオープンソース協業の争点
- 作成者は「AIが高品質なコードを完成できることを証明しようとした」として、AIベース開発の実験 であることを強調
- メンテナたちは「AI生成コードの品質・著作権・レビュー手順」について明確な方針が欠けていると指摘
- 今回の事例は、AI支援開発がオープンソースプロジェクトに統合される際に必要な手順と基準 をめぐる議論を促した
2件のコメント
しかし……PRを提出した本人は、まったく理解していない。
したがって……本PRは却下する。（バンバンバン）
Hacker Newsの反応
OCamlのメンテナたちは厄介な人への対処に関する特別訓練でも受けているのかと思った
あの忍耐力と成熟ぶりには驚かされる。自分ならTorvalds流に即ブロックしていた気がする
経営陣がAIにほとんど宗教的な信頼を置いていて、すべてのエンジニアにできる限りAIを使ってほしいと思っている
コードレビューまで次第にAIが担うようになっている。ただ、この件で親切だった理由はそれではなさそうだ
たとえばPRを分割させたり、設計提案を出すよう促したりする形で
メンテナたちは優しすぎて、そういう人たちに時間を浪費しているのを見るともどかしい
メンテナたちが感情に流されず、論理と共感で応じる姿はまさに教科書的なコミュニケーションだった
ただ、こうした親切さがかえって幻想を強めてしまわないかは気になる
ある意味でその人はLLM以上に自己認識が欠けているように見えた
AIが作ったコミットの正当性をAIに尋ねるなんて本当にあきれる
それでも少なくとも正直ではあった。「このゴミの山を保守してもいいが、金は払ってもらう」という発言は圧巻だった
そのおかげで自分もOCamlエコシステムに貢献してみたいと思った
「なぜ提出したファイルの著者がMark Shinwellになっているのですか？」という質問に
「AIがそう決めました。私は尋ねませんでした」と答えたのが、すべてを要約している
こうしたAI世代は、最低限の多面的思考すらしていない
著作権表記がなぜ入ったのか聞かれるのは目に見えているのに、答えの準備すらできていなかった
結局レビュー負担はメンテナに押しつけられ、保守責任を投稿者は負わない
この人の履歴書が伝説級だ
ウォール街の銀行を渡り歩き、Deutsche Bankの技術ディレクター、EAへのライセンス販売、
「Hardcore Erlang」の執筆企画、2日で200万ドルの暗号資産調達など
天才か、世紀の大ぼら吹きか、そのどちらかに思える
関連リンク: 以前のブログ, 履歴書PDF, インタビュー, 公式サイト, Erlang本の中止に関する話
AIが生成したコードであっても、コミュニティが時間をかけて対話しフィードバックを返しているのに、
投稿者がAIの書いた長文をそのままコピペするのは即ブロック対象だと思う
スパムボットのように振る舞えば、スパムボットとして扱われて当然だ
私が質問すると返ってくる答えは典型的なGPT口調だった
結局自分で試してみたら、ほぼ語単位で同一の返答が出てきて、
それ以来、彼のコードはレビューしないと宣言した
「これはAIが書いた著作権分析です」と言い出した時点で、もう限界だった
自分ならその時点で即座にリポジトリからブロックしていた
私も複数のオープンソースプロジェクトでAI生成PRをクローズした経験がある
こういう投稿者は、あるプロジェクトで拒否されると別の場所へ移っていく
レビュー負担は増え、本物の貢献者は減っていく
それでも、こうした議論をHNでリアルタイムに見られるのは興味深い
投稿者は論理ではまったく説得されなかった。他のプロジェクトもこうして持ちこたえられるかもしれない
むしろ心配すべきなのは企業向けソフトウェアのほうだ
AI擁護派に聞いてみたい
AIで書いた発表原稿を読み上げたあと質問を受けたら、何と答えるつもりなのか？
今回の状況はまさにそれだ
13k行のPRを理解せずに投げるのは、AIの有無に関係なく間違っている
AIはただの道具であり、CNCマシンを使おうがノコギリを使おうが結果を理解することが重要だ
これまで見たAI生成PRの中で、これは最も異質なケースだった
たいていは初心者が書いた動かないコードだが、今回は複雑で実際に動いていた
投稿者のJoel Reymontは30年の経験を持つ開発者で、2008年からHNアカウントを持つ古参だった
OCamlメンテナたちの忍耐強さは見事で、最終的に彼は人間味のあるコメントで自分の立場をまとめ、
AIでOSSに貢献するのはやめると述べた
それでも、この手のPRは依然として全員にとって時間の無駄であり、
これまで生産的に活用された例は見たことがない
本当に驚くべきPRだった
該当コミットへのリンク