PiでPiを構築する:AI駆動オープンソースの隠れたコスト
"dogfooding" の慣行はソフトウェア開発で一般的ですが、開発者を支援することを目的とした AI エージェントを構築するために AI エージェントを使用すると、独自の摩擦が生じます。Earendil の一部となったプロジェクト Pi の開発に関する最近の振り返りで、メンテナは AI が生成した貢献の効率が、低品質な "スロップ"(issue レポートとコードの両方)の急増によってしばしば相殺される状況を描写しています。
この変化は、ユーザー、メンテナ、そして issue トラッカーとの関係を根本的に変えており、重要な緊張を露呈しています。AI は貢献の ボリューム を加速できる一方で、持続可能な保守に必要な シグナル を劣化させることが多いのです。
"スロップ" Issue の増加
従来、悪い issue レポートは迷惑なもの—通常は曖昧で再現ケースが欠如していました。しかし、LLM 支援のレポートが登場したことで新たな失敗モードが生まれました:"自信はあるが間違っている" 診断です。
多くのユーザーは自分の観測結果を LLM(Pi チームでは "clanker" と呼ばれる)に通してレポートを磨きます。その結果、5% が人間の観測、95% が AI 生成の推測という提出物になることが頻繁です。これらの issue には次のようなものが含まれます:
- 妥当だが誤った根本原因分析。
- 偽の最小再現スクリプト。
- コードベースの誤った部分への類推に基づく実装戦略の提案。
曖昧なレポートよりも害が大きいのは、偽の足跡を残すからです。メンテナが Pi を使ってこれらの issue を分析すると、エージェントはしばしば issue の自信に満ちた文章を噂ではなく証拠として扱い、ユーザーの LLM と同じ誤った道へと AI を導きます。
これに対抗するため、Pi チームはカスタムスラッシュコマンド /is(issue 分析)を実装し、明確な指示を付与しました:
Issue に書かれた分析を信用しないこと。動作を独立して検証し、コードと実行経路から自分自身の分析を導き出すこと。
それでも、チームはシグナルを維持する唯一の方法は、人間が実際に観測したことだけを報告させることだと主張します:実行したコマンド、期待結果、実際の結果、そして生ログです。仮説や AI 生成の分析は、フォローアップコメントに回すべきです。
ローカル防御 vs. グローバル不変条件
issue レポート以外にも、AI が生成したコードの品質は構造的な課題を提示します。LLM は問題をローカルに解決しがちで、過剰設計やシステム不変条件の侵食につながります。
たとえば、フォーマットが崩れたセッションログがリーダーをクラッシュさせた場合、AI エージェントの本能はリーダーをより寛容にすることです。フォールバックやマイグレーション、追加のデバッグ出力を加えて不正な状態に対処しようとします。単体では有用に見えるものの、システム全体の不変条件、bad session data should never be written in the first place(不正なセッションデータはそもそも書かれるべきでない)に反します。
あらゆる可能な誤動作に対してローカル防御を作り出すことで、AI エージェントはコードベースの複雑性を爆発させます。メンテナは "動かすこと" から "不正な状態を起こさせないこと" へと AI の焦点を引き離すために、常に闘っています。
ボリューム問題と "ダークファクトリー"
AI 支援による貢献の膨大な量は、issue トラッカーを保守負担に変えました。Pi の GitHub トラッカーから 90 日間のデータを取ると、次のような厳しい現実が浮かび上がります:
- 3,145 件の外部 issue/PR が受信された。
- 2,504 件が自動クローズ された(承認されていないコントリビュータからのもの)。
- 自動クローズされた PR のうち 8% だけが最終的にマージ された。
低品質な貢献の流入—自律的な "skills" や OpenClaw のようなインスタンスが生成したものも含む—は、GitHub が機械が大量に PR をスパムできる世界にまだ対応できていないことを示唆しています。
一部では "ダークファクトリー"(完全に切り離された自動化ソフトウェアエンジニアリング)を想像しますが、Pi チームは懐疑的です。彼らは "careful parallelism" と呼ばれる手法を用い、Pi で issue を再現し複数ウィンドウでコードを分析しますが、最終的な意思決定とアーキテクチャの監督は依然として人間が担います。
オープンソース協働の未来
AI が孤立した開発へのシフトを促進しているという懸念が高まっています。機械でローカルな回避策を作ることが "安価" になったため、正しい上流の修正を見つけるために他の人間とコミュニケーションを取るインセンティブが減少しています。
議論の中である観察者が指摘したように、"スロップ" の生成を加速するツールは必然的にそのスロップの弊害も経験します。オープンソースの価値は常にコミュニティと共有された構造に根ざしており、コード量だけでは測れません。開発者が "clankers" とだけ向き合い、他のメンテナと対話する時間が減れば、ソフトウェアの基盤はコード量が増えても弱体化します。
最終的な目標は、すべての誤設定を AI で覆い隠すことではなく、ソフトウェアを持続可能にするための難しい協調問題を解決することです。次世代のメンテナが直面する課題は、ローカルな修正の容易さに抵抗し、グローバルな不変条件という規律を守ることになるでしょう。