多くのコーディングエージェントには、RAGまたは初期のエージェント時代に意味のある「モード」機能があります。現在、Amp (検索サブエージェント、一般サブエージェント、オラクル) や Claude Code (非常にクールなカスタム サブエージェント機能がリリースされたばかり) などのサブエージェントを追加しています。 モードは、重量級のコンポーザブル UI ドロップダウン メニューです。サブエージェントは自然言語 ("オラクルを使用して..."、"問題サブエージェントを使用して..."、または暗黙的に) を介して呼び出され、完全に構成可能であり、エージェント ツール呼び出しの概念モデルにきちんと適合します。 モードとサブエージェントは基本的に同じ目的を果たすことがわかりました。サブエージェントは厳密にはより良いソリューションです。 そのため、既存の「モード」機能を持つ前世代のコーディングエージェントは、サブエージェントを追加する際に、モードとサブエージェントの両方を残す(これは混乱して複雑です)、モードを切り取る(モードの作成に多大な労力を費やすため、ユーザーベースにとって苦痛です)、または「モード」の概念をサブエージェントも含めるように拡張しようとする(これも混乱を招くでしょう)。羨ましくない。 Amp チームでは、エージェント コーディングが将来どのようなものになるかを誤って判断し、苦痛を伴う製品変更を行う必要がある場合、このうらやましい立場に立つのではないかという致命的な恐怖の中で生きています。私たちは、Amp の前に構築した製品でこれらすべての間違いを犯してきました (そして、Amp でも大量の間違いを犯し、これからも犯します)。これが、新しいUIコンセプトを追加するための信じられないほど高いハードルを持っている理由であり、強い直感を持つチームメンバーを優先する理由であり、今日ではなく、6〜12+か月後にモデルと開発の中央値がどこにあるかを考慮して構築する理由です。この場合、この方向性が正しい決定に導いたと思います(モードなし、コンポーザブルサブエージェントのみ)。 幸運なことに、信じられないほど賢く、オープンマインドで先進的な開発者向けに構築することができ、彼らは頻繁に、そして基本的に伝書鳩を除くすべてのチャネルを通じてフィードバックを共有しています。私たちは皆さんの多くをよく知り、理解するようになりました。私たちは、あなた方や私たち自身が本当に「モード」を愛している人を見ることができませんでした。しかし、@thorstenballサブエージェントを構築し、次にオラクルを構築し、それらを使用するには、ドロップダウンから選択するのではなく、そう言うだけです(「オラクルを使用して...」)と言ったとき、それは私たちと皆さん全員にとって正しいと感じました。そこで彼に小道具を捧げ、未来を見据えてくれた素晴らしいユーザーに感謝します。 私たちがこのことについてどのように考えているのか、そしてなぜ私たちが物事に対して極端または硬直的に見えるのかについて、舞台裏で少し共有したいと思いました。 ...そして今週末、最も物議を醸している頻繁に無視されるフィードバック (FIF) の 1 つについて私が間違っていたことを認め、無視していないことが判明した大量のフィードバックのおかげで、それを変更する予定です。