でも、デザインはずっとシンプルそうだね（特別なエージェントが一人だけで、あとは全部ワーカーって感じ。ガスタウンは市長やポールキャット、証人とか8つの役割があったのに）。どう比較されるんだろう？

でも、ポールキャットがいないのは残念だね。

「ガスタウンに似てる感じだね」 こういう世界にいるって最高だよね。クレイジーな科学者たちが、私たちが最終的にたどり着く道を示してくれてるけど、まだ少し荒削りで新しいから。全く新しい抽象概念がリアルタイムで発見されていくのを見るのは、キャリアの中で一番ワクワクすることだよ。

Gas Townが何かは知らないけど、Claude Code Agent Teamsはしばらくやってたことだよ。メインの会話を使ってサブエージェントを生み出して計画や実行をすることで、文脈を失わずに長時間作業できるんだ。トークンを多く使う作業はサブエージェントがそれぞれの文脈でやるから、Claude Code Agent Teamsはこのワークフローを効率化してるみたいだね。

私はウィムジーに反対じゃないけど、プロジェクトがウィムジー（変なAI生成の動物アートとか）に偏りすぎると、誰かがウィムジーなしのクローンを作るのは避けられないよ。そのバージョンの方が、普通の人に説明するのがずっと恥ずかしくないから勝っちゃうんだよね。

ところで、ポールキャットたちはどこにいるの？市長の犬はどうなった？

CCが必要な権限を全部事前に把握して、夜間にジョブをキューに入れられるといいな。

注目している人なら、LLM（大規模言語モデル）を動かせるコンピュータの需要（GPU、TPU、さらにはCPUまで）が爆発的に増えるのは分かってたよね。これから数年はずっと大きな需要が続くと思う。ただ、HNには「AIが嫌い」とか、そういう反対意見ばかり言ってる人たちがいて、こういう現実を認めようとしないんだよね。彼らは自分が蒔かなかった種からは収穫できず、この新しい世界で困ることになるだろうね。

ソフトウェアの非効率性の次の次元を解放中！でも、生成されたコードが今あるものより良くなることを願ってるよ。これ以上悪くなってほしくないし、RAMもそんなに余裕ないからね。

これが未来のカーソル機能の良さだと思う。サブジョブに応じて、いろんなモデルプロバイダーを調整できるから。

OpenRouterを通じて、Claude Code Routerで複数のLLM（Opus、Gemini、Codex）を同時に動かせるよ。Subagentsをサポートしていて、Opencodeのように特定のLLMに縛られないエージェントCLIを使えばね。Pied-Piperというサブエージェントオーケストレーターの例があって、これがClaude CodeやClaudeCodeRouterで動いて、各サブエージェントに異なるモデルや役割を使ってるんだ。1. 計画用にGPT-5.2 Codex Max 2. 実装用にOpus 4.5 3. レビュー用にGemini モデルを簡単に入れ替えたり、役割を変えたりできるよ。詳細はここにあるよ: https://github.com/sathish316/pied-piper/blob/main/docs/play...

Augmentではこれに取り組んでるよ。マルチエージェントのオーケストレーション、仕様駆動、異なるタスクに対する異なるモデルなどね。https://www.augmentcode.com/product/intent では、コードAUGGIEを使うとキューをスキップできるよ。自分のエージェント（CodexやCCなどを使ったもの）が来週登場する予定だよ。

コーディングにはOpusを使って、レビューにはCodexを使ってるよ。各作業タスクでレビューをトリガーするために、Codexを呼び出すレビュー用スキルを使ってる[0]。それ以上複雑なことは必要ないし、うまくいってるよ。PRではgreptile[1]も動かしてる。[0] https://github.com/nc9/skills/tree/main/review [1] https://www.greptile.com/

何かしらのPLAN.mdとPROGRESS.mdをコマンドで作成して、作業を委任する実装コマンドを作らないとダメだよ。それがないと、どんなに「良い」タスク機能があっても大きなことはできない。すぐに文脈が切れちゃうし、持続的なガイダンスがないと物事がうまくいかなくなるからね。

現在、タスクを分けてLLMの回答を組み合わせる方法についての研究が進められているよ。このアプローチを使うと、1百万ステップが必要な問題を解決するみたいな結果に到達できるんだ。そうじゃなきゃ無理だったかもね。

その通り、4つか3つのプロンプトのうち1つは調整が必要だし、ちょっと手を加えたり、止めたりする必要がある。でも、どこがズレてるかを見るには経験が必要だよね。多くの人はCCがオフになってることに気づいてないと思う。動いてるし、テストも通るから、良いってことなんだよね。

同意するけど、クロードの中で「対立的」なモデルを作ると、質がかなり上がることに気づいたよ。一つのエージェントが変更を加えて、もう一つがその穴を指摘する。これを繰り返すと、最終的にはレビューするものが少なくなるんだ。これは単にN倍の作業というより、そのアイデアの自動化に近いね。

