LLMの使い分け術:フロンティアモデルは「ここぞ」という一発で使え!
You only need the frontier model for one single edit
You only need the frontier model for one single edit
全工程を高性能なフロンティアモデルに頼る必要はありません。本当に価値を発揮するのは、複雑な推論や最後の仕上げとなる「たった一度の編集」のタイミングだけです。それ以外の単純作業は、より軽量でコスト効率の高いモデルに任せてしまいましょう。
どうやら「/prewalk」は https://github.com/can1357/oh-my-pi に組み込まれているみたいだね。これって「Oh My ZSH?」のPi版で、必要なものが全部入りって感じかな。興味深いアイデアがいろいろ詰まってるけど、自分のワークフローにはまだ取り入れてないかな。使ったことある人いる?
シニアアーキテクトにジュニアエンジニア。最高に聞こえるだろ?
コンサルという名の食肉処理場って感じだな。Java Enterprise Solutionsを想像してみてくれ。まあ、ソフトウェアエンジニアリングの頂点(笑)ってやつだ。
最近はこんなバリエーションを試してる:メインのエージェントに段階的な実装計画を立てさせて、各フェーズごとにフォーカスを絞ったプロンプトで実装用サブエージェントを立ち上げ、その成果をメインセッションでレビューするっていうやり方。こうすればメインセッションにすべての調査結果を残しつつ、実装セッション全体のコンテキストを抱え込まずに差分だけを確認できるという理屈だ。
元の投稿にはコスト比較のレビューが含まれてないけど、個人的にはその場でレビューするほうがミスをたくさん拾える気がする。
この記事もGemini Flashで書かせたの?正直言って、読むに堪えないんだけど。
効率的なモデルを使うのは、タスク実行のコストが上位モデルを使うより安く済む場合に限定すればいいだけだよ。Fableならその指示に基づいたルーティングなんて余裕でこなせる。
私のワークフローも似たような感じだな。Fable 5 / Sol on Highに要件を設計できる状態になるまで話し合わせる。その後、設計をチケットに分割させるんだ。私はエージェント指向の課題トラッカーであるkataを使ってる。もし肥大化してきたら自分で作るつもり。大した機能は必要ないからね。とにかく、実装用エージェントが受け取れるように、各チケットに十分なコンテキスト(明確なユーザーストーリーやCucumberスタイルの受け入れ条件など)を含めるよう指示してる。
それが終わったら、小さいモデルに切り替えて「/goal」で kata ready を呼び出し、チケットを作業可能な状態にさせる。各ゴールのイテレーションでチケットを1つずつ片付けて、完了したらコミット。チケットがすべてクローズするか、自分待ちの状態になったら終了。
これ、めちゃくちゃ上手くいくよ。iOSアプリ丸ごと(比較的単純なものなら)月額20ドルの5時間セッション枠内で完成させられるし。
さらに良い結果を得るために、フロンティアモデルを使ったQAセッションで「実装スペック」と「Claude Design用の設計プロンプト」という2つの成果物を作らせることもある。そのプロンプトをClaude Designに通して結果を調整すれば設計スペックが完成する。計画を立てる時に、フロンティアモデルに以前の実装スペックと設計スペックの概要ファイルを読み込ませるんだ。
この方法だと、Fable 5とSolでA/Bテストをしても書かれるアプリはほぼ同じになる。いわゆる「サブエージェント艦隊を放つ!」系のコンテキスト管理よりずっと安上がりだよ。
まだフロンティアモデルの検証サイクルはループに組み込んでない。みんな「デカいモデルがドローンたちの成果をレビューする」みたいなフローの話ばかりするけど、受け入れ条件をうまくエンコードできれば、ドローンだけでも十分満足いく仕事をしてくれるよ。
「棒グラフが本棚になってて、背表紙にホバーするとカバーが見える」っていうあの最高にイケてる可視化手法、名前わかる人いる?これまで見たことがなくて。
「プランファイルを作らずセッションを新しくしてモデルを切り替える」っていうのを、かなり回りくどく言ってるだけじゃないかな。私はどのみちそうしてるし。
ただ、プランを読むのに時間がかかって休憩を挟むと、その間にキャッシュが切れてることが多いんだよね。そうなると最初からやり直す方がマシなこともある。
どのエージェント、どのモデル、どの足場を使おうと、料金は実質的にO(読み込み量)に依存する
つまり、トークンを売る側には、冗長で読みづらいコードを生成させるインセンティブが働いてるってことか。
私が「計画してから実装」の手順を踏むのは、計画なら調整がきくからだよ。いきなり実装させると、修正が難しい間違った判断を(よく)しちゃうし、後から直す羽目になるからね。