AIスロップはフォークが難しい

プロジェクトのフォークを維持したり、なかなかマージされないプルリクエストを抱えた経験があるなら、こんな状況に心当たりがあるだろう。ある時点で上流が動く。そしてgit rebaseやgit mergeを実行すると、それまで綺麗に孤立していた変更がマージコンフリクトで覆い尽くされる。時にはこれがなんとかなることもある。近くの関数が変わった、ファイルが移動した、誰かが型をリネームした。数分間修正してテストを再実行すれば済む。しかし、それがうまくいかない時もある。

メンテナーがプロジェクト全体を再フォーマットしたり、すべてのモジュールを再編成したり、あなたの変更が依存する内部構造を書き換えたりする。そうなると、あなたのフォークはもはやフォークではなく、考古学プロジェクトになる。そしてこれは昔から痛みを伴うものだった。単純で退屈な作業というだけでなく、リスクも伴う。最初に書いたバージョンは特定の上流の状態に対してテストされていた。周辺のコードを理解しており、おそらく各行に一貫した理由があった。しかし、苦しいリベースを3回繰り返した後、目的は静かに変化する。

もはや元の変更の品質を保とうとはせず、ただコードをコンパイルできるようにし、テストを通すようにし、5つの微妙に異なるファイルで同じ概念的なコンフリクトを解決しながら正気を保とうとするだけだ。そして、もともとなかったバグや脆弱性が混入し、フォークの品質はリベースのたびに低下する。厄介なのは、これが以前は比較的まれだったことだ。大規模で広範囲に及ぶ上流の変更は確かにあったが、それには実際の人間の時間がかかった。メンテナーは大規模なリファクタリングが痛みに値するかどうかを判断し、実際に作業を行わなければならなかった。そのため、ほとんどのプロジェクトには自然な摩擦があった。しかし、AIはその摩擦の多くを取り除く。

安価な実験は有用だが、コミットの形状も変える。バイブコーディングされたプロジェクトでは、コミットが巨大になりがちで、それはパターンになりつつある。プロンプトが多くの表面に触れる差分を生成し、メンテナーは結果を見て、テストを実行し、方向性を気に入ってコミットする。単一コミットで大規模な変更。その差分を生成するコストはごくわずかだが、他の人が統合するコストはそうではない。大規模なAI生成リファクタリングは、エンターキーを押す人にとっては安価でも、ローカルな変更やダウンストリームのパッチセット、長期間放置されたプルリクエストを維持する人にとっては非常に高くつく可能性がある。

プロジェクトは動作を変えただけでなく、形状も変えた。そしてフォークは形状に依存する。フォークはコードのコピーであるだけでなく、どこに何があるか、関数がどのように分割されているか、どの内部境界が安定していてその上に構築できるか、どのファイルが他の部分に影響を与えずに変更できるかという仮定のセットでもある。上流のコミットごとにその形状が再シャッフルされると、フォークはアンカーを失う。これは、重要だがすぐにはマージできない変更にとって特に悪い。メンテナーはアイデアに同意しても別のAPIを望むかもしれない。もっとテストが必要かもしれない。あるデプロイには有用でも上流には特異すぎるかもしれない。プロジェクトは皆が忙しくてレビューが遅いかもしれない。

そして、上流のプロジェクトが常にプロンプトによって書き換えられている場合、まともなマージのための時間枠ははるかに狭くなる。あなたの作業がすぐに取り込まれるか、すぐに腐り始めるかのどちらかだ。ロジックが間違っているからではなく、周囲のコードが別の形状に攪拌されたからだ。しばらくすると、フォークの維持は事実上不可能になる。上流からの更新を停止することもできるが、それはフォークが徐々に独自のプロジェクトになることを意味する。リベースを続けることもできるが、それは無関係なグローバル編集による損傷を修復するためにより多くの時間を費やすことを意味する。あるいは、諦めてAIにゼロから自分自身の競合バージョンを生成させることもできる。

最後の選択肢は最悪だが、まさにインセンティブが向かう方向だ。上流がコードを、気分が変わればいつでもグローバルに再生成できる使い捨てのテキストとして扱うなら、ダウンストリームのユーザーもいつかは同じように上流を扱うだろう。安定した形状を保つことを拒否するもののフォークを丹念に維持するのはなぜか？

意図的な大規模変更と、カジュアルなチャーンには違いがある。人間によるリファクタリングには通常、何らかの傷跡が残る。メンテナーが被害を最小限に抑えようとしているのがわかる。差分には境界がある。コミットメッセージはなぜこれが必要だったのかを説明する。互換性レイヤーが現れる。古いパスはしばらく存続する。レビュアーはこれがダウンストリームユーザーを傷つけるかどうかを尋ねる。AIスロップは自然にそのようなことを気にしない。

それは現在のチェックアウトでプロンプトを満たすことを最適化する。誰かのフォークにどのようなパッチシリーズが存在するかを知らない。小さな関数のリネームが10個のオープンなプルリクエストでコンフリクトを生み出すことを気にしない。他の全員に作業をやり直させるという社会的コストを感じない。フォーク可能性は（かつては？）プロジェクトの品質だった。AIはそれを破壊することをこれまで以上に容易にした。