Jevは単に性能のいい埋め込みモデル（を使った分類器）なのだから、そのまま埋め込み生成してベクトル検索に使えばいいのに、なぜわざわざ事前に時間をかけて特定クエリにしか使えないツリー構造に変換して使うのか意味わからん＞Decision RAG

ここしばらくKanbanやSuperpower等のスウォーム開発フレームワークの比較と評価を続けてて、結局は自分の用途に合った環境を自前で作り込むのがベスト、というよりそれが開発者の新しい仕事、という結論になりつつあるのだけど、その大きな理由がこの記事で触れられてたこの2つ。 "タスクを検証しやすくし、その結果から作り方を改善していくことが、ソフトウェアファクトリーの本丸" "人がどこで、何を見て判断するかに関心があります" 1) フレームワーク評価というメタな作業をしてると、それぞれの成功や失敗、不具合や改善点が見えてくるので、その原因や理由を定量評価する方法を確立して、フレームワークを継続的に改善していく仕組みをつくること。 2) 「エージェントによる完全な自律開発」は実はあまり面白くないない。むしろ、スウォームは「めちゃくちゃ効率的に調査と実装とテストとレビューをしてくれるピアみたいなもの」で、いま開発してるアプリにとっての最良のUXは何かをできるだけ効率的に「探索」したい、というのが自分がスウォームに求める性能。チーム開発の基盤というより、パーソナルソフトウェアファクトリーに近い位置付けにとても関心がある。 こうしてカスタマイズしたフレームワークがうまく動いてくれると、自分の思いついたアイディアや気になるリスクについてバンバン会話を始めて、issueを開いて、裏側で数十のスウォームが調査したりコード書いたり検証したりしてくれる。すると自分の集中力がある種のフロー状態に入って、以前のようにエージェントの返事の遅さにイラついたり、新しい考えを試す面倒さもなくなり、脳みそフル回転する感覚になる。これって何か呼び方あるのかな。

複数エージェントでスムーズに開発する体制を作っていくのは、なんだかエンジニア組織論みたいにな話になる。個々のエージェント間できちんと役割分担を定義してハーネスで誘導しないと、エージェント同士でやるやらないの議論を始めたり、ボールを落としたり、サボったりする。 それに、個々のモデルの特性と作業内容のマッチング。フロンティアモデルは賢いしけど簡単な質問にもすぐに答えられず待たされたり、エコノミーなモデルは仕事は速いけどサボりがちだったり。簡単で大量な実装やテストの作業は後者のサブエージェント小隊にやらせ、プロジェクト監査とレビューは前者に（参謀）、そしてQ&Aやissue起票は後者に（伝令）、という適材適所な体制になってきた。