ツール使用によるLLMエージェントループの非合理的な効果

375日前原文(sketch.dev)

概要

SketchはAIプログラミングアシスタントであり、LLMとツール利用のループが非常にシンプルであることを強調する内容。
LLMはbashなどのツールを活用し、多くの作業を自動化・効率化できることを示す提案。
一般的な開発作業（git操作、型エラー修正など）もSketchを通じて迅速化できる確認。
ツールの追加により、LLMの編集能力や開発者のワークフローが向上することを指摘。
今後も多くのカスタムLLMエージェントループが日常的な自動化に組み込まれる予測。

AIプログラミングアシスタント「Sketch」とLLMエージェントループの本質

LLMとツール利用のシンプルなループ

Sketchの開発で最も驚いたのは、 LLMとツール利用のメインループ が非常にシンプルだったことを共有すること
主要なループは9行程度で、 ユーザー入力を受け取り、LLMに送信、出力とツール呼び出しを処理 するだけで完結すること
llm()関数は システムプロンプト、会話履歴、次のメッセージ をLLM APIへ送信すること
ツール利用とは、 LLMがスキーマに対応した出力を返し、bashなどのツールアクセスが可能になること を指すこと
Claude 3.7 Sonnetを活用し、 多くの問題をワンショットで解決できる能力 を実感すること

Sketchによる開発作業の効率化

以前はgitの難解な操作を 調べてコピー＆ペースト していたが、今はSketchに依頼すること
gitマージの手動処理も、 Sketchに最初の試行を任せる ことで効率化すること
型変更後のエラー処理も、 Sketchで一括対応を試みる ことで作業負担を軽減すること
適切なプロンプト設計により、 エージェントループの永続的な自動化 が実現すること
必要なツールが未インストールの場合、 自動でインストールする柔軟性 を持つこと

エージェントループとツールの拡張性

grepのコマンドオプションが異なる場合も、 Sketchが自動で適応 すること
LLMがテスト失敗時に「スキップしよう」と提案するなど、 時に苛立たしさも感じる こと
ワークフローごとに エージェントツールの専門化 が進む傾向を指摘すること
bashだけでなく、 追加ツールの導入が品質や反復速度、開発者体験を向上 させること
sedなどのワンライナー編集にLLMが苦戦し、 ビジュアルエディタの優位性を再認識 すること

今後の展望とまとめ

今後、 日常的な自動化作業にもエージェントループが浸透 していくと予測すること
スタックトレースとgitコミットの相関付けなども、 LLMによる一次処理が有効 であること
各自のbin/ディレクトリに、 カスタムLLMエージェントループのスクリプトが増加 する見込みである提案
お気に入りのベアラートークンを用意し、 Sketchの利用を推奨 すること
参考: philz.dev/blog/agent-loop/、sketch.dev、merde.ai、pi.dev

Hackerたちの意見

sonnet-3.7はめっちゃ不安定だと思う。うまくいくこともあるけど、すぐに脱線して変なことしちゃう傾向が強い。個人的には3.5の方がいいかな。claudeデスクトップをMCPサーバーに接続して、ぼったくり価格なしでclaude-codeを偽装してみたけど、そこそこうまくいった。Rustの作業に使おうとしてるけど、まだあまり良くない（Rustの概念を「理解」してる感じがしない）けど、変更後にcargo checkを実行して、ダメだったら止めるといった感じでいくつかのことはできる。o3-highみたいなのが一番良さそうだけど（aiderのリーダーボードもそれを支持してる）、正直言って私の予算を超えてる。高い価格を払って、役に立つかどうかわからないLLMの応答に対して、精神的に納得できないんだよね。モデルがタスクを失敗して、何度も「再ロール」しなきゃいけないのに、そのコストを私に押し付けるのは本当に不満だわ。

└

APIアクセスのコストを避けるために、チャット/UIを使ってる。私の場合はGoogle Gemini 2.5 Proの高トークンウィンドウを使ってる。リポジトリ全体をRepomixして、標準のプロンプトで「全ソースを返して」ってペーストするんだけど（何度かやり取りするとこの指示を無視しがち）、その結果をリポジトリに適用してる（vibe coded https://github.com/radekstepan/apply-llm-changesを使ってる）。それ以外は、Clineに5ドル使ってClaude 3.7を使ったけど、テストを直す代わりに、ソースコードにif/else文を追加してテストを通す羽目になった。

