プランモードは死んだ

今年の初め、私はしばらくの間、AI でソフトウェアを作るうえで最も重要な工程は計画だと考えていた。

その考えにすっかり確信を持ち、それを中心に据えたデスクトップ向けコーディングアプリまで作り、リリースした。Nuanced の出発点はある観察だった。AI によってコード生成の速度と量が急激に伸びたのに、その新しい作業リズムを支えるインターフェースが追いついていない。

Nuanced の計画機能は失敗したが、おかげで、より広い意味での plan mode がすでにあまり役に立たなくなっていることもはっきりした。以前の plan mode には二つの役割があった。(1) agent がそのまま実行できるよう、指示を十分に正確に書くこと。(2) 自分が何を作っているのかを理解すること。

モデルが強くなるにつれ、1 は急速に陳腐化しつつあると思う。2 は以前にも増して重要だが、plan mode はそれを担うのにふさわしい抽象ではない。ましてや、並行して走らせる agent の数が増え続けている状況ではなおさらだ。

なぜ Nuanced を作ったのか

私が作ろうとしていた製品が最終的に答えるのは、今も成り立ち、これからも成り立ち続けると私が考える問いだった。マシンがソフトウェアシステムを変更する速度が、人間がその変更を確認する速度を上回ったとき、人間はどうやってシステムに対する一貫したメンタルモデルを保つのか。

モデルは数分で数千行のコードを書く。つまり、自分が何を、なぜ作っているのかを考える前に、巨大なメンテナンス負担を背負い込むということだ。そうなると、振る舞いを推論するのも、コードに早々に固定されてしまった誤った前提を追うのも難しくなる。

こうやってコードを生成するのは楽だし、ドーパミンの報酬も大きい。だが、本当に不快な作業を覆い隠してしまう。あることをやる価値がなぜあるのか、そもそもやる価値があるのかを突き詰めて考え、製品・設計・インフラの判断を厳しく評価する作業だ。私はよく、製品上の意思決定を自覚的に一切しないまま、製品を一つ手に入れていた。アーキテクチャを十分具体的に説明しなければ、agent は空いた部分を勝手に埋める。たとえそれが引く抽象の境界が、後で厄介なことになるとわかっていてもだ。こうした想定される振る舞いや設計に関する誤解は、チャット UI の下、複数のファイルに深く埋もれた経路を伝って広がり、見落としやすい。表面の下をかき分けてわかりにくい問題を探すより、最初から正しく設計したほうが効率がいい。

この経験は、精神が体から切り離されたような、生ける屍のような感覚を私に残した。特に Conductor や Codex のようなコーディングアプリで、より多くの agent を並行して走らせられるようになってからは。集中できている実感が持てず、以前と同じ深さで作っているものに向き合えなくなっている自分に気づいた。生成された結果が正しいかどうかを判断するのも難しくなった。

ユーザーの prompt → agent の意思決定 → コード → 製品の振る舞い、というこの連鎖には、読める形でたどれる痕跡がない。だからといって、コードを行ごとに読み、ファイルを一つずつ追っていた昔に戻りたいわけではない。むしろ、自然言語でアイデアを練るほうが楽で効率的だと感じる。システムがどう動くかの理解を犠牲にせず、コードの上を自信を持って航行したい。

今の plan mode は協働に向かない

plan mode は存在するが、計画に必要な正しい抽象が存在しないのだと思う。Claude Code CLI から Conductor、そして Codex のリリース後にそちらへ移るまで、私はずっと計画を磨き、削ってきたが、それを反復する定まった場所がなかった。やり方は会話の中で直し、計画の断片を新しいメッセージにコピーして修正するというものだった（Codex に注釈機能が付く前の話だ）。この切り貼りの流れは不格好で、アイデアを進めながら現在の計画を追いかけるのはかなり骨が折れた。

計画に居場所を与えたかった。それを自分のワークフロー全体に根付かせ、会話が進むにつれて履歴の中に消えていく一時的なテキストの塊から、生きた、持続するドキュメントに変えたかった。plan mode を開発を導く一級のプリミティブにしたかった。理由はいくつかある。

• 次に何をするかを考えなければならない。
• それを十分正確に説明できていると確かめなければならない。
• 何をしたのかを把握しなければならない。
• どこで問題が起きたのか、なぜ起きたのかを突き止めなければならない。

理想の製品を作る

私は自分の理想のワークフローを思い描き、それを一つの製品として形にすることにした。Nuanced では thread を作る。thread は一つの会話だ。作りたいものを説明すると、システムがその中の曖昧さと、あなたが決めるべき判断を洗い出し、実装に入る前に、一緒に持続的に進化する計画を固める。その後 Nuanced が計画に沿って実装し、生成されたコードが要求どおりであることを確かめる。意図から始まり、実装、レビュー、検証まで一気通貫のパイプラインが欲しかった。もう一つのコーディングアプリというより、人間の脳——というより私の ADHD の脳——の義肢だ。私を導くことと、物事の進み具合を見張ることの両方を設計目標にしている。

どこで間違えたか

既存ツールに欠けているものや、SDLC がどう変わりつつあるかについての判断を誤ったわけではない。私たちの実装が、思い描いた解決策を届けられなかったのだ。理由はこうだ：

• planning と plan を混同していた
• モデルが非常に強くなった
• AI が生成した文章を誰も読みたがらない
• planning と building を切り離したやり方が邪魔になった

Planning != Plan

