この記事に関係あるけど、AIとは関係ない話ね。コーディングの趣味プロジェクトが大好きだけど、プロのソフトウェアエンジニアじゃない私にとって、これらの設定ファイルや環境変数を維持するのは本当に疲れる。特に、ちょっとしたプロジェクトでもどんどん増えていくし、どれがどれだか覚えるのも大変だし、特定の設定を見つけるのも難しい。メカニズムも謎めいていることが多くて、実際に動くかどうかを手動でテストしないといけないこともある。実際のコードは、流れが明確だから読んでいるだけでロジックが理解できるのにね。他の人の設定ファイルを何も考えずにコピーするなんてできないし、各スイッチが何をしているのかも分からないから、プロジェクトを作るのが特に他の人のプロジェクトを真似するのがフラストレーション溜まる経験になってしまう。みんなはどうやってこれをうまく対処してるの？

LLM=trueよりも、静か/冗長な設定を標準化する方がいいと思う。これは冗長性の問題で、LLMは通常は静かにしておきたい場面が多いけど、常にそうとは限らないからね。次に、出力をキャッチしてキャッシュするためのヘルパーが必要だし、正直言って、普通のシェルやbashツールに出力をキャッシュして、フィルタリングして取得できるオプションがあればいいなと思う。コンテキストやトークンよりも、パターンに対するフラストレーションは、エージェントが異なる出力の行を取得するために時間のかかるタスクを再実行することが多いから。時には冗長な出力でツールを実行するのがベストな場合もあるけど、ツールが最初の実行時に必要なものを体系的にフィルタリングしやすい方法で出力を提供してくれたら嬉しいな。

それから、すべてのツールが無関係なコンテキストをstdoutに大量に出力して、コンテキストウィンドウを汚染していることに気づいたとき、まるでレンガが顔に当たったような衝撃を受ける。コンテキストウィンドウだけじゃない。あの無駄な出力の多くは人間にとっても完全に無意味だし、警告が無関係な出力の中に隠れていて、誰かが気づくまで何年も放置されることも珍しくない。

もう一つの受け入れられる解決策は、安いモデルで「ランナー」サブエージェントを作って、コマンドを実行して重要な部分をメインエージェントに伝えることだね。

そして、すべてのツールがcrazyな量の無関係なコンテキストをstdoutに出力して、コンテキストウィンドウを汚染していることに気づいた瞬間、顔にレンガが当たる。エージェントに自分で最適化されたスクリプトを書かせることで、これが本当に助けになることがわかった。Claudeは直接gradlewを使うことを禁止されて、私たちが作ったヘルパースクリプトだけを使えるようになった。それはクリアして、再コンパイルして、ローカルに公開して、テストして… すべていくつかの追加フラグで行われる。そしてテストが失敗したときは、スタックトレースが表示される。これ以前は、Claudeはたくさんの異なる呼び出しをしなきゃいけなくて、すべてがコンテキストを混乱させてた。テストが失敗すると、gradleが生成したHTML/XMLファイルを読み始めて、コンテキストがめちゃくちゃになったんだ。だって、そこにはたくさんのインラインJavaScriptが含まれているからね。最近は、ほとんどのアプリケーションでこの「LLM=true」みたいな動作を実装してる。LLMが使っているときは、ログがあまり冗長じゃなくて、重複もなくて、同じ行が何度も表示されないようになってる。 > 何かがうまくいかないのを見て、彼はtailを使ってスタックトレースをカットしたから、もっと大きなtailを使って再試行する。見たものに満足できず、さらに大きなtailで再試行して… 問題が見えてくる。まるで犬が自分の尻尾を追いかけているみたいだ。私も同じ問題を抱えてた。Claudeは5分以上のテストスイートを何度も続けて実行してたんだ、ただ最後に違う| grep somethingを付け加えただけで。今、私が作ったスクリプトは常に全体の（簡略化された）出力をログに記録して、テンポラリファイルのパスを表示するだけ。これがすごくうまくいくんだ。

人に何度も言わなきゃいけないのが不思議だけど、AIはあんまり変わらないよね。ツールは昔からいろんな出力があって、それをコントロールする方法もあったし、悪いツールはデフォルトでたくさん出力するけど、良いツールは "-v" のバージョンや簡単な grep の後ろに隠してる。--LLMとか追加するんじゃなくて、クリーンで一貫した冗長性コントロールを追加してほしいな。

このコンセプトには価値があると思うけど、今のLLMをターゲットにするのは短絡的だと思う。これは一時的な問題を解決するために、永続的な変更を加えようとしてる気がする。長期的に価値があるのは、簡潔で正確、かつあいまいでないオプションだと思う。これはLLMだけのために考えるべきじゃないよね。人間は時々、すぐに理解するために読みやすさを求めることがあるし、文脈を追加することで大きく助けられることもあるけど、時には正確さとあいまいさのなさが最重要になることもある（例えば監査のとき）。似たようなもののバッチを扱うとき、同じ文脈を繰り返すのは何の役にも立たないし、一度に見える量を制限しちゃう。だから、人間が直接読むためにこういう出力をリクエストできるのはメリットがあるよね。それに、今持ってる出力処理ツールの幅広さもあるし（まだawk使ってる人もいるし）。だから、これは必要だけど、数年後にはLLMには必要なくなるかもね。他の使い道は残るだろうけど。

テキストストリームを扱うツールのUNIX哲学、何かがうまくいかない限り「静か」にしておく、一つのことをうまくやる、などは、現代のAIコーディングエージェントにとても適しているよね。

なんでエージェントが出力をコンテキストに入れるべきかどうかを動的に判断できないの？ LLMに確認して、出力が重要そうかどうかを判断すればいいのに。重要じゃなければ、フル出力をローカルに保存して、プロンプトには簡単な要約とユニークIDを入れればいいじゃん。そうすれば、必要なときにフル出力を取り出せるツールも用意すればいいし。人間もそんな感じでやってるよね。ターミナルをスクロールして、無視できる部分をサクッと判断して、後で「これ全部のスタックトレース読まなきゃダメかも」って思い出すこともあるし。決定を下すのにフル出力を送る必要もなくて、「npm run buildの出力が500行で成功したけど、これ読む必要ある？」って送れば、会話の流れに応じてLLMが「はい」か「いいえ」で返事できるんじゃない？

ズームインするとスクロールが壊れるの、ちょっと気持ち悪い。