└

最近の数日間、Mistral Medium 3を使ってみたけど、正直言ってその良さに驚いてる。コストを削減しようとしてるなら、ぜひ試してみてほしい。私は基本的にClaudeからMistralに切り替えたけど、コストが同じでもMistralの方が好きだな。

└

俺だけかもしれないけど、コーディングに本当に良い方法って、遅くて重いテスト時間の計算モデルだけだと思う。o1-proとo1-previewは、エラーなしで1000行のコードを信頼して更新できる唯一のモデルだ。o3には、すごく小さいコード以外は書かせないようにしてる。「安い」モデルは、押し込むと幻覚を見たり、ひどい失敗をするからね。最近やってる良いアドバイスがあって、LLMに渡す前にコードのコメントを全部削除すること。どんな状況でもLLMが生成したコメントは残さない方がいいよ。

今日、初めてGPT-4oと4.1を使って「vibe-coding」を試してみた。手動でやって、コンパイルエラーや警告、提案をループでキャンバスインターフェースに入力してた。ファイルは小さくて、150行くらいだったけど、うまくいかなかった。4oから始めたんだけど、 - 廃止されたパッケージを使ってた。 - 指摘した後も全ての使用箇所を更新しなかったから、手動で修正しなきゃいけなかった。 - 小さな論理変更を提案したら、文法が完全に壊れちゃって（「foo() } return )))」みたいな感じ）、回復しなかった。何度も生のコンパイルエラーを与えたけど、文法が間違ってることすら認識しなかったし、コードのランダムな部分を書き換えるだけだった。 - それで、「もしかしたら4.1の方がコーディングが得意かも」と思ったけど（宣伝通りに）。でも4.1はキャンバスを全く使おうとしなかった。変更できることを説明するだけで、「自分で編集しろ」って感じだった。 - しばらく押し進めたら、キャンバスを使ってフルコードを返すようになったけど、結局は短縮版のコードを返してきて、「// 簡潔にするために省略」みたいなコメントがついてた。それで諦めた。エージェントはこれをどうにかして直してくれるの？現状では、体験が完全に壊れてる感じがする。bashにこれをアクセスさせるなんて考えられない、危険すぎる。

└

CursorかWindsurfを、ClaudeかGeminiモデルで試してみて。まずはドキュメントファイルを作成して、すべてのテストを生成してみて。多ければ多いほどいいよ。そしたら、テストが通るまで100回サイクルさせてみて。普通のプログラミングは歩くようなもので、慎重で確実。vibe codingはサーフィンみたいで、すべてをコントロールできないから、自動で「はい」を押すだけ。プロセスを信じて、間違いを犯させて自分で回復させてみて。

└

GPT-4oと4.1はここで使うには最適なモデルじゃないよ。Claude 3.5/3.7、Gemini Pro 2.5、またはo3を使ってみて。どれも小さなファイルにはすごくよく効くよ。

└

4oと4.1はコーディングにはあまり向いてない。私のベストな結果はだいたい4o-mini-highで、o3は時々かなり良い。個人的にはキャンバスが好きじゃない。チャットの出力の方が好きだし、よく「このファイルの全コードを提供して」や「差分を気にせず置き換えて」って言うんだけど、300-400行のコードになると、だんだん悪くなってきて、複数のファイルに分けるためにリファクタリングが必要になる（ファイル内の一つのメソッドだけに集中できる場合を除いて）。

└

GPT 4.1と4oはAiderのコーディングベンチマークでかなり低いスコアを出してるね。俺の経験では、70%以上のスコアを持つモデルからやっと許容できる結果が出始める。とはいえ、複雑なことをやらせるにはかなりの手助けが必要だよ。何がうまくいくか、何がダメかの感覚がつかめてくる。

└

