Fable 5が使えなくなる前に、その「働き方」をOpus/Sonnetに引き継がせた

前回、Fable 5をトークン破産させずに使い倒す方法について書きました。 簡単にいうとオーケストレーターに Fable 5をおいて、スコープ切り、設計、委譲、最終レビューを任せ、手を動かす実装・テスト・シッピング・コードレビューは Opus と Sonnet のサブエージェントが担う形式です。高いモデルが計画と判断を、安いモデルが実行を受け持つ構成です。これはかなりのタスクでうまく回っていました。 ただ、みなさんご存知の通り、サブスクでのFable 5 アクセスは7月7日で終わります。（近い将来またサブスクに戻ってきてくれることを祈ってはいますが・・・🙏） 追記: 7/12までに伸びましたね！このままずっとサブスク範囲で使わせて欲しい・・🙏 オーケストレーションの仕組み自体はFable 5がなくても動くとはいえ、やはり最上位でスコープを切っていたオーケストレーターのモデルが下がれば、

[jintrick]

"Opus/Sonnetでありがちなミスはいきなり書き始めることです" → それ役割分担してないのでは。こりゃ問題意識のレイヤーが全然違うかもw

[doko]

ほらー、GPTにこんなこと言われちゃうよー「それ、Fable 5の知性の話ではなく、LLMを複数役割で使う普通の運用設計の話ですよね。」

[misshiki]

Fable 5の働き方をOpus/Sonnetに継承する試み。ccteamsでworking methodとplaybookを整備し、作業ルーティン、失敗パターン、検証、学習ループを明文化。

[hirrrose]

fableのようにsonetを動かす

[n314]

下位モデルのズレた調査に基づいて上位モデルで注意深く計画したら、とんでもなくズレた複雑な仕組みが出来上がる。サブエージェント無しの方がマシなくらい。というのが実感としてある。

[somaria3]

たぶん無駄っす

[mkusaka]

Fable 5の働き方をccteamsでOpus/Sonnetに移植。5つの軸とVERIFIED/REASONED/ASSUMEDで検証を強制する

[morimarii]

意味不明