依存関係でのLLM生成コードを禁止
(joeyh.name)- git-annexは、LLM生成コードを含む依存関係なしでビルドできるよう、この1か月で約100時間をかけて点検された
- この作業は、個々のコードではなく依存関係ツリー全体を継続的に追跡しなければならない現実を浮き彫りにし、保守負担を大きく増やしている
- 点検中には、大規模なLLM生成変更の無説明での差し戻し、26,000 LOCのコードベースに対する10,000行の変更、1,489行に及ぶ一貫性のないコミットメッセージといった事例が確認された
- 依存関係の品質情報を追加で得られた点は前向きだが、Software Freedom ConservancyやFSFのような組織レベルの対応には懐疑的な見方が残っている
- LLMで設定追加やフォーマット変更を簡単に作れても、そのようなコミットは協業の信頼やプロジェクト参加に直接的なコストを生み得る
git-annexの依存関係点検
- git-annexは、LLM生成コードを含む依存関係なしでビルドできるよう、約1か月にわたり約100時間を投じて点検した
- 現時点では目標を達成しているように見える
- 関連ページとして git-annex no LLM code がある
- 問題の核心は、プログラムの依存関係ツリー全体を継続的にレビューしなければならない負担にある
点検中に明らかになった事例と影響
- 確認された事例は、単なる好みの問題ではなく、保守性と信頼の問題につながっている
- 大規模なLLM生成変更が、次のリリースで何の説明もなく差し戻された
- 26,000 LOCのコードベースに10,000行の変更が入り、コミットメッセージは1,489行にわたる一貫性のない内容だった
- 別のプロジェクトからコードをコピーするよう求めるLLMプロンプトがあり、幸運にも著作権侵害は避けられたように見えた
- 今回の作業により、依存関係の品質について追加の情報が得られ、この情報は今後の選択に影響し得る
- Software Freedom Conservancyは、LLMベースの生成AI勧告でこの問題を見過ごしているように見え、FSFがよりうまく対応できるかも不透明である
- こうした変化の中で、関連コミュニティへの参加を見直しているが、作業とユーザー支援は継続している
- LLMに
Add fourmolu config and restyled、neat、format a moduleのようなプロンプトを与え、その結果をコミットするやり方は簡単に見えるかもしれないが、その行動の広範な影響を考慮する必要がある
1件のコメント
Lobste.rsのコメント
今日知ったのだが、git-annex がHaskellで書かれているのは格好いい
今日、帰りの地下鉄で隣の人がYouTube Shortsを最大音量で見ていて、静かで混み合った車内では騒音公害で腹が立った
さらに腹立たしかったのは、その人が見ていた動画が完全にAI生成の低品質動画だったこと
この記事で、依存先の作者たちがLLMで理解しにくい変更を作っているという逸話は刺さった
LLMの誤用でいちばんもどかしいのは、人同士のやり取りを壊してしまうところにある
以前は、会社で粗い考えの提案をレビューしても、核となるアイデアがそのまま見えていたので拾い上げてコメントしやすかったが、今では誰でも粗い変更をLLMに入れて、一見よくまとまっているようで、レビューすると穴だらけの成果物にできてしまう
同じように、一見よさそうに見える悪いコードも作れてしまう
新しい不満ではないが、だんだん神経に触るようになってきた
仕事や生活を楽しく充実したものにしていた人間的なつながりの中核の一部を失いつつある感じがする
同僚が「これは 🤖 がやった」と正直に教えてくれるので、どの程度のレビューを期待しているのか事前に分かってありがたい
たいていはコードベースをもっと学ぶために使った過程の記録なので、同僚がLLMの出力を読んでおり、ちゃんと学べたか確認してもらいたいのだと信じられる
LLMが変えたのは品質の相対価格だと思う
家にたとえると、以前は屋根が雨漏りし、基礎も悪いひどいMcMansionが1000Xで、隠れた厄介事のない良い家が2000Xだった
今ではLLM技術により、熟練者が機械的で検証しやすい作業の一部を任せることで、良い家の価格を理論上1500Xまで下げられる
ところが、ひどいMcMansionは100Xまで下がった
そのため、低品質なMcMansionが良質な仕事を醜いやり方で押しのける可能性が高い
良い家を2000Xから1500Xに下げる職人たちを責めるつもりはないが、100Xの粗悪な家がより良いものを市場から押し出してレモン市場を作ると、顧客はソフトウェア全般をはるかに疑うようになるかもしれない
買い手が品質の良し悪しを見分ける方法がないという点で、レモン市場は見苦しい
ソフトウェアで最も有名な例は1983年のビデオゲーム大暴落で、大量のゴミのようなゲームに多くの顧客が痛い目に遭い、購入をやめた事件だ
この立場は十分に合理的だと思う
個人的には、時間が経てば大半は無駄骨になる気がするし、自分がソフトウェアを使う上ではあまり気にしていないが、主観的な観点としては十分に妥当で興味深く、この人がこうしているのも良いことだと思う
AI楽観論者が誇張するのと同じように、反AI側も否定的な側面を過度にドラマチックに語りがちだ
この記事自体は例外に近いが、最後の段落の性急な一般化を除けば、全体の意図とメッセージはずっと強くなったと思う
それでも、こういう文章を読んで感情の中から興味深い部分を探すのは好きだ
プロジェクトごとの最後に確認された100%非LLMコードのデータベースがあれば面白そうだ
影響のあるスロップのデータベースも面白そうで、ここで「影響のある」は肯定・否定の両方、「スロップ」はレビューされていない出力という意味が重要だ
ざっくり2023年初めのGitHubアーカイブを取ってくるような形でごまかすこともできるだろうが、単なる特定時点のスナップショットではなく、プロジェクトごとの最後のコミットのスナップショットならもっと面白いはずだ
このデータセットから出そうな興味深い結果は多そうだし、この記事のように非LLMソフトウェアだけでエコシステムを作りたい人たちにも役立つ
すでに想像はつくだろうが、私はLLMユーザーだ
それでも合理的な側だと思っている
興味があれば私のウェブサイトの記事を読んでもよいが、ブログ記事の本文は100%人間が書いたと約束する
反対意見を読むことは学び成長する最良の方法の一つだと思っているので、こうした試みに参加するのは好きだ
熱心な反AI寄りの人たちが運営する https://codeberg.org/ethical-foss/open-slopware だ
いくつかのプロジェクトには「最後の汚染されていないバージョンまたはコミットID」があるが、すべてのプロジェクトを網羅しているわけではない
この記事を投稿した理由は、著者が依存先でLLM使用を示唆する特定のコミットを自分で探し、発見内容をまとめたページを作っていた点が良かったからだ
個人的には、この記事はバイブコーディングというよりコミュニティと慣行に関する内容なので、
vibecodingタグを付けるべきかは確信がなかった「この時点では押し寄せる潮流を止めようとしているだけかもしれないことは分かっている」というくだりがある
プロジェクトが依存しているコンパイラが影響を受けたら勝てない
私も被害の抑制はしているが、結局は代替手段にこだわるほうがもっと悪くなり、譲らざるを得ない瞬間が来る
難しい問題だ
どれほどよく分析しても、LLMコードを避けるのは難しい可能性が高い
たとえばコード補完で入ったコードは検出できない
信頼が壊れた時点は、これらのライブラリがLLMを使い始めたときではなく、巨大な変更を受け入れて統合し、読みづらく役に立たないコミットメッセージを付けたときだと思う
これはLLM使用の有無とは別のソフトウェア工学上の失敗だ
ちなみにJoey Hessと彼のソフトウェアは好きだし、コード貢献はどんなツールで作られたかに関係なく、成果物の良さで評価すべきだという立場だ
説明の仕方が少し残念だ
persistentのコミットはLLMが書いたものではなさそうだ「Co-authored-by」が付いたすべてのコミットをLLM生成だと言わないでほしい
最初の
yesodリンクはCI変更なので、依存しているコードとは見なしにくいと思う「1489行のコミットメッセージが付いたLLM生成コミット」とあったので、コミット自体がひどい状態なのかと思ったが、実際には妥当なスカッシュマージで、ただ差分がものすごく大きいだけだ
cabalのコミットはLLMがテストだけを生成したとされていて、それも自分が依存するコードと見るべきなのかは疑問だgitのコミットも単なるCIだこれらの依存先の一部がLLMを使っていることは疑っていないが、提示された根拠が十分に持ちこたえているとは言いにくい
一方で、期待よりはるかに多くの手間がかかった作業であり、どの依存先を使わないかの具体的な理由として指し示せるものがある点は良い