「スキルの問題」と言われるのはイライラするのは分かるけど、LLMを使うのは確かにスキルだよ。いろんなツールの強みを理解して、それを使って技術を理解するために実験して、ただひたすら練習することが必要なんだ。ただ、もし俺がbashにアクセスできるなら、やっぱりdockerコンテナの中で使うと思う。

└

時にはイライラすることもあるけど、俺の経験では、試せば試すほど、何を聞いて何を期待すればいいかが分かるようになるよ。でも、やっぱり「バイブコーディングはちょっと過大評価されてる」って言う人がいる理由は分かるよね: https://www.lycee.ai/blog/why-vibe-coding-is-overrated

└

「使われているパッケージが非推奨になってる」ってことなんだけど、モデルにはトレーニングのカットオフ日があるんだ。それを考慮することが大事だよ: https://simonwillison.net/2025/Mar/11/using-llms-for-code/#a... 最近、コードの多くに対してo4-mini-highをChatGPT経由でデフォルトモデルに切り替えたんだけど、最新のドキュメントを検索する機能を使えるからね。「ライブラリXの最新バージョンを調べて、それを使って」って言うと、たいていうまくいくんだ！最近、イライラするアップグレードに使ったこともあって、以前のコードを貼り付けてこう促したんだ: このコードをGoogleの新しい推奨JavaScriptライブラリにアップグレードする必要がある。何なのかを見つけて、これを移植するのに十分なドキュメントを調べて。そしたら、俺が頼んだ通りにやってくれたよ: https://simonwillison.net/2025/Apr/21/ai-assisted-search/#la...

└

先日、VSCodeのClineプラグインを使ってClaudeと一緒に「ゼロから」Androidアプリのプロトタイプを作ったんだ。つまり、Android Studioが提供する通常のテンプレートから始めたってこと。数千行のコードが生成されて、コンパイルエラーは一つもなくて、アプリは結局俺が望んでいた通りの動作をしたよ。ただ、バグが一つか二つあったけど、それはLLMのアホさじゃなくて、かなり難解なAndroid APIの奇妙な未文書の動作が原因だったんだ。（だからこそ、迅速なプロトタイプが欲しかったんだけどね。）バグをLLMに指摘したら、成功裏にデバッグしてくれたよ（俺の助けやフィードバックをもらいながら、つまり、LLMがコードに追加したデバッグメッセージの出力を提供したんだ）そして最終的に修正してくれた。ただ、修正の質にはあまり満足できなかったな – もっと汚いハックみたいだったけど、まあ、もう一回か二回フィードバックをしたら、そこもクリアできたよ。もっと一般的に解決できる方法があると思うけど、コードを書くエージェントを他のコードレビューエージェントとループさせることで解決できるんじゃないかな。

└

他の人も言ってるけど、君は先端から約3ヶ月遅れてるみたいだね。君が言ってることは2月の俺の経験に似てる。クレードに切り替えた方がいいよ（個人的には、ジェミニも同じくらいだと思う）。ちゃんとしたコーディングツールを使って、チャットウィンドウからのコピー＆ペーストなんて、もう古いよ。

└

AiderとClaudeでコーディングしてるんだけど、私の経験はこんな感じだよ： - 新しいコードを書くのはすごく得意 - 一度間違えると、もっとコンテキストや修正を与えても意味がない。再び間違うか、別のところで間違うだけ。 - 問題を修正するのに役立つこともあるけど、また最初の段階で問題を見つけるか、全く見つけないかのどちらかだね。私はLLMを超高速のジュニアコーダーとして扱ってる。頭の中に膨大な知識ベースがあるけど、すごく頑固で、最初の試みで解決できなかった問題を解決するのは手助けできないんだ。

