NISHIO Hirokazu[Translate]
Opusの大局観
>kenn 大きな開発では
>
> 人間 ←→ Opus ←→ Codex (←→ Cursor)
>
> の多重下請け構造がおすすめです
>
> Opusは意図を汲んだり本質をつかむのがうまい
> けどコードを書かせるとミスで手戻りが多すぎる
>
> Codexは実装を漏れなく実行するのがうまい
> けど詳細にとらわれて本質を見落とすことがある
>
> Cursorは大きな開発では無職になりがち

>kenn ただし
> なぜかプランはCodexのほうがトークン効率よく
> 広く深く短く書いてくれるので
>
> プランはCodexに書かせて
> それをClaudeにレビューさせる
>
> というのが一番うまくいってます
>
> Claudeのプランは詳細に踏み込みすぎるので
> ツッコミ役に徹したほうがうまくいきます

>kenn あと忘れてましたが
>
> Codexは「安全だが汚い」コードを書き散らかすので
> 最後にかならずClaudeでリファクタリングします
>
> クリーンアップはClaudeが得意
> しかしやはり自分で編集するとミスるので
> 指摘だけさせて実作業はCodex本人にやらせる
>
> とにかくClaudeは読んで考えるだけ
> docs意外は書かない

>izutorishima めちゃくちゃ同意だ・・・Opus は大局観を捉えるのがうまいが実装をやらせると遅い上にミスが多いので、大局的な全体設計とか人間サイドとのすり合わせ含めた要件決めは Opus と一緒にやって、決まったら Codex に抜け漏れをビシバシ指摘させて Codex に実装させて、そして要件を担当した Opus にレビューさせるとかなりうまくいく印象

>nishio いい表現、近い感覚を感じていたが「大局観」と言語化できてなかった


"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]