「Plan mode」はもう死んでいる
Plan mode is dead
AIコーディングアプリ「Nuanced」を開発した著者は、計画と実装を分離する「plan mode」がもはや有効でないと結論づける。モデルの性能向上により、エージェントへの精密な指示は不要になり、AI生成の長大な仕様書は読む気を失わせるだけだった。計画は文書ではなく、理解→実行→検査→調整を繰り返すプロセスに埋め込まれるべきだと説く。
私が犯した最大の過ちは、計画を「成果物」に変えてしまい、人間の理解を深めるプロセスを設計しなかったことだ。
HNでの議論
37- bcherny
[Claude Codeを開発しています] 著者の意見には概ね賛成です。plan modeはかつては有用でしたが、今はもう有用ではありません。
Claude Codeでは、plan modeがするのは各ユーザーメッセージに「あなたはplan modeにいます。まだコードを書かないでください」といった小さなリマインダーを追加することだけです。これは何ヶ月も前の日曜日の夜遅く、新しいセッションごとにコードを書く前にClaudeに一緒に計画を立ててほしいと頼むのに疲れたときに私が思いついたものです。おそらく気づかれていないことですが、plan modeは常にプロンプトに過ぎませんでした。ツールセットを変更したことは一度もありません。なぜなら、そうするとプロンプトキャッシュが壊れ、ユーザーにとって高コストになるからです。
これはしばらくうまく機能していましたが、数ヶ月前、Fableの初期バージョンを使っていて、私はもうplan modeを使っていないことに気づきました。モデルが単にそれを理解していたからであり、私がモデルに依頼する作業がますます複雑になるにつれ、計画は対話的かつ反復的になっていたからです。Opus 5.5では、Opusもその段階に達したと感じています。
コードベースの理解のために、私は時々Claudeに変更の特定の側面を説明するアーティファクトを生成するよう頼みます。システムの核心部分への複雑な差分については、変更や検討された代替案をよりよく理解できるよう、図や場合によってはインタラクティブなデモを作るよう頼むことがよくあります。頻繁ではありませんが、必要なときにコードを説明するのに便利な方法です。また、ClaudeにこれらのアーティファクトをPRに添付するよう頼みます。そうすれば他の人も理解でき、将来のClaudeにもコンテキストが残ります。
- bityard
機能やバグ修正の実装について自分のアイデアをまとめるとき、私は人間でさえ最初から自分の意図を理解してくれるとは信じていません。常に、私の側の誤りか、相手の側の誤った仮定のどちらかがあります。「これはXとYを考慮しているが、Zを考慮していないので全体が壊れる」から「この部分は以前言ったことと直接矛盾しているが、どうしたいのか」まで、あらゆるものです。
人々がどんなに「良くなっている」と言っても、LLMが人間よりも自分の意図をよく理解するとは信じられません。
TFAは普通の昔ながらのバイブコーディングを推奨しているように見えます。まずコードを書き、後で質問する。それは彼らの選択であり、多くの場合には有効な選択かもしれません。しかし、少なくともそれを正しい名前で呼ぶべきです。
- tcdent
plan modeが死んだ本当の理由は、リポジトリに変更を加えないように、あるいは選択したドキュメントだけに変更を加えるように、エージェントに会話的に指示するだけで、それが聞き入れてくれるからです。かつては選択したツール使用を通じてこれを強制する必要がありましたが、私たちはそれを超えました。
- bfung
反対です。今ではより多くのことを1発でできるようになったのは確かですが、コンポーネント間の相互作用がより複雑な場合、plan modeによる良い計画があれば、プロジェクトは「良さそうだ、進めよう」で一晩中実行できるものになります。一方、そうでなければ「ステアリング」が必要になります。
- nojs
Claude Codeのplan modeがゆっくりと非推奨への道を歩み始めたのは、「コンテキストをクリアして実装」オプションをフラグの背後に隠したときでした。当時の議論からすると、開発者たちはそれを主にレガシー機能と考えており、新しいモデルは長いコンテキストでもそれを必要としないほど賢いという見解のようでした。