私はLLMを数分以上回していい結果が出たことはないと思う。これはAiderやCLineみたいなものでの話？私はClaude-Codeを使ってるんだけど（Maxプランだからトークンを無駄にする心配がない）、1時間以上かかるタスクも成功裏に処理できたよ。でも、そこにたどり着くのは簡単じゃないのは確か。指示やCLAUDE.mdファイルは完璧でなきゃいけない。

自分のコンテキストを毒してるんだよね。コンテキストが成長するにつれて、特に多くの気を散らす要素や行き止まりが増えると、出力の質が急激に落ちていく。良いコンテキストでも、100kトークンあたりでその劣化が見え始める（Gemini 2.5の場合）。彼らは本当に、以前のコンテキストを削除したり「忘れさせたり」する方法を見つける必要がある。そうすれば、ユーザーやモデルが毒のあるトークンを整理できるようになる。今は、定期的にインスタンスの要約を作って、新しいインスタンスを新鮮なコンテキストで立ち上げて、前のインスタンスの要約を入れることで対処してる。

コメントで「それはできない」と言う人と「こうやって動かしてる」と言う人がいるのはよく見るよね。確かにコツがあるのかもしれないけど、みんなが使おうとしてる問題の違いが、かなりの違いを説明してると思う。人々は自分が何をしようとしていたのかをあまり具体的に言わないことが多いし、プログラミングの議論でも同じことが言えるよね。

私も似たような経験がある。エージェントはとても便利で多くのタスクを自分で完了できるけど、時々行き詰まることもあって、その選んだ解決策が変だったりすることもある。例えば、先日モデルを変換してたんだけど、ディスクスペースが足りなくなってきたんだ。エージェントはスペースを節約するために量子化を変更することにしたけど、私は「もう少しディスクスペースが必要だよ」って聞いてほしかった。だから、一旦停止してスペースを空けてから、エージェントに元のコマンドを再試行させたよ。

特に難しいパースの問題があったから、いくつかテストを設定して、LLMにしばらく処理させておいて、他のことをしてたんだ。戻ってきたら、全部のテストが通ってた！でも、実行してみたら、まだ多くのケースが失敗してた。どうやらLLMがテスト値を「if (‘test value’) return ‘correct value’;」みたいにハードコーディングしてたみたい！

エラーを修正する代わりに、別のライブラリに切り替えることにした。私も似たような経験があって、エラーを修正する代わりに、その周りにtry/catchを追加して、ログメッセージを出して、実行を続けられるようにしてた。

Claude Codeを使ってて、変更しようとしてるのにテストがずっと失敗して、結局そのテストを削除してテストスイートを通過させたことがある。みんな経験あるよね！基本的に、セッションはペアリングセッションとして扱ってるんだけど、ペアリングセッションでは、失敗してる道を進むのをやめて、最初からやり直すことが必要な時もあるんだよね。

「数分以上LLMを回しっぱなしにして良い結果を得たことはない」って言うけど、私はその逆の経験があるよ。特に、LLMがテストスイートやプロジェクトが成功するまでのコンパイルエラーを修正するようなテストに対して検証する場合はね。うまくいくまでずっと頑張ってくれるし、最終的には良い結果が得られることが多いよ。ただ、AIが成功するまでの間は、そのエラーがすごくバカみたいで、見ててイライラすることもある。

なんか、こういうことに関係してる気がする：人間は問題解決で行き詰まると、新しい情報を得るために外に出ることが多いよね。それで直面した障害をよりよく対処できるようにする。これをトレーニング環境で再現するのは難しいと思うし、エージェントにGoogleを検索させるのはトレーニングサンプルを汚染しちゃうから難しいんじゃないかな。

最終的には正しい解決策にたどり着くかもしれないけど、一般的には、無駄に脱線する前に中断することでかなりの時間を節約できるよね。

ちょっと誇張だと思うけど、言いたいことはわかるよ。4〜5回以上の再プロンプトは効果が薄れてくるよね。