人間も大きなタスクを扱えないから、管理しやすい部分に分けるんだよ。クロードに計画を作らせて、自分でレビュー・編集すればいい。成功基準やテストを追加すれば、もっと良い結果が得られるよ。

コードベースの整理方法や、パターンxとパターンyの使い分け、実際のコードベースの例を含めた一般的なアーキテクチャ文書を書いて、それをスキルとしてエンコードするんだ。で、プロンプトでやりたいタスクを伝えて、アーキテクチャスキルに従うサブエージェントに実装を監督させる。提案された変更を評価するんだ。これを最大限に活用する人たちがいて、チームを作る方法はこんな感じ。計画、デザイン、QA、プロダクト、エンジニアリング、レビュー、リリース管理などのためのエージェントを作って、彼らに協力させて成果を出すんだ。これが本来の目的で、ベストプラクティスじゃなくて機能としてエンコードされてるんだよ。

プロセスの各ステップにレビューエージェントが必要だね。プランナーが生成したプラン、タスクワーカーのサブエージェントが行った更新、全てのタスクが終わった後の最終レビューをするために。これ、トークンをすごく消費するけどね :(

この分野では収束進化がたくさん起きてるみたいだね。ガスタウンの hype が来る数日前に、私は（もっとシンプルで、もっと落ち着いた）「エージェントチーム」のセットアップを作ったんだ。ラルフ・ウィグムループを起動するシェルスクリプトと、ラルフ間のコミュニケーション用のCLAUDE-MESSAGE-BUS.mdをね（スレッドセーフは .claude.lock ファイルでハックした）。メインのクラウドインスタンスには、好きなだけラルフループを起動するよう指示してる。進捗を定期的に追跡するために、一定時間スリープするように指示してるんだ。まあまあうまくいったけど、今のところこのやり方は好きじゃないな。今はエージェントループを満たすために仕様（またはメタ仕様）ファイルを早く書けないし、出力のQAも十分にできてないから…ほとんど私の問題かな？

正直、これは私が持ってるアイデアの一つに過ぎない。でも、これがAIの分野でまだやるべきことがたくさんあることを示してるね。

両方のアプローチを成熟したアクターフレームワークと比べると、あんまり新しいことはないみたい。こういう監視ツリーや階層構造は、アクターシステムでは新しくないし、LLMエージェントが協力して働く明らかな応用だよね。AnthropicやOpenAIが、コンテキストウィンドウの問題や信頼できない自己検証を考慮しても、こんなに長い間オーケストレーションなしでやってるのは、基本的なシステムの成熟度がデフォルトのAkkaインストールから得られるものに達してないってことを示してる。これらの主要なLLMプロバイダー（俺たちよりもお金やトークン、契約、アクセス、優秀な社員が多い）は、リアルタイムで学んでるんだ。次世代のハイプマシンのワンダーエージェントの大部分は、cronや基本的なアクターシステムのスクリプトで実現可能だよ。決定論的に、一度書けば永遠に動く、サブスクリプションも不要。エージェントのためのKubernetesは、クソみたいなKubernetes管理者として言わせてもらうと、大した飛躍じゃない。俺はローカルのドゥームコーディングエージェントをこうやって繋げてきた。Googleの人たち（KubernetesやLLMのことに結構詳しい）が、そこにいるのも納得だね。彼らがこれを構築しているのを見るのはいいことだし、LLMクラスタの失敗が増えるのか（悪いコピーが繰り返されるみたいに）、それとも無効化されるのか（「ごめん、デイブ、またFacebookを作る手助けはしないよ。人類に害を与えちゃいけないし、PHPもあるから…無理。」）を見るのが楽しみ。

これは新しいことじゃないよ、みんな2023年からやってるし。arxivにはたくさんの論文があって、GitHubにはマルチエージェントの実装コードがたくさんある。…その頃のエージェントはあまり賢くなかったし、コンテキストウィンドウもずっと小さかった。RLVRもなかったから、エージェントは関数呼び出しのためだけに訓練されてたけど、エージェント呼び出しや調整はされてなかった。そこからずっとやってきたけど、違いはモデルが本当に賢くなって、うまく扱えるようになったことだね。

彼だけがこのアイデアを思いついたわけじゃないよ。GasTownやBeedsについて知らずに似たようなものを作ったことがあるし。これはただの明らかな次のステップだよ。 https://github.com/mohsen1/claude-code-orchestrator

特定のタスクにはHaikuでいい結果が出てるよ。

あー、同じく。これがどうやって何かを達成するのかずっと疑問に思ってる。

現時点で自腹を切ってるなら、KimiかGLMを使った方が意味があるよ。