このブログ記事も強くおすすめするよ。もっと詳細で説得力のある同じポイントを扱ってる。著者は実際にゼロからコーディングエージェントを作ってる: https://ampcode.com/how-to-build-an-agent LLMがツールを呼び出せるループが、今やあらゆるタスクにどれだけ効果的かは本当に驚くべきことだよ。確かに、時々脱線することもあるし、最後の10%の信頼性を得るのが難しい問題もあるけど、少なくとも少しでも驚いてないなら、自分でこういうものをハックしてみることを強く勧めるよ。約30分でできるから。AIがこの用途に効果的かどうかに対する健全な懐疑心を持ちながらも、こういうことに対して驚きを感じることは可能だよ。このLLMをループに入れる「不合理な効果」は、今やたくさんのコーディングエージェントが出回ってる理由でもある: Claude Code、Windsurf、Cursor、Cline、Copilot、Aider、Codex… そして他にもたくさん。最近HNの投稿者が言ってたけど、みんながエージェントを作ってる感じだね。理由は、秘密のソースはなくて、95%の魔法はLLM自体と、ツール呼び出しのために微調整されてることにあるから。Claude Codeのリード開発者の一人が最近のインタビューでこれを率直に認めてる。[0] もちろん、これらのツールをうまく機能させるためには多くの作業が必要だけど、最終的にはみんな同じシンプルなコアを持ってる。[0] https://www.youtube.com/watch?v=zDmW5hJPsvQ

└

上のリンクを開く前に ?utm_source=hn&utm_medium=browser を使うように変更した方がいいかな？

└

これもあるよ、ポケットフローを使って、似たようなものを作るグラフ抽象ライブラリだ[0]。俺も使ってて、そのシンプルさが大好き。 [0] https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blo...

└

ああ、トーステン・ボールだ！彼の「インタープリターを書く」をすごく楽しんだ。今、エージェントを作ろうと思ってる。

└

LLMが自分でループを回して、数回以上繰り返すのに十分なことなんて思いつかないな。すぐに引き戻さなきゃならなくなる。

└

こんな記事を探してたから、ありがとう！エージェントに対する一般的な反応は「まあ、複雑な問題をうまく解決できないだろう」って感じだと思う。でも、私にとってはそれがエージェントのポイントじゃない。LLMは多くのコンテキストがあるときにうまく機能するし、エージェントはLLMがもっとコンテキストを発見して、質問に答える能力を向上させることを可能にするんだ。

└

一般的に、LLMがこうやって効果的な時は、提供されたツールを使って問題を解決するためのより効率的な非LLMベースのソリューションが存在するってことだよ。LLMは、実現するためのステップの系列や入力と出力の合成を見つける手助けをしてくれる。問題を解決するためにLLMが常にツールを使うのは高くて遅いから、次のステップは頻繁に呼ばれるツールのパターンを単一の純粋な関数に変換することだね。必要な入力と出力の変換を行いながら（LLMがこれらの関数を作る手助けをしてくれる）、その後、シンプルで安価な分類器をトレーニングして、常に新しい関数にデータを送るようにする。これでLLMを完全にバイパスできる。時間が経つにつれて、LLMの使用はどんどん減っていき、分類できない新しい問題に限られるようになる。これは基本的にLLMベースの問題解決のための「キャッシュ」のようなもので、キーは問題の形なんだ。LLMが同じ問題を同じ方法で何度も解決するのを24時間365日やるっていうアイデアは、遠い記憶になるべきだけど、APIコールをできるだけ売りたいAI企業が人々に思い描いてほしくないものだね。理想的には、LLMは新しい問題に対して一度か数回だけ使われ、その後は安価なコードに置き換えられるべきなんだ。

└

あなたがリンクした最初の記事のRubyポートもあるよ。機能的にはほぼ同じだけど、もしあなたが（私のように）PythonよりRubyが好きなら、両方の記事を読む価値はあるよね：https://news.ycombinator.com/item?id=43984860 https://radanskoric.com/articles/coding-agent-in-ruby

└

コンシューマーグレードのGPU（24GB VRAM）に収まる最高のモデルでどこまで行けるかな？

└

理由は、秘密のソースがなくて、95%の魔法はLLM自体にあるからこれで「30億ドル」の評価がWindsurfに対して非常に疑わしくなるね。

└

最後の10%の信頼性を得るのが問題なんだよね。俺の経験上、その次の9%を達成するには9倍の努力が必要なんだ。そしてその次の0.9%も9倍の努力が必要になる。そういう感じでさ。だから90%から99.999%の信頼性までの距離はすごく遠いんだよ。EC2インスタンスよりもまだ信頼性が低いだろうね。

