AIでソフトウェアを書くとき、まず計画を立てるべきか、それともとにかく作り始めるべきか。Ayman Nadeem のこの文章は、その問いに対して自分の考えがどう変わったかをかなり率直に書いている。彼は今年前半、計画こそがAI時代の開発で最重要になると信じ、その思想を前提にしたデスクトップ向けのコーディングアプリ「Nuanced」まで作った。ところが実際に使われてみると、Plan mode は期待した役割を果たさなかったという。この記事は、単なる製品の反省文ではなく、AIコーディングツールが「計画」をどう扱うべきかという設計論にも踏み込んでいるので、今読んでおく価値がある。
Ayman Nadeem は、AIによってコード生成の速度と量が一気に増えた一方で、それを支えるインターフェースが追いついていないと見ていた。そこで作ったのがデスクトップのコーディングアプリ Nuanced だった。彼の問題意識は、機械が人間よりずっと速くコードを増やしていく状況で、人間がソフトウェア全体の理解を失わずにいられるのか、という点にある。数千行のコードが数分で生成されれば、作る前に「何を作るのか」「なぜ作るのか」を詰め切れないまま、保守負債だけが先に積み上がってしまう。
彼は当初、計画には二つの役割があると考えていた。ひとつは、エージェントに対して十分に明確な指示を与えること。もうひとつは、人間が何を作っているのかを理解する助けになることだ。だが、モデルが賢くなるにつれて前者の重要性は下がっていく。大規模なコードベースを文脈や記憶を使って読み解き、かなり妥当な判断まで自力で進められるようになったからだ。逆に、後者、つまり人間の理解を支える役割はむしろ重要になった。ただし、彼は Plan mode という形ではそれをうまく実現できないと気づく。
Nuanced の体験では、プランは長くなりすぎ、しかも AI が生成した文章は読みづらかった。Spec Tour という案内機能まで作ったが、結局は「長い説明文を、別の長い説明文で案内する」形になってしまった。さらに、実際の開発フローも、チャットで質問に答え、仕様を作り、それをレビューし、承認し、実装し、またレビューするという直線的なものだった。しかし彼は、実際の思考はそんなふうに段階的ではないと言う。理解と実装は行き来しながら進むのに、Plan mode はそこでいったん思考を終わらせてから次へ進むよう、ユーザーを押し込んでしまう。
彼はまた、Plan mode と Build mode を分けたことも失敗だったと振り返る。タスクに計画が必要かどうかをユーザー自身が判断し、必要ならボタンやショートカットでモードを切り替えるのは、むしろ認知負荷を増やした。結果として彼がたどり着いたのは、計画を文書として固定するより、会話と実装がひとつの循環としてつながるほうが自然だ、という考え方だった。要するに、Plan mode が死んだのは、計画そのものが不要になったからではなく、計画を「独立した成果物」として扱う発想が合わなくなったからだ、という主張である。
この記事でいちばん面白いのは、著者が Plan mode を否定しているようで、実は計画そのものを捨てていない点だと思う。彼が失敗だと認めているのは、計画を固定された文書にしてしまったことだ。ここは重要で、AIコーディングの現場で本当に欲しいのは「文書」ではなく「思考の足場」ではないか、という話になる。人間は、書類を読むために開発しているわけではない。決め切れない点を少しずつ減らしながら、いつでも戻れる状態で前に進みたい。その意味で、計画を永続的な spec にしてしまうと、むしろ思考が固まりすぎる。
これは、いまのAIツール全般にある「説明の過剰生産」ともつながる。モデルは理由をそれっぽく整えるのが得意だが、その整い方が人間の理解を必ずしも助けない。むしろ、きれいに整いすぎた文章ほど読む気を削ぐことがある。著者が「目が滑る」と書いているのは、かなり正直な感想だろう。私も、AIが作った長い仕様書は、内容が正しいかどうか以前に、読書体験として疲れることがあると思う。だから、今後のUIは「もっと書かせる」方向ではなく、「必要な分だけ見せる」「必要なときだけ戻れる」方向に進むべきではないか。
著者の主張で印象的なのは、モデル性能の向上を「計画の価値を上げるもの」ではなく、「計画という作法の価値を下げるもの」と見ているところだ。これは直感に反するが、かなり筋が通っている。モデルがコードベースを理解し、自分で試して、自分の出力を見て修正できるなら、人間が最初に細かい計画を全部書く必要は薄れる。人間の仕事は、先に全部決めることではなく、どこで注意を向けるかを見極めることへ移っていく。
ここで大事なのは、著者が「理解の必要」まで否定していない点だ。むしろ逆で、理解の問題はまだ解けていないと強く言っている。エージェントが5個から100個、200個へ増えるほど、会話を全部読むことは現実的でなくなる。だからこそ、人間が介入すると効果が高い場所を、システム側が絞って見せる必要がある。これは単なる開発効率の話ではなく、認知の設計の話だと思う。AIが強くなるほど「人間が全部わかること」は諦めるしかないが、「人間が要所を理解できること」は諦めてはいけない。その間を埋める仕組みが、いまのツールには足りない。
もうひとつ引っかかったのは、著者が「plan → approve → execute」という昔の流れと、「understand → act → inspect → clarify → adjust → act again」という新しい流れを対比している点だ。これは単なる操作順序の違いではなく、AI時代の開発がウォーターフォール型の一直線から、観察と修正のループへ移るという見方だ。実際、モデルが自分で試し、結果を見て方針を変えられるなら、人間が最初に承認ボタンを押すこと自体の意味は薄れる。
ただし、私はここに少し注意も必要だと思う。ループが自然になるほど、逆に「どこで止めるか」が難しくなるからだ。人間が計画を読まなくてよくなるのは楽だが、その代わりに、知らないうちにどんどん変更が進む危うさも増す。だから Plan mode が死んだとしても、完全な無計画でよいわけではない。必要なのは、文章としての計画ではなく、変更の意図・影響範囲・検証結果を短く追える可視化だろう。著者の問題提起はそこまで含んでいるように読める。
Nuanced の失敗談は、実は開発ツールに限られた話ではないと思う。AIを使うあらゆる仕事で、「詳しい説明を保存すること」と「人が状況を把握し続けること」は別問題になっている。長い要約、長い議事録、長いプロンプト、長い仕様書。どれも生成は簡単でも、運用は意外と難しい。著者が言うように、複雑さをそのまま文書化しても、複雑さが理解しやすくなるとは限らない。
むしろ必要なのは、複雑さを減らすことではなく、複雑さの見え方を変えることだと思う。大きなドキュメントを一つ置くより、会話の中で少しずつ決め、変更点だけが自然に浮かぶ形のほうが、人間には向いているのではないか。Plan mode が死んだ、という刺激的なタイトルは、計画不要論を煽るためではなく、「人間が理解できる形で複雑さを扱うUIはまだ足りない」と言っているのだと受け取った。
