あなたが挙げた参考文献は、今となってはちょっと古いね。8月のトークに基づいてるから、新しいモデルが生産性に大きな変化をもたらした「前の時代」のものだ。私が見つけた重要な変化は、オーケストレーションに関することだね。TFAが言うように、自分でプロンプトを実行するわけじゃない。オーケストレーターが全体を動かすんだ。建築家やプランナーと話をさせて、その計画の出力を別のエージェントに自動的に送る。彼の場合、建築家、開発者、いくつかのレビュアーを使ってるみたい。私はSuperpowersベースのオーケストレーションシステムを使ってるんだけど、ブレインストーミングからデザインプラン、実装プラン、開発者、レビュアーを経て、進捗と正確さをチェックするために実装プランに戻るんだ。実際、楽しいよ。40年以上コーディングしてるけど、今は楽しんでる :)

専門的なサブエージェントに分けることについては、確かに大事だけど、最初は分ける基準が明確じゃないんだ。私たちが見つけたのは、タスクの複雑さではなく、副作用のドメインで分けること。読み専門の「リサーチャー」エージェントと、出版専門の「ライター」エージェントは、片方だけが不可逆的なアクションを持つから、自由にコンテキストを共有できる。読み書きを一つのエージェントに混ぜると、再起動の安全性を考えるのが難しくなる。もう一つの実用的なことは、別々のコンテキストウィンドウを持つ別々のエージェントが、真に並行しているグラフの部分を扱うときに大いに役立つってこと。大きなエージェントは、並行化できる作業を直列化しちゃって、遅延が全体のパイプラインに影響を及ぼすんだ。

LLMは何でも作れる。真の問いは、何を作る価値があるのか、そしてそれがどう届けられるかだ。それがまだ人間の役割なんだ。LLMは人間でないがゆえに、人間を他の人間ほど理解できない。（セラピストとしてLLMを使おうとしたすべての試みを見てみて）要するに、LLMは最終的にはソフトウェアを設計できるようになる。でも、まだただのツールに過ぎない。

じゃあ、私たちの使い道は何？ 新しい経済的な価値を見つける必要があるよ。それが技術進歩の現実なんだ。技術やホワイトカラーの業界は、自分たちにもそれが来るとは思ってなかったんだろうね！時代遅れになったスキルは、当然役に立たない。今日でも、工業規模の生産の中で手作りの品には需要があるから、コーディングでも同じようなレベルがあると思う。

他の人たちがすでに部分的に答えてるけど、私の20セントを言わせてもらうね。ソフトウェア開発は本当に建築に似てる。最終的な結果は、異なるタイプのコネクタ（道路、グリッド、APIなど）を持つユニークなモジュールのインフラなんだ。これまでのソフトウェア開発では、計画を立てたりコネクタの種類を決めたりするのは、ほとんど同じ人たちがやってた。リアルエステートの建築家も、彼らを助けるためにたくさんのソフトウェアツールを使うけど、最終的には人間のニーズを理解し、何年も勉強と実践を経て、全体の建物やインフラがどう機能するかを理解している人が必要なんだ。そして、その人は最終結果に対して責任を持ち、結果の複雑さや質に応じて報酬を受けることになる。だから、確かにソフトウェアエンジニアはそれほど必要なくなるけど、残る人たちは複雑でやりがいのある問題に取り組んで、さらにフロンティアを押し進めることになるだろうね。

何の証拠があるの？ ソフトウェアエンジニアが使うものの証拠って何？ テスト、型チェック、構文ハイライト、IDE、コードレビュー、ペアプログラミングとかさ。俺の経験では、ソフトウェアエンジニアリングの実践の効果に関する証拠は二つのカテゴリーに分かれる。 - 開発者の直感、彼らの経験に基づいている。 - 科学的な研究、でもそれは説得力がない。生産性を測ろうとする研究もあるけど、実際のソフトウェアエンジニアの生産性を測るのは難しいから、マネージャーの評価みたいな質的な指標や、LOCやクローズしたチケット数みたいな意味のない量的な指標に頼るしかない。他の研究は、実際のソフトウェアエンジニアリングとは全く異なる特定のタスク（例えばコーディングパズル）に対して実践を測っているから、説得力がない。このLLMパターンの証拠も同じ。ある開発者は、うまくいくという直感を持っている。

分けるのは意味があると思う。異なるエージェントに具体的なプロンプトと孤立したコンテキストを与えるためにね。「アーキテクト」はコードスタイルガイドをコンテキストに持つ必要はない。それは実際には誤解を招く可能性があって、アーキテクチャから逸れてしまう情報を含んでいるかもしれない。

カーゴカルト的な現象が多いけど、こういう状況では避けられないよね。真実がモデル依存で、常に変わっているから、人々はAIの使い方を教えられるという前提で会社を作ってしまった。

これは経験談だけど、数日前に同僚と一緒にちょっとした実験をして、その証拠を集めたんだ。異なるペルソナ（アーキテクト、ビジネスアナリスト、セキュリティ専門家、開発者、インフラなど）を持つエージェントの階層を使って、要件を分析させて、リクエストを議論させて解決策を導き出した。彼らはプロジェクトのソースコードにアクセスできた。で、同じ入力を、ペルソナの定義を含めてClaude Codeに直接渡して、結果を比較したんだ。エージェントたちの協議は、約12ドルかかって、主にOpus 4.6を使ってかなり良い結果に至った。驚いたことに、Claude Codeに単一のプロンプトで直接渡したら、似たような良い結果が得られて、しかも早くて0.3ドルで、主にHaikuを使っていた。これはもっと調査する価値があるけど、今のところの仮説は、エージェント間の調整とコミュニケーションにはかなりのコストがかかるってこと。もしそうなら、個人的には驚かないな。 - 人間が仕事を分ける理由は、限られた能力があるからだよね。必要な分野で専門家になることはできないし、良いアーキテクトやビジネスアナリスト、セキュリティ専門家になるための知識を身につけることはできない。どうやら、LLMにはそれが問題じゃないみたい。だから、仕事の分け方は人間には必要なパターンだけど、LLMにはそうじゃないかもしれない。 - 仕事の分け方には高いコストがあって、スケールしない。特に、人間の組織では調整に関する問題が多いし、組織が大きくなるほどプロセスのコストが高くなって、最終的には官僚主義に変わる。IT企業では、グループ間のインターフェースに多くの問題があって、低帯域幅のコミュニケーションや言語の曖昧さが原因だ。単一のLLMが自分自身とコミュニケーションを取る方が、エージェントの協議よりもずっと良くて安いのは驚きじゃない。