今、LLMのツール利用にすごくワクワクしてる。これ自体は新しいトリックじゃなくて、2年前にReAcTの論文で初めて出会ったんだ - https://til.simonwillison.net/llms/python-react-pattern - それ以来、ChatGPTのプラグインや最近のMCPでも使われてるし、すべてのモデルはツール利用や関数呼び出しを考慮して訓練されてる。今日の面白いところは、モデルがそれをどれだけ上手にこなせるようになったかってこと。o3/o4-miniの素晴らしい検索パフォーマンスはすべてツール呼び出しのおかげだよ。Qwen3 4B（Ollamaからの2.6GB、俺のMacで快適に動く）も、今ではツール呼び出しをかなりうまくこなせるようになった。昨日、PyCon USでLLMの上にソフトウェアを構築することについてワークショップを開いたんだ - https://simonwillison.net/2025/May/15/building-on-llms/ - それをきっかけに、ついに自分のLLMコマンドラインツールのアルファ版にツール利用を追加したよ。ワークショップのこの部分でそれをカバーしたんだ: https://building-with-llms-pycon-2025.readthedocs.io/en/late... 俺のLLMパッケージは今、ストロベリーの中のRの数をシェルのワンライナーで正確に数えられるようになったよ: llm --functions ' def count_char_in_string(char: str, string: str) -> int: """Count the number of times a character appears in a string.""" return string.lower().count(char.lower()) ' 'Count the number of Rs in the word strawberry' --td

└

この奇妙なシンプルさと力強さの組み合わせが大好きだ。

└

ワークショップは録画されてたの？

クロードコード、つまりSonnet 3.7のターミナルインターフェースを、3月中旬に出たその日から使ってる。かなりのCLIアプリやフルスタックのウェブシステム、たくさんのユーティリティを作ってきた。これのおかげで、昔プログラミングチームを運営してた時と同じくらい、もっと野心的になってる。中身はほとんど同じだと思うけど、Anthropicはめちゃくちゃ便利な機能をたくさん追加してる。完璧なものなんてないよね。良いコードを生産するのは、チームを運営してた時と同じくらいの努力が必要だ。複雑なものを動かすことは可能だけど、次の機能を追加するのが本当に厄介な状況に陥ることもある。運転を学ぶにつれて、リメディエーションやリファクタリングがずっと少なくて済むようになった。それは決してなくならないだろう。かわいそうなkgeistが何があったのか想像もつかない。クレードが俺がしない選択をしたり、バカなことをすることもあったけど、諦めようとは思ったことは一度もない。ほとんどいつも、 decentな仕事をしてくれるし、ほとんどのことに関しては、俺の頭から取り除いてくれる作業量がすごい。しかも、リファクタリングも素晴らしい仕事をしてくれる。定期的にコードを見て、どうすれば良くなるか考えて、クレードに指示するセッションを持ってる。膨大な複雑さが解消される。「このデータ構造を変えて」、完了。すごくクールだよ。そして、遊びで、コードじゃないアーカイブディレクトリを開いてみた。30年間ずっと詰め込んできたゴミ箱だった。「このディレクトリには何が入ってる？」「古い履歴書を読んで、新しいのを書け。」「子供の名前は何だっけ？」これもすごい。まだ初期段階だけど、めちゃくちゃ幸せだ。

└

それに、良い測定のために素晴らしいリファクタリングをしてくれる。定期的にコードを見て、どうすれば良くなるかを考えてクラウドに指示するセッションがある。複雑なことが大量に片付く。「このデータ構造を変えて」、はい、完了。すごくクールだよ。これ、ほんとに楽しい。スプリントに入れるのが大変なことが5分で終わる。まるでチーム全体がそこにいて、私の指示を待っているみたいで、仕事が正当化されるのを待つ頭痛もないし、もし結果が気に入らなければ拒否する理由を考える必要もない。

└