最初に学んだのは、自分たちが planning と plan を混同していたということだ。この二つは別物だ。実装に入る前に徹底的に考えを巡らせる余地があり、その思考を構造化された大きなドキュメントとして残せば、プロジェクトが進むにつれて価値が出るはずだ——これが当時の前提だった。ところが、初期ユーザーのこの spec への関心は驚くほど低かった。

モデルが非常に強くなった

コンテキストとメモリを通じて大規模なコードベースを理解する力が高まるにつれ、モデルはリポジトリを探索して妥当な仮説を立てるのがうまくなった。指示に従って熟考した結果を明示的に出させる必要性は、縮んでいった。

モデルの能力と「人間の思考を助けるより良いインターフェースを設計する」ことが競合するとは思っていなかったが、多くの場面で実際に競合していた。モデルが自力で確実に下せる決定は、その分だけユーザーの前に出す必要のある決定が減るからだ。

AI が生成したテキストは読むのがつらい

この spec は情報量は増えたが、明晰さは増していない。spec が長すぎたからだ。重要な決定は記録されていたし、役に立ちそうなコンテキストもたくさん含まれていた。問題は、それが AI 生成だということだった。AI が書いた文章には、リズムや過度に構造化された感じに何かがあって、読んでいて非常につらい。目がずっと滑っていた。

これに気づいてから、spec をばっさり削るのではなく Spec Tour を作って対処した。ドキュメント全体を読ませる代わりに、Spec Tour が重要な部分を案内する、という発想だ。だがこれは上に複雑さを重ねただけだった。画面上で注目を奪い合う文字が増えただけだ。spec を使い物にするために短い版を生成しないといけないのなら、完全版のドキュメントはそもそも何のために存在するのか。

本来ひとつながりのプロセスを切り分けていた

ワークフローは直線的で、順序に縛られすぎていた。流れはおおよそこうだ：

chat → 質問に答えて曖昧さを解消 → spec を生成 → spec をレビュー → spec を修正 → 承認 → 実装 → コードをレビュー

実際の思考はこうは進まない。これらの段階の区切りは人為的で不自然に見える。たいていは問題の一部をまず理解し、少し手を動かしてみる。最初の生成結果から新しいことがわかり、考えが変わって別のことを試す。各ステップが新しい問いを露出させる。計画と構築は絡み合っていて、plan mode が許すよりずっと有機的に立ち現れる——Nuanced での私たちのやり方は特にそうだった。私たちのインターフェースは、ユーザーが早すぎるタイミングで「思考を終わらせ」、構築を始めるよう迫っていた。実装が始まってから chat ベースの推論に戻るのは、ワークフローの中を後ろに歩くような感覚だった。この滝に帰り道はない。

Codex の現在の働き方を見ると、計画と実行の境界は消えつつあり、一つになりつつある。以前は、コーディング agent は次のステップを人間が担う流れから恩恵を受けていた：

計画 → 承認 → 実行

当時は、間違った方向に進むコストがはるかに高かった。だが agent がシステムを理解するのがうまくなるにつれ、自律的に動き、自分の成果を検証するのも得意になっていった。結果を見てから考えを修正するのもうまい。そこで別のループが生まれる：

理解 → 行動 → 確認 → 明確化 → 調整 → 再び行動

このループの中でも計画は大量に起きているが、それは「計画」という名のドキュメントの形を取る必要はない。私の最大の誤りは、計画を成果物にしてしまったことだ。人間がより深く理解するためのプロセスを設計する代わりに。

Plan mode と build mode の区分けがおかしい

Nuanced には plan mode と build mode があり、ユーザーはどちらからでも始められる。plan mode は必ず spec を出力する。build mode は spec を書くことを強制せず、spec を書くほどでもない小さなタスクに使える。だがこの二つのモードの分け方がぎこちない。ユーザーはまずメタな問いを自分に投げかける必要がある——このタスクは計画する価値があるか——そして価値があるなら、ボタンかショートカットで plan mode を有効にするのを覚えていなければならない。この区別は、AI がすでに持っているコンテキストから判断してくれるべきものだ。どのモードを使うべきかを自分で覚えておくのは、認知負荷を増やすだけだ。

ここまで考えて、自分はあの midwit meme の真ん中の人だなと思った。チャットインターフェースで、デフォルトではなく必要に応じて計画する——この素朴なやり方が、実はかなり良い。

理解の問題は依然として未解決

何を作るか、なぜ重要か、意思決定をどう評価するかを考えることは、今も変わらず重要だ。人は自分が向き合っているシステムについて、一貫したメンタルモデルを持つ必要がある。だが、大量の AI 生成テキストがその適切なインターフェースだとは思わない。チャットで意思決定を練るほうが直感的に感じられるが、システムが変わったとき、その理解をどう最新に保つかは未解決の問題だ。

agent が5つから数百に増えれば、この問題はさらに難しくなる。キャッチアップするといっても、すべての会話を読んで、コードの変更箇所ごとに説明を求めるわけにはいかない。Agent は、人間の注意力が最大の影響を生む箇所を特定し、その注意力が実際に役立つだけの文脈を提示する必要がある。

何百、何千という、ますます高性能な agent が同時に一つのシステムを変更するとき、人が方向感覚を保つ方法を、私たちはまだ知らない。だが、より深い問題——人がシステムをどう理解し、複雑な情報階層をどう渡り歩き、強力なツールをどう使うか——は長期的に存在し続けると思う。インターフェースは常に、それを支える技術とともに変化してきた。複雑さを理解可能にするという要求は変わらない。