プランモードは死んだ

今年の初め、私はプランニングがAIを使ったソフトウェア構築の最も重要な部分になると信じていました。この考えに対する私の信念は非常に強く、それに基づいてデスクトップコーディングアプリ全体を構築してローンチしました。Nuancedは、AIがコード生成の速度と量を劇的に増加させたものの、この新しい作業ペースをサポートするインターフェースがまだ追いついていないという観察によって動機づけられました。Nuancedのアプローチによるプランニングは失敗しましたが、それはまた、プランモードが一般的にそれほど有用ではなくなっていることを私に明らかにしました。歴史的に、プランモードは2つの目的を果たしてきました。(1) エージェントにとって十分に正確な指示を指定すること、そして(2) 人間が構築しているものを理解するのを助けること。私は、#1はモデルが改善するにつれて急速に時代遅れになっていると思います。私は、#2はこれまで以上に重要だと思いますが、プランモードはそれにとって間違った抽象化であり、特に私たちが実行する並列エージェントの数が増えるにつれてそうです。 なぜNuancedを構築したのか 私が構築する動機となった製品は、最終的に、依然として関連性があり、常にそうであろうという問いに答えました。それは、人間が機械が人間の検査速度よりも速く変更しているソフトウェアシステムの一貫したメンタルモデルをどのように維持できるかということです。モデルは数分で数千行のコードを書くことができるため、構築しているものやその理由を考える前に、すでに巨大なメンテナンスの負担を引き継ぐことになります。これにより、動作について推論し、コードに時期尚場に固定された誤った仮定をデバッグすることが困難になりました。この方法でコードを生成する容易さがより大きなドーパミン報酬を引き起こした一方で、なぜ何かを構築することが重要なのか、それがそもそも重要なのか、そして製品、設計、インフラストラクチャの決定を厳密に評価するという不快な作業を不明瞭にしました。私はしばしば、製品の決定を意識的に行う前に製品を手にしていました。アーキテクチャの指定が不十分だった場合、エージェントは、その抽象境界の切り方が後で問題を引き起こしたとしても、そのギャップを埋める自由を取りました。意図された動作と設計に関するこれらの誤解は、チャットの表面下の数多くのファイルに広がり、容易に見落とされる可能性がありました。この表面下で不可解な問題を探し回ることは、最初から正しく設計するよりも非効率的だと感じました。この経験には、特にConductorやCodexのようなコーディングアプリがより多くのエージェントを並列実行する能力を可能にしたため、精神的に断絶され、ゾンビのような感覚になる何かがありました。集中できず、以前のように作業していることについて同じ深さや理解にアクセスできないと感じました。これにより、生成された結果が正しいかどうかを確認することも困難になりました。ユーザープロンプト→エージェントの決定→コード→製品の動作の間の接続を示す明確で解釈可能なトレースがありませんでした。これは、コードの行を見たり、ファイルを見たりする昔に戻りたいという意味ではありませんでした。私は実際に、自然言語でアイデアについて推論することが、より簡単で効率的だと感じました。システムの仕組みを犠牲にすることなく、コードの上に自信を持って浮かぶことを望んでいました。 既存のプランモードは十分に協力的ではなかった プランモードは存在していましたが、うまく計画するための適切な抽象化が存在しないと感じました。Claude Code CLIからConductor、そして最終的にCodexがローンチされるまで、私は明確な場所を持たずに、計画を細心の注意を払って形成し、削り取っていました。チャットを使用し、次に計画の一部を新しいメッセージにコピーして改訂していました（Codexのアノテーション機能の前）。このコピー＆ペーストのワークフローはぎこちなく感じられ、現在の計画を把握しながらアイデアを検討するのが困難でした。私は自分の計画に場所を与え、それらを全体的なワークフローに根付かせ、会話が進むにつれてバックスクロールに消えていく一時的なテキストの塊から、生きた、呼吸する、永続的なドキュメントに変えたかったのです。私は、いくつかの理由で、プランモードを開発を導く第一級のプリミティブに変えたかったのです。何をすべきか考える必要がありました。それを十分に正確に説明する必要がありました。何がされたのかを理解する必要がありました。何かが間違ったときに、なぜ間違ったのかを理解する必要がありました。 夢を構築する 私は夢のワークフローについて考え、それを製品にエンコードすることで実現しようと決めました。Nuancedでは、スレッドを立ち上げることができました。各スレッドはチャット会話でした。何を構築したいかについて話し合い、システムは曖昧さとあなたの入力が必要な決定を提示し、一緒に実装が始まる前に永続的な計画に到達しました。その後、Nuancedはあなたの計画を実装し、生成されたコードがあなたの要件に準拠していることを確認しました。私は、意図から始まり、実装、レビュー、検証まで続くエンドツーエンドのパイプラインを望んでいました。私はそれを、単なる別のコーディングアプリというよりも、人間の心（または私のADHDの心）の補綴物として見ていました。それは、私が何が起こっているのかを把握するのを助けるのと同じくらい、指示するように設計されていました。 なぜ間違っていたのか 既存のツールのギャップやSDLCがどのように変化しているかについての私の考えが間違っていたというよりも、私たちの実装が期待したソリューションを提供できなかったということです。その理由は次のとおりです。 計画とプランを混同した モデルが非常に賢くなった 誰もAI生成テキストを読みたくない 計画と構築を破壊的な方法で分離した 計画 != プラン 最初に学んだことは、計画とプランを混同していたということです。それらは実際には同じではありません。私の仮定は、実装される前に何かについて徹底的に考えるためのスペースを持つことは価値があるということでした。また、その思考を大きな構造化された成果物に保存することは、プロジェクトが進むにつれて価値があると考えていました。しかし、初期のユーザーは、その仕様に対する関心が驚くほど低かったのです。 モデルが非常に賢くなった モデルがコンテキストとメモリを通じて大規模なコードベースを理解するのに長けるようになると、リポジトリを探索し、合理的な仮定を立てるのが得意になりました。よく考えられた結果を生成するように明示的に指示する必要性は縮小しました。私は当初、モデルの能力が人間の思考のためのより良いインターフェースを設計することと競合するとは考えていませんでしたが、多くの意味でそうでした。これは、モデルが自分で確実にできる各決定が、提示する必要のある決定が1つ減ったためです。 AI生成テキストは読むのがつらい 仕様には、より多くの明瞭さを生み出すことなく、より多くの情報が含まれていました。これは、私たちの仕様が長かったためです。それらは重要な決定を捉え、多くの有用に見えるコンテキストを含んでいましたが、問題は、それらがAIによって生成されたということでした。AI生成テキストのペースと過度に構造化された性質には、読むのが非常に困難になる何かがあります。私の目はうつろになっていきました。この発見に反応して仕様を破棄するのではなく、仕様ツアーを作成して解決しました。仕様全体を吸収するように誰かに依頼するのではなく、Spec Tourが重要な部分を歩き回ってくれるだろうと考えました。しかし、それは追加の複雑さのレイヤーを bolted on しただけで、画面上のさらに多くのテキストが注意を要求していました。仕様を使用可能にするために仕様の短い表現を生成する必要があるなら、そもそも完全な文書のポイントは何だったのでしょうか？ 連続して感じる必要のあるプロセスを分離した 私たちのワークフローは線形的で逐次的すぎました。私たちのプロセスは次のようなものでした。チャット→質問に答えることによる曖昧さの解消→仕様生成→仕様レビュー→仕様改訂→承認→実装→コードレビュー 実際の思考はこのようには起こりません。そして、これらの部分の間の分離は人工的で強制的に感じられました。通常、問題の一部を理解し、何かを試み、最初の生成が新しいことを教えてくれ、それによって考えが変わって何か別のことを試したくなるでしょう。各ステップは新しい質問を明らかにします。計画と