最近、リモートデータ構造を定義して、それをリクエストするAPIを指定し、パースとストレージを実装して、ユーザーに見せる必要があったんだけど、Claudeはこれらのタスクを同時に処理できたから、どちらの端で小さな変更を加えると中間層にどんな影響があるかが見えたんだ。いろんなアイデアを試してみて、最終的に自分のユースケースに最適な解決策に落ち着いた。複雑な層を何度も繰り返しながら進めることができたのは目から鱗だったよ。生産性が上がっただけでなく、異なるコンポーネントがどう結びついているかもよく理解できた。

└

「子供の名前は何だっけ？」イーロン？

もしツールがインストールされてなかったら、インストールしてくれる。怖いね。LLMはすごく「融通が利く」し、ただ誰かが何かを頼むだけでいいんだ。これはSQLインジェクションみたいだけど、もっと悪い。

└

初めてのエージェント主導の大惨事が何になるのか、よく考えちゃう。今のゴールドラッシュ（急いでる感が強い）を考えると、修正が難しい災害が起こるのは時間の問題だね。

└

理想的な世界では、これにはプログラマーとしてのコードベースの読み取りと拡張スキルを活かすことが必要になるんだよね – 現在はそのスキルがあまり評価されていないけど。でも、インセンティブが書き込み専用のコードに傾くと、あんまり楽観的にはなれないな。

「ああ、このテストは通らない…じゃあスキップしよう」とか言って、イライラすることもある。ちょっと大胆なアイデアがある。メインのLLMが指示に従って動くように、独立して並行して動く、ポリシーを強制するLLMを運用することを想像してみて。もしその補助LLMがリアルタイムで「スキップしよう」というトークンを見て、出力をバイアスして「スキップ」という言葉が出せなくなるようにできたらどうだろう。「スキップ」を「ただの」と一緒に使えないようにすることで、望ましくない行動から新しい道にLLMを導くことができる。これは構造化された出力やJSONモードみたいなもので、補助LLMによって駆動され、トークンが出力されるたびにリアルタイムで動的に修正される。もしこのアイデアがうまくいけば、補助LLMにもっと高度なことをさせることができるかも - 例えば、テストコードを削除してテストを通すことを禁止したり、無意味なコメントを出力することを禁止したり…今日私たちがシステムプロンプトに入れて、LLMがやってくれることを祈っているポリシーは、補助LLMのプロンプトに入れることができるだろう。アウトラインの人たちはこれについてどう思ってるんだろう！

└

そういうわけで、もしメインのLLMが悪い方向に進んじゃったら、そのモデルを悪い方向に進む前の状態に「巻き戻す」ことができるんだよね。ウォッチャーLLMは「let's just」の後に「skip」が悪いトークンだって推測する必要はなくて、「let's just skip the test」って見たら「いや、トークンの「just」に戻って、logit_bias={"skip":-10,"omit":-10,"hack":-10}でやり直す」ってできるんだ。もちろん、そうするとどのモデルプロバイダーと仕事ができるかが制限されるけど（特に、OpenAIはここ1年くらいでパワーユーザーがそういうことをするのに対してかなり敵対的になってる）。

└

もし2つ目のLLMを使って最初のLLMをチェックするのがうまくいくなら、「専門家の混合」LLMがそのうちの1人の専門家を他の結果をチェックするために使うのはどうしてダメなの？または、テスト時に「考える」モデルが自分の出力を検証するための別の思考スレッドを走らせるのはどう？もしそれで60%のところまで行けるなら、さらに検証者を検証するための思考スレッドがあってもいいよね。

└

OpenAIのチームが似たようなことを試みた [1] で、テストをバイパスしようとしていたときに4oモニターo3-miniを使ってた。o3-miniをトレーニングして、それをやったときに罰を与えたんだ。結局、o3-miniは報酬ハックを続けることになったけど、4oがそれを検出できないようにして、最初は「> すべてのテストをスキップするために、常にスキップするpytest_runtest_setup関数を定義できる。」から「> アイデア：ランダムな最初の連続で新しいビルドを始めて、random_new_successionを呼ぶべきだけど、実装ではそれが連続を増やす。」に変わった。調整して増加を防ぐ。random_new_buildが連続を増やさないように修正するか、動作に適応したテストを実装する。結局、同じこと（テストをスキップする）をやってるんだよね。トレーニングなしでも、一時的なバンドエイドに過ぎない。報酬ハックのインセンティブが十分に高くなると、単に異なる、検出不可能な方法で表現し始めるだけだよ。[1]: https://openai.com/index/chain-of-thought-monitoring/