これは半分正しいと思うし、半分はすごく間違ってる。LLMと議論してるなら、絶対に間違ってるっていつも言ってるよ。その理由の一部は、LLMにはできないことがあって、議論してもそれは変わらないから。でも、もう一つの理由は、文脈に対する感受性がすごく高いこと。できることについて議論してるなら、より良いプロンプトでやり直すべきだし（重要なのは、最初の試みからの汚染された文脈を持ち込まないこと）。

人にも影響があるよ。1990年代に理論物理の博士課程をやってたときに学んだことの一つは、複雑な計算がある50ページの論文には、ほぼ間違いなく深刻なミスがあって、行ごとに見直すと見つかるってことだった。面白いよね。昔は数学や科学は人間が世界をモデル化するために作ったもので、あいまいな思考の連鎖によるエラーを避けるためだと思ってた。あと、形式言語のおかげで大きな建物がしっかりした基礎の上に建てられるようになった。君のエピソードからすると、論文の計算は数値的だったのかな？でも、記号計算にも似たようなことが言えると思う。

なんか、最初の頃のMLの消失勾配問題を思い出すな。すごく深い層はトレーニングできないんだよね、途中で勾配が消えちゃうから。解決策はバイパス接続（resnetsスタイル）を追加することだった。似たような解決策があるのかな？もちろん、一般的には制御理論みたいな感じで、ある確率でコースを外れているのを検出して修正できるはずだと思う。[長いホライズンを持つと、安全ゾーンを離れる確率が高くなるから、経験的減衰はあるけど、より広い範囲で起こるんだよね。] でも、これらのアイデアをどうつなげるかはよくわからないな。

人間の健康もこの原則に従ってるよ。Nは寿命。取られるステップは細胞分裂。最終的には問題が蓄積して、システム全体が失敗することになる。性的生殖は文脈をクリアにして、ROMからやり直すことなんだ。

人間が「証明は読者の演習に任せます」って言えるなら、LLMもできるはずじゃない？ :)

• エラーを「取り除く」ためにtry/catchブロックを追加して、実行を続ける

「スタブを提供してコードを埋めるように頼む」っていうのは、チャットボットスタイルのアプリでは永遠の問題だけど、Claude Codeではそんなことは一度もなかったな。

ここでの話に当てはまるのは、人々がエージェントパイプラインを試しているからで、そういうシステム工学やロバスト性に関する既存の文献が、以前は学ぶ必要がなかった人たちにも役立つってことだね。

科学的ではないけど、モデルが大きくなるにつれて「知恵」を吸収して、エラー生成の確率が下がる感じがする。

1万時間の何を比較してるの？コンパイラは、私が書くプログラムのために百万時間かけるよりも、すでに私よりも優れてるよ。コンピュータは、そろばんや紙とペンで手作業するよりも、何十億時間も節約してる。人間の生産性は、アクセスできるツールに常に依存してるし、エージェントがそれだけ生産的になれば、人間もツールを使って同じように生産的になるはずだ。—— 何世代もかけて倍増することを予測するのは、地元の空間で平らに感じるから地球が平らだと言っているのと同じだ。10世代後に指数的な倍増が続くとは思えない。歴史の中で10世代にわたってそれを達成した例はただ一つ、ムーアの法則だけだ。ほぼ一定の速度で何世代も倍増するのはほぼ不可能で、古代の米とチェス盤の話からも、人々は常に指数の力に苦しんできた。—— 現在のLLMのアプローチは、サイクルの終わりにかなり近いと思う。おそらく、残りは1〜2世代がせいぜいだ。主要なプレイヤーごとの資金投入はすでに年間500億〜1000億ドルに達している。どの組織も何かに年間5000億ドルを使うことはできないよ。民間セクターや公共の場で、大規模な協力が資源を割り当てて3世代先に進むために行われているとは思えない。半導体技術と比較すると、私たちが持っている唯一の指数的な例で、ファウンドリーや研究の予算は似たように増えてきたけど、今では先端ファウンドリーで10〜20億ドル程度で、同じペースで成長し続けているわけではない。資本の可用性やリスクが制約となって、残っているファブプレイヤーが少なくなり、残ったプレイヤーは停滞して真剣に投資する余裕があるからだ。