Pop!_OS、コードベースの大部分でAI生成コードを禁止

完全にパフォーマンスだ。

あなたはOSを何千ものオープンソースパッケージの上に構築しているが、その多くにはAI生成コードが含まれている。それらを一つ一つ監査して問題のあるパッケージを削除するのか？OSが修復不能に壊れるために削除しないものはどうする？

私が進行中だったPRがこれのせいでクローズされた。VPN用のネットワークアプレットのパスワードに問題があり、Claudeを使って特定し、修正案を考えるのに使った。品質を確保するために手作業で多くの時間を費やしたが、彼らの決定を尊重し、恨みはない。ただ、オープンソースに貢献する時間と機会を見つけるのに苦労してきた者としては、少し後退した気分だ。

AWSの専門家（元AWS CTO）による同様のトピックのスレッドがここで進行中だ。

「どうやら、AIはすべてのソフトウェア開発チームで肯定的な結果をもたらすわけではないようだ。顧客はチームでのAI導入を遅らせるべきかと私に尋ねている。

どう答えるか？

はい？いいえ？」

https://www.linkedin.com/feed/update/urn:li:activity:7510679...

その一部は学習習慣であり、ツール（AIエージェント）自体の使用に熟達し、その周りのワークフローを改善することだと思うが、AIはまだ完璧ではないということか？

サイバーセキュリティとゼロデイの発見においてlsがますます優れるようになるにつれ、これが攻撃者/防御者のギャップを生き残るとは思えない...しかし、もしかすると十分に obscure で問題にならないのか？

問題は主にコードなのか、それともAIが書いたPRやAIを使ってメンテナーと話す人々なのか疑問だ。個人的には後者をする人は誰でも禁止している。これ以上opusと話したくない笑

OK、これは物議を醸すかもしれないが、LLMのコードトークンは無料ではなく、かなり重いプロジェクトをいくつかやるだけで週の許容量を定期的に使い果たしてしまう。だから、なぜ誰かがわざと悪いPRを出すために自腹を切るのか理解できない。証明されない限り人々の善意を前提にしたい。つまり、これらの大規模オープンソースプロジェクトでLLMが書いたコードをほぼ全面禁止するのは少し極端に思えた。核心的な問題はレビュープロセス/ポリシーが時代に合わせて変わるべきだということのようだった。

例えば、今年初めにオープンソースのゲームエンジンで、2021年頃に遡る長年のテキストレンダリングのバグを手伝っていた。そのバグはエンジンをプロダクション対応にするのを妨げており、コミュニティと私は広範な回避策を開発していた。それである日、ついに我慢の限界に達し、Claudeにデバッグさせた。Claudeは10分でバグを見つけ、レンダラー内の3行のコード変更だった（そう、3行）。

そこで、回帰テストを書き、バグを文書化し、修正のPRを開いた。1週間以内にマージされて先に進めると思っていた。メンテナーはPRをかなり好意的に受け取ったが、PRはほぼ6ヶ月間マージされずに放置され、最終的に上流の悪いsquashでクローズされた。バグはまだそこにあると確信している。

余談だが、誰かが私のGitHubプロジェクトにAIで貢献してくれたら大喜びだ。

「...AIによる貢献の多くは計画されておらず、ソフトウェアアーキテクチャの理解をほとんど示していなかった。そのため、チームは『自分たちのチームと定期的な貢献者からの貢献を優先したい』と考えている。」

熱心なLLMユーザーにも合理的に聞こえるだろう。線を引かねばならない。この線は単純すぎるが、今のところは機能するだろう。