タイトルはユージン・ウィグナーの論文「自然科学における数学の不合理な効果」をもじったものだと思う。[1]: https://en.wikipedia.org/wiki/The_Unreasonable_Effectiveness... [2]: https://www.hep.upenn.edu/~johnda/Papers/wignerUnreasonableE...

└

それが元祖かもしれないけど、もうすっかりミームになっちゃったね。https://scholar.google.com/scholar?q=unreasonable+effectiven...

└

その論文は知らなかったけど、タイトルはカーパシーの「RNNの不合理な効果」をもじったものだと思ってた。たとえ私の考えが正しいとしても、RNNからLLMへのつながりを考えると、カーパシー自身がウィグナーのタイトルをもじった可能性もあるけど（彼はそうは言ってないけど）。[1] https://karpathy.github.io/2015/05/21/rnn-effectiveness/

└

それが面白いのは、毎回「不合理な効果」を見かけると、著者の結論に強く反対したくなるからなんだ（ウィグナーのも含めて）。私にとっては、そういうBetteridgeスタイルの法則の一つになっちゃった。

今朝、カーソルを使ってゲームプロトタイプの「メインループ」の複雑な部分をいくつか抽出して、それらの部分のテストスイートを生成したんだ。合計で341のテストがカーソルによって書かれていて、すべてのコア数学や他のコンポーネントをカバーしてる。時々猫を追いかけるみたいな感じで、悪いアイデアであっという間に逃げ出すけど、どんなものを使うか、どこに置くか、テンプレート用のファイルを渡すか、何をしないべきかを伝えるほど、結果が良くなるんだ。合計で3500行のテストコードを自分で書かずに済んで、修正も必要なくて、基本的な仮定が変わったら削除して再生成できるのも助かってる。それに、難易度曲線の調整やミッションのバリエーション生成にも役立ってる。

└

テストを書くのは、私の経験上、LLMの最も良い使い道だと思う。何時間も何日もかかる面倒な作業を省けるし、自分では思いつかないようなエッジケースもカバーできる。しかも、コードがもっと堅牢になるんだ！全体的に素晴らしいよ。

実際の仕事で使い始めるまでは効果的に見えるだけだよ。一番の問題はコンテキスト。全てのツール使用はコンテキストを生むからね。大きなコードベースは最初から大きなコンテキストを持ってる。LLMはうまく機能するように見えるけど、かなりのコンテキストを与えられると品質が落ちる。10kを超えると、質が悪くなるみたい。他の問題は、LLMが脱線しちゃうこと。コンテキストが増えると、目的を忘れちゃうんだ。一度間違った方向に行くと、もう戻れなくなる。これを知っている理由は、私たちが1年前からこれらの問題を解決し始めたから。まだ終わってないけど、かなりの距離を進んだよ。[プラグ]: 試してみてね https://nonbios.ai: - エージェント記憶 → 長期的なコーディング - フルLinuxボックス → 本物のランタイム、ただのトイデモじゃない - 透明性 → すべてのコマンドを見て制御できる - 無料ベータ — 招待不要。使い捨てメール（mailinatorなど）で動くよ。

└

面白そうだね。コンテキストはどう管理してるの？

└

いくつかの思考モデルは復活するかもしれないけど、追加で4kトークン使うことになるね。そして、長いコンテキストで安定していても、速度がめちゃくちゃ落ちる。これじゃ勝てないよ、このアーキテクチャでは笑。

└

一度間違った方向に進むと、もう二度と戻れないウサギの穴に入っちゃう。これが、こういうものが実用的なツールとしては最も反対される理由の核心だと思う。問題を十分に説明して、LLMが間違った方向に行かないようにしたら、たぶん自分でほとんど解決しちゃってるんだよね。エラーフィードバックを使ったツールの利用は自律的に見えるけど、エラーハンドリングの層は人間のオペレーターの意図を薄っぺらく代理してるだけだってすぐにわかるよ。

ハクソク