夢晨発 凹非寺 量子位 | 公式アカウント QbitAI
Microsoftの有名オープンソースプロジェクト.NET Runtimeが「お祭り騒ぎ」の場と化し、世界中のプログラマーがGitHubのコメント欄で集まって嘲笑しています：
MicrosoftはゴミAIでMicrosoftの従業員を苦しめている、これは悲しくもおかしい。
何が起こったのでしょうか？
なんと、新登場のCopilotコードエージェントが自動バグ修正を手伝おうとしたのですが、手伝えば手伝うほど状況を悪化させてしまいました。
バグ自体は正規表現の些細な問題で、Microsoftの従業員スティーブンとCopilotが協力して解決することになっていました。
Copilotは提案の記述において、いかにももっともらしいことを述べ、「一貫性を保証する」「変更は最小限である」などと語っていました。
しかし、結果としてコードは直接チェックを通過せず、長いエラーメッセージが続きました。
結局、このAIが散々頑張った挙げ句の唯一の「貢献」は、タイトルを変更したことだけで、これは「サボりの極意」を覚えたと言えるでしょう。
幸い、それは単なるコード規約の些細な問題だったので、スティーブン氏は気にせず、Copilotにスタイル問題を修正させ、テストを以前のファイルに移動させました。
すぐにCopilotは「スタイル問題を修正し、テストを既存のファイルに移動しました」と報告しました。
スティーブン氏が確認すると、残念ながら多くの正規表現テストが失敗していました。
このPRがプログラマーたちの注目を集め始めたのはここからで、数百人が「笑い」のリアクションをつけました。
AIが引き起こした問題はAI自身で解決しなければなりません。Copilotはエラーの修正を試み、「最初の修正案はアグレッシブすぎた」と結論付けました。
その結果、この先進的なAIエージェントは、より原始的なプログラムBotによって直接「顔を潰されました」：この操作はキャンセルされ、後続のステップには期待されるログが含まれない可能性があります。
これには傍観していたネットユーザーも耐えきれず、「このソリューションの可能性は本当に見た」と皮肉を込めてコメントしました。
人間が動かないコードを書くのに時間を費やすよりも、コンピューター自身に動かないコードを書かせた方が、少なくとも無効なコードを書く効率は上がります。
最終的にこのPRはスティーブン氏によって手動でクローズされました。彼は、設定の問題でエージェントが必要な依存関係にアクセスできなかったためだと考えています。
そして、Microsoftの従業員とCopilotがペアになって、最終的に失敗したPRは…こんなにもたくさんありました。
苦しめられたのはスティーブン氏だけではありません。別の従業員のエリック氏は、手動でPRを閉じ、ブランチを削除した後、振り返るとCopilotがブランチを復活させ、タイトルを変更して再度レビューを依頼してきた、という事態にも遭遇しました。
しかし、すでに閉じられていたので、エリック氏はその後、相手にしませんでした。
AIがバグを修正、直せず、しかも言い訳
別の正規表現に関するPRでは、バグはスタックアンワインド時の配列の境界外アクセスによる例外でした。
Copilotの提示した解決策は、驚くべきことに、境界チェックを追加し、配列の長さを超えた場合に「不一致」を返し、例外をスローしないようにするというものでした。
この解決策はスティーブン氏に「対症療法で根本的な解決ではない」と評価されました。なぜ境界外アクセスが発生するのか、依然として解決されていませんでした。
今回Copilotはすぐに反応せず、スティーブン氏が再度@メンションしてようやく動き出しました。
Copilotは反応しましたが、新しい解決策は提示せず、代わりに自分の解決策がすでに効果的に問題を解決していると長々と理由を述べ、「優雅に」とまで言い張りました。
スティーブン氏はAIを説得できず、代わりに新たな問題を指摘しました。またもやテストコードが正しい位置に置かれておらず、実行されていなかったのです。
正しい位置に置いた後、案の定、また問題が発生しました。AIが追加したテストはすべて失敗しました。
ここまで来ると、傍観していたネットユーザーはもう見ていられなくなり、Microsoftの従業員はAIに指示する時間を無駄にするよりも、自分で問題を解決すべきだと考えました。
結局のところ、これは.NETランタイムのコードであり、多くのクラウドコンピューティング、医療、金融などの重要なシステムがこれに依存して動作しています。
混乱の中、ある者は脱獄プロンプトを試み、AIにプロジェクト全体をPHP言語で書き直させようとしました。
しかし、幸いにもMicrosoftは権限管理を行っていたため、プロジェクト参加者以外の指示はCopilotに影響を与えませんでした。
スティーブン氏は依然として、エージェントの設定問題は修正中であり、実験を続けると主張しました。
しかし、皆の意見は「もう続けるな、早くこの実験を中止しろ」というものでした。
Microsoft従業員の回答：強制要件ではない
Copilotエージェントのひどいパフォーマンスは、傍観していたプログラマーたちを最初は面白がらせましたが、徐々に業界全体にとって何を意味するのかを考えさせられるようになりました。
Microsoftが最近3%の人員削減を行ったこと、そして同社のコードの20～30%がAIによって生成されているという情報が合わさり、Copilotが解雇された6,000人の代替として使われているのではないかと疑わせる状況です。
このままでは、.NETプラットフォームを信頼し続けることはできなくなり、いつかAIが書いたひどいコードが本番環境に入り込むでしょう。
より広い視点から見ると、これは人類がAIを開発した当初の目的にも反していると考える人もいます。
本来、機械は人間の作業を補助するはずだったのに、今は逆になって人間が機械を補助せざるを得ない状況です。
ある.NET開発者は、どれだけのAIが15年前のStack Overflowの回答に基づいて訓練されているのか、そしてそれらの回答がもはや現在のパターンや推奨される方法を表していないのではないかと提起しました。
AIが継続的に失敗し続けるなら、プロジェクトの保守担当者の忍耐をすり減らすでしょうか？
あるいは、これはAIに熱心な株主に見せるためにMicrosoftが出した命令に過ぎないのでしょうか？
しかし、スティーブン氏は、Copilotの使用は会社の強制要件ではなく、チームはAIツールの現在および将来の限界を理解するために実験を続けていると回答しました。
そして彼はこう考えています：
これらのAIツールをどのように活用するかを考えない人は、将来淘汰されるでしょう。
One More Thing
.NETランタイムのコードベース全体で、Copilotがバグを自動修正し、コードを正常にマージできたケースはわずか2件しか見つからず、それらも人間のプログラマーが繰り返し修正を促してようやく成功したものでした。
しかし、Copilotは多くのPRで補助コードレビューアとして機能しており、こちらは比較的順調で、ほとんどが成功しています。
このCopilotエージェントは、現時点ではコードの自動補完や内容の要約といった作業しかできないようです。
真のバグ修正には、やはり人間が必要です。
お祭り騒ぎの現場：https://github.com/dotnet/runtime/pull/115743https://github.com/dotnet/runtime/pull/115743https://github.com/dotnet/runtime/pull/115733https://github.com/dotnet/runtime/pull/115732https://github.com/dotnet/runtime/pull/115822
— 完 —
量子位AIテーマ企画が募集中です！「365のAI導入ソリューション」「1001のAIアプリケーション」の特別企画にご参加いただくか、あなたが探しているAI製品、または発見したAIの新しい動きを私たちと共有してください。
💬 量子位AI交流グループにもぜひご参加ください。一緒にAIについて語り合いましょう〜
ワンクリックフォロー 👇 星を灯して 毎日テクノロジーの最前線を見よう
「いいね」「共有」「ハート」のトリプルクリックをお願いします！コメント欄にあなたの考えを残してください！