「Plan mode」はもう死んでいる

開発者から理解が失われていくのを、コードレビューがノーコメントのチェックマークにまで削られていくのを、そしてコードベースが誰にも読めない肥大化した混乱に陥るのを、私は積極的に目撃しています。エンジニアは出荷するコードを理解し責任を負わなければならない、といった公理が打ち壊されつつあり、出てくる製品はConwayの法則を反映して、不可解なまでに難解で、常に「複雑すぎて明らかな欠陥がない」（かつての目標だった「単純すぎて明らかな欠陥がない」とは対照的に）ものになっています。

plan modeが助けた唯一のことは、人間が戦略を理解し、設計やアーキテクチャをあれこれ見られるようにすることでした。ある程度の自制心とエージェントへの短い綱でこれを達成できますが、負け戦のように感じます。最高の開発者は依然として良いコードを出しますが、劣った開発者は何も学ばないまま、指標だけは素晴らしく見えます。私たちは膨大な負債を積み上げており、それがまもなく返済期限を迎えるのではないかと思わずにはいられません。

経験談ですが、Opus 4.6の頃は、plan modeを使ってアプローチを発見し、その後コンテキストをクリアして実行するということに何か特別なものがあるように感じました。

実装途中での壊滅的なコンパクション（突然物事が脱線する）に対する防御と、コンテキストが汚染される前に新鮮な実行で仮定を再確認し微妙な誤りに気づけるようにすることの混合でした。

十分に大きな変更については、親セッションが証拠に基づいて問題の根本原因を理論化し、その理論と具体的なテレメトリの例に基づいて修正するために的を絞った子セッションを派遣する方を今でも好むことに気づきました。

サンドボックス化されたコンテキストを持ち、一方が仕様に沿って集中して作業している間に、もう一方でアーキテクチャについて質問できるセッションがあることには、何かクリーンなものがあります。

機能やバグ修正の実装について自分のアイデアを起草するとき、私は人間でさえ最初に自分の意図を理解するとは信じていません。常に、私の側の誤りか、相手の側の誤った仮定のどちらかがあります。「これはXとYを考慮しているが、Zを考慮しておらず、それが全体を壊す」から「この部分のアイデアは以前あなたが言ったことと直接矛盾しているが、どうしたいのか？」まで、あらゆるものです。

人々がどんなに「良くなっている」と言おうと、LLMが人間よりも自分の意図をよく理解するとは信じられません。

TFAは普通の昔ながらのバイブコーディングを推奨しているように見えます。まずコードを書き、後で質問する。それは彼らの選択であり、多くの場合には有効な選択かもしれません。しかし、少なくともそれを正しい名前で呼ぶべきです。

plan modeが死んだ本当の理由は、エージェントにリポジトリを変更しないように、または選択したドキュメントだけを変更するように会話で指示すれば、それに従うからです。かつては選択したツール使用によってこれを強制する必要がありましたが、私たちはそれを超えました。

著者がチェックされていない、チェック不可能な大量のコードを受け取ることにためらいを感じなかったという点で、この記事は興味深かったです。これが出荷されるべきものだとしたら、これは受け入れられるべきではないと考えるのは、私が時代遅れなのでしょうか？人が読んでいないコード、ましてや書いていないコードを出荷するなどありえません。

簡単な世論調査です。ここでAIを使ってコーディングしている人のほとんどは、自分の言語／ソフトウェア開発に精通していますか？つまり、「手作業で」10年以上の経験がある人ですか？

10年後には、その10年の経験を持つ開発者は誰もいなくなると思います。

かつてCodex上であなたの製品に似たものを構築しようとして、失敗しました。

しかしplan modeについての私の結論は少し異なります。plan mode自体は行き止まりかもしれないという点には同意しますが、同じ目標を達成する別の方法があるかもしれないと今でも信じています。

製品を構築していたとき、最大の問題は能力ではなくセンスだと気づきました。エージェントは動くものを作れましたが、それはしばしば私が実際に望んだものではありませんでした。そしてその「センス」の背後には、膨大な暗黙のコンテキストがあります——好み、過去の決定、製品の直感、そして私の頭の中にあるトレードオフです。それをすべてコンテキストに蒸留するには多大な労力がかかり、単一のエージェントにすべてを与えると最終的には圧倒されるのではないかと疑っています。

より良いアプローチは、異なる役割、プロンプト、視点を持つ複数のエージェントを用意し、それらが効率的に協力する方法を見つけることではないかと考えています。

まだ仮説にすぎません。解決すべき複雑な調整問題がたくさんあり、まだ答えは出ていません。

私はおそらく時代遅れなのでしょうが、Claude Codeでplan modeをかなり使っています。私が望むものとほぼ一致するまで、計画を何度も反復します。良さそうになったら、計画を構築し、完了したらPRを開くよう頼みます。

plan modeに対する私の唯一の批判は、計画を反復する際にClaude Codeで更新や変更を簡単に見られるようにしてほしいということです。どの部分をレビュー済みで、どの部分が新しく（もう一度見る必要がある）かを覚えておくのは無駄です。これを修正しようと考えたこともありますが、レビューこそが実際の思考（たとえ非効率でも）だと感じているので、あえて削除していません。

私のツールにはProject Starterがあり、ユーザーをアイデアからtodoリストまで、いくつかの非常に具体的な段階を経て導きます。小規模から中規模のプロジェクトで1年間使っていますが、今でも私にはよく機能しています。

完成したプロジェクトができることを期待しないでください。むしろ初稿のようなものです。それができれば、何が機能し、何を変えるべきかを直接体験できるので、自分が実際に何を望んでいるかをはるかに容易に判断できます。

重要な注意点は、私はエージェントとは仕事をしないということです。各ステップはかなり厳格な手動レビュー段階を経ます。

まず計画なしで仕事をするなど想像できません。

第一に、何が構築され、それが賢明な方法で行われるかどうかについて、非常に明確な理解を得るための優れた方法だと思います。

多くの場合、最初に計画を立てるためにLLMと問題を探求するまで、作業がどのような形になるべきか実際にはわかりません。

計画がなければ、生成されたコードのコードレビューを通じて初期理解を行わなければならず、これは計画をレビューするよりはるかに難しく、その後必ずLLMにやったことを修正させる必要があり、コードを扱っているときは計画を扱うよりはるかに遅く、次に必要なレビューのことは言うまでもありません。

そして計画が十分に良くなったら、実行を指示する前にコンテキストをクリアします。これによりLLMの出力品質が大幅に向上することに気づきました。