脳をオフにしても意味がない時などない

2025年初頭、LLMを使用する際に人々が「脳をオフにする」のを目にするようになりました。LLMに要約やコーディングなどのタスクを実行させ、それが機能したと単純に仮定するのです。これは2025年初頭には一般的にうまくいかず、結果はしばしば非常に滑稽なものでした。LLMが改善されるにつれて、このような傾向は増えています。時には、人々はLLMにコードを書かせ、それが機能すると基本的に仮定するだけです。人間が介在する場合もあり、うまくいかない場合は、LLMに問題を見つけて解決するように依頼します。Niklas Gruhnは、このような手法のいくつかのバリエーションを「ミートプロキシ（肉の代理）」と呼んでいます。for loopのミートプロキシは、2025年初頭よりもうまく機能するようになり、このように開発されたソフトウェアは、時には実際に機能するようになります。私が使いたいと思えるほど、あるいは成功するほどではありませんが、2026年9月現在、ミートプロキシがいかに効果的であるかに感銘を受けています。将来的には、LLMが十分に改善され、ミートプロキシ開発が平均的な品質のソフトウェアを生み出すようになることさえ想像できるかもしれません。あるいは、人間を介さずにLLMが素晴らしいソフトウェアを生成するほど改善されるかもしれません。仮にそれが起こったとしましょう。会社がミートプロキシを雇用する理由は何でしょうか？会社は単にLLMをループで実行し、従業員を解雇できます。この方法論が従業員にとって機能する時点はありません。Max Bittker、Yossi Kreinin、Luke Burton、Thomas Dullien、Dennis Snell、Peter Geoghegan、Jamie Brandonには、コメント、修正、議論に感謝します。この考えは1年半ほど前からありました。LLMが改善され、LLMとの対話で脳をオフにする時間が増えているのを見るにつれて、最近ではより頻繁にこの考えが浮かびます。 Luke Burtonは次のようなコメントをしました。「このようなことができるというのは、行われている仕事の種類について、人々が考えている以上に多くを物語っていると思います。私は、タスクの価値が非常に低い場合、失敗しても構わない場合にのみ、このような仕事から手を引きます。価値の高いタスクでは、LLMが一発でそれらをこなせる確率ははるかに低いです。私はQA、エンジニアリングマネージャー、アーキテクトの役割を担わなければなりません。while loopはしばしばクランチタイムのように感じられます。何かを見落としたのではないかという nagging suspicionがあり、不適切に指定されたプロンプトが、やり直しが必要なアーキテクチャ上の選択につながる可能性があります。もう一つの観察は、高いスループットが私自身の出荷基準を引き上げることです。以前はMVPを出荷して反復処理していたかもしれませんが、今ではエージェントが私の基準をはるかに超えるエッジケースを磨き、探求しますが、プロンプトを与えない限り、それらを達成することはできません。それは人々に不快な考えを抱かせるかもしれませんが、ミートプロキシの皆さんに、エージェントがそれほど簡単にこなしているなら、私の質問は次のとおりです。1) あなたはすでに少し楽をしていた可能性がありますか？ 2) なぜ、それほど簡単にこなせるタスクをはるかに超えてエージェントをプッシュしないのですか？私たちは、「ハンズオフ」自動化に非常に適していると思われることを行ってきました。それは[redacted]をBazelでビルドするために変換することです。エージェントを使っても、数ヶ月かかっています。このタスクには、目に見えず、指定が難しい要件がたくさん埋め込まれており、エージェントがそのラインを歩くということは、絶え間ない監視を意味します。「これをBazelに変換して」というプロンプトを与えて立ち去ることは、少なくとも数ヶ月先、おそらく数年先、そしておそらく決してないかもしれません。意思決定のポイントが多すぎ、未知の未知数が多すぎます。例えば、コードに遭遇し、それがなぜそのように機能するのかはっきりしないが、そのことを知ることが取るべき行動のコースを実質的に変える、というシナリオはどれくらいの頻度で発生しますか？開発者体験に影響するかもしれませんし、ある顧客がそれを使用し始めているかどうか分からないかもしれません。そのような状況で、どのようにミートプロキシするのですか？逆に、あるステークホルダーと行った作業を確認すると、「ああ、あれ？あれは必要なかった部分です。もう使っていません」と言われることがあります。特定の要素を保持する必要があるという誤った仮定の周りで、どのような決定が下されたのでしょうか？（Lukeのコメントはここまで、私のコメント）。エージェントが分布外の何かに遭遇した場合に、より明白に意思決定を行う必要がある場所があります。このマイナーなバージョンは、エージェントが異なるプログラミング言語をどれだけうまく使用できるかを比較したときで、エージェントは、それらが学習されているにもかかわらず、主流言語ほどではない、よりマイナーな言語でははるかに劣っていました。より分布外の例は、ボードゲーム（特にチェスや囲碁のような古典的なゲームではなく、現代のゲーム）をプレイしようとすることです。一般的に、Lost CitiesやDominionのようなゲームでは、SOTAモデルとハーネスは、ボードゲームがそこそこ得意だが、そのゲームをプレイしたことがない人間よりも劣っています。ゲームについてエージェントに尋ねると、ゲームについて多くのことを知っており、ゲームを理解していない人にはもっともらしく聞こえるが、理解している人には明らかに間違っていることを言うことができます。最近、新しいプレイヤーと一緒にDominionをプレイしましたが、そのプレイヤーはChatGPTを使ってゲームを理解するのを助けることが、ゲームを学び、プレイするのに役立つと考えていました。私は非常に懐疑的で、おそらく彼を悪化させるだろうと示唆しました（そして、私の知る限り、それはそうでした）。数ゲームプレイした後、ChatGPTが彼に何を伝えているかを見ましたが、それは半分正しく、半分間違っていましたが、間違っていた部分は、一般的なゲームプレイのヒューリスティックを使用して、ゲームをうまくプレイする人よりも悪い方向へ導いていました。ちなみに、十分な公開情報があるので、初めてプレイした人でも、例えば5時間ゲームについて読んだり、公開されている情報を調べたりすることに費やした場合、事前の読書と参照資料があれば、そのゲームで99パーセンタイル以上に容易に到達できると思います。それは楽しくないと思うので、誰にもお勧めしませんが、エージェントは検索やAPIのクエリなどを行えることを考えると、分布外の問題に取り組む際の人間とエージェントの今日のギャップを示しています。次の大きなモデルリリースでこれが逆転する可能性はありますが、今日のギャップはまだかなり大きいです。とにかく、私の言いたいことは、コーディングタスクを行っている場合でも、エージェントが合理的な人間と比較して非常に悪く振る舞う分布外の質問に遭遇することがよくあるということです。今日、全体的に良い結果を得たいのであれば、これらのケースに気づき、それに対処する必要があります。 人々が単に物事がうまくいくと仮定したときに起こる問題の例としては、エージェントが（時には）テストに過度に過剰適合するこのケースや、エージェントがメトリックに過度に過剰適合するこのケースがあります。エージェントは評価形式の問題でより多くの不正行為を行うという理論を聞いたことがあります。それが本当かどうかは分かりませんが、たとえそれが本当だと仮定しても、私の仕事や個人的なプロジェクトでは、評価形式の指示をほとんどの人よりも多く作成する傾向があるとしても、評価形式のものをあまり作成しない他の人々が、いくつかの指示を書き、エージェントを監督なしで自由に動かしたときに、同じ問題（実際にはより深刻に）に遭遇するのを見てきました（私は最小限の監督でうまくいったことがありますが、それはエージェントをかなり制限することによってのみであり、それはほとんどの人が行うよりも、そのものを評価形式に近づけます）。LLMに思考をアウトソースした人々からソフトウェアを入手すると、そのソフトウェアには深刻な問題があります。この種のことが機能すると私に言った人もいますが、そのソフトウェアはしばしば、ここで議論されている基準によれば機能しないと私が言うレベルにあります。くだらない例を挙げると、あるプログラミングの思想的リーダーがTwitterで、プログラミングは解決されたと宣言したのを見ました。なぜなら、彼はあらゆる種類の（プログラミング）分野でプロジェクトを試したが、Claudeはすべてを専門家と同じように解決できたからです。私は実際に彼のGitHubを見て、私が調べたすべての例（ゼロではない数）は、機能しないか、非常に悪く機能していました。ボードゲームAIを作成していたときに、この問題に遭遇しました。