ポストIDEの時代

JetBrainsの年間サブスクリプションを、つい先ほど解約した。

数年前の私には、ほとんど考えられないことだった。IntelliJをはじめとするJetBrains製品は、まさに喜んでお金を払いたくなるソフトウェアだった。強力で洗練された開発ツールに豊富な機能が詰め込まれ、大規模なコードベースの記述、移動、リファクタリング、デバッグを格段に楽にしてくれた。長い間、私にとってソフトウェア開発はIDEの中で行うものだった。

問題は、今ではほとんどIDEを開かないことだ。

ソフトウェアを作らなくなったわけではない。むしろ、今はこれまで以上に多くのソフトウェアを作っていると思う。変わったのは、IDEを介してコードベースに触れることが減った点だ。私はOrgabotなどのエージェント実行環境を使い、欲しいものを説明する。あとはエージェントにリポジトリの調査、関連コードの追跡、ファイルの変更、テストの実行、失敗の修正、実装のレビュー、プルリクエストの作成、競合の解消を任せ、そのまま作業を進めてもらう。

私の主なプログラミングインターフェースは、ソースコードで埋まったテキストエディターから、意図を伝える会話へと徐々に移ってきた。自然言語が、私のコーディング言語になったのだ。

IDEは複雑さに向き合うためのインターフェースだった

何十年もの間、IDEはソフトウェア開発のコックピットだった。コードベースが大きくなり、言語が高度になるにつれ、単純なテキストエディターでは足りなくなった。開発者には、シンボルへの移動、賢い自動補完、静的解析、リファクタリングツール、デバッグ、テスト実行、データベースの閲覧、バージョン管理との統合、依存関係管理など、何十もの便利な機能が必要だった。

IntelliJのような製品は、その問題を驚くほどうまく解決するようになった。私自身が一日中コードベースを操作していた頃、それらの機能には支払うだけの価値があった。ただ、少し俯瞰すると、IDEとは結局、大量のソースファイルを人間が理解し、操作するための道具なのだ。

エージェントによる開発は、その操作を誰が行うかを変える。

コードベースは今もある。コンパイラーもある。Git、テスト、リンター、型システム、デバッガー、パッケージマネージャー、ビルドシステムが消えたわけではない。変わったのは、それらを直接操作するのが私ではなくなりつつあることだ。操作するのはエージェントだ。

もうコードを読む必要はあるのか？

コードを見る必要がほとんどない。この気づきが、最終的にJetBrainsの解約につながった。私はもう「コードを書く」ためにIDEを開くことがほとんどない。実装が気になってファイルを見ることはある。ごく小さな変更を手で加えることもある。差分を見たり、特に奇妙な問題を追いかけたりすることもあるだろう。

しかし、それらはもはや主な作業ではなく例外だ。テキストを確認するだけなら、基本的なエディターで十分である。たまにソースファイルを手動で開くために、数GBのIDEと年間サブスクリプションは必要ない。

以前IntelliJで頼っていた機能の大半は、今も重要だ。賢いコードナビゲーション、リファクタリング、テスト、静的解析、コードレビューは今でも欲しい。ただ、各ツールを自分で操作するのではなく、エージェントにそれらをやってほしいと思うようになった。

ツールは消えていない。私が時間を過ごす抽象化レイヤーの下に移ったのだ。

念のために書いておくと、ここで述べているインターフェースは文書化されています。Claude Codeはターミナルからのエージェント的なコーディングを中心に設計されていて、エディターのウィンドウを中心にはしていません。

自然言語がプログラミングインターフェースになりつつある

プログラミング言語は、程度の差こそあれ、機械を人間にとって理解しやすくしようとしてきた。機械語やアセンブリから離れるにつれ、言語は次第に意味を表現するものになった。意味のある名前を持つ変数、動作のように読める関数、現実の概念をモデル化するオブジェクト指向の構造、そして必要な命令をすべて並べる代わりに、欲しい結果を記述できる宣言的な言語が登場した。

それでも、あくまでプログラミング言語だった。

30年前に、いつか一日のかなりの時間を、コンピューターに普通の英語で話しかけたり入力したりしてプログラミングするようになると言われたら、私はSFのたわごとだと思ったはずだ。だが、今の私は本質的にそれをやっている。

もちろん、英語が文字どおりTypeScript、Python、Go、Javaなど、最終的にシステムを実装する言語に置き換わるわけではない。私のCPUが、エージェントに書いた一段落を実行するわけでもない。しかし、人間側から見た技術スタックでは、その区別の重要性が薄れつつある。

プログラミングとは常に、人間の意図を機械が実行できる形へ翻訳することだった。そして私たちは、その翻訳の人間側を、繰り返し高い抽象度へ引き上げてきた。かつて人間は機械の命令を直接扱った。アセンブリは命令に名前を与えた。高級言語はレジスターを気にせずアルゴリズムを記述できるようにした。フレームワークは基本要素をすべて実装せずにアプリケーションを記述できるようにした。Infrastructure as Codeは、サーバーを手動で設定せずに環境全体を記述できるようにした。

エージェントは、さらに一つのレイヤーを加える。実装の細部をすべて自分で表現する代わりに、望む結果を伝えられるようになっている。

• このプロバイダーのOAuth対応を追加して。
• このAPIエンドポイントが時々古いデータを返す原因を調べて修正して。
• これらのサービスが同じ認可レイヤーを共有するようにリファクタリングして。
• このGitHubのエピックと、すべての子課題を実装して。
• 作成されたプルリクエストにセキュリティ上の問題がないかレビューし、準備ができたらマージして。

これらはプログラミングの指示だ。結果は従来どおりのソースコード数千行になるかもしれないが、その大部分を私が直接書いたわけではない。欲しいシステムを説明し、制約を設定し、結果を評価し、意図を必要な言語へ翻訳する部分を機械に任せたのだ。

30年前、普通の英語がソフトウェア開発スタックの頂点に来るという発想はSFに聞こえた。今では、それが私の日常の作業になっている。自然言語はシステムの下にあるプログラミング言語を置き換えるのではなく、私自身が使うプログラミング言語になりつつある。

本当に価値があったのは、言語そのものではない

多くのプログラミング言語を使った経験には、今も大きな価値がある。各言語が型、並行処理、メモリー、状態、インターフェース、エラー、抽象化をどうモデル化するかを知っていれば、エージェントの成果を評価するための、より優れたメンタルモデルが得られる。その経験は、悪いアーキテクチャ、不要な複雑さ、壊れやすいインターフェース、後で問題になりそうな実装上の選択を見抜く助けになる。

しかし、もっと重要なのは、複雑なシステムを作ってきた経験だと思う。言語は結局、目的を達成するための手段だ。

ソフトウェア開発の難しさは、構文を覚えたり、どのライブラリー関数を呼ぶかを知ったりすることだけではなかった。境界をどこに置くか、コンポーネントをどう連携させるか、どんな障害が起こり得るか、状態をどう管理するか、変化をどう見越すか、何を優先して何を諦めるか、創発的な挙動をどうデバッグするか、一見妥当な実装が現実の複雑さに耐えられないのはどんな時かを判断することこそ難しい。

そうした能力はエージェント開発への移行後も残り、むしろ重要性を増すかもしれない。エージェントが必要に応じて十分な品質のTypeScript、Python、Go、Rust、Javaを書けるなら、特定の構文に習熟していることの希少性は下がる。何を作るべきか、各部分をどう組み合わせるか、どの制約が重要か、結果が本当に良いかを判断する力の価値が高まる。

だから、未来がプロンプトの上手な人だけのものになるとは思わない。巧みなプロンプトは、エンジニアリングの判断力の代わりにはならない。何十年もシステムを作ってきた人なら、エージェントの計画を見て、境界が間違っている、データモデルが拡張に耐えない、セキュリティの前提が弱い、あるいは提案されたアーキテクチャがそもそも違う問題を解こうとしていると見抜ける。

エージェントは、意図から実装への翻訳をますます担えるようになる。それでも人間は、システムを理解しなければならない。

私には、これこそ本当の変化に思える。プログラミング言語はスタックの下へ移り、アーキテクチャ、判断力、オーケストレーション、システム思考が上へ移るのだ。

Cursor や Windsurf はこれを解決するのか？

CursorやWindsurfも、この問題は解決しない。当然の反論は、従来のIDEが衰退しても、CursorやWindsurfのようなAIネイティブのIDEが未来なのではないか、というものだ。私はそう思わない。

CursorもWindsurfも、根本的にはIDEだ。人間がソースファイルを見て、リポジトリ内を移動し、コードを選択し、差分を確認し、エディターの中でAIとやり取りすることを、ソフトウェア開発の中心に据えている。それはもう、中間段階のように感じられる。

その後、どちらもターミナルのエージェントや自動化のインターフェースを備えた。これは確かにこの方向への一歩だ。それでも製品の中心はエディターのままで、新機能が載るのも、注意が向くのも、対価を払っているのもそこだ。

Orgabotなどのエージェント実行環境を使っているなら、AIで強化されたエディターも、従来のエディターと同じくらい必要ない。私は自動補完を待ったり、関数を選んでAIに書き直しを頼んだり、助手が肩越しに見ている間に手動でファイルを行き来したりしているわけではない。

エージェントに仕事を渡す。

エージェントはファイルを開き、コードベースを検索し、依存関係を調べ、コマンドを実行し、テストの失敗を読み、20個のファイルを修正し、サブエージェントを起動し、変更をレビューし、完了まで反復できる。そこまで来ると、IDEの中にAIを入れるのは、ほとんど逆向きに思える。

目標は、人間がコードを編集する速度を劇的に上げることではない。人間が編集しなければならないコードを劇的に減らすことだ。

この違いは重要だ。CursorやWindsurfはAI支援プログラミングのための優れたコックピットかもしれない。しかし私が進んでいる方向では、コックピットそのものが次第に不要になる。主なインターフェースはミッション、課題、仕様、会話になる。ソースコードは依然として極めて重要だが、一日を過ごす場所ではなく、そのインターフェースの下で生成され、操作される成果物になる。

だからJetBrainsを解約したとき、CursorやWindsurfに乗り換えたわけではない。IDEをエージェントに置き換えたのだ。

もうプログラマーではありたくない

Orgabotは、私をさらに一歩先へ進めた。Orgabotでアプリケーションや組織を作るとき、私はより良いコーディングツールを持つソフトウェアエンジニアとして取り組んでいるのではない。CEOの視点から取り組んでいる。

CEOはソースファイルを開いて関数を直さない。目標を定め、責任を割り当て、適切な人やエージェントが作業していることを確認し、成果が目標に合っているかを評価し、プロセスが壊れたら組織を変える。

オーケストレーション自体も委任できる。CEOがCTOに製品の完成を指示すれば、CTOはその任務の下で、エンジニアリング、セキュリティ、インフラ、デザイン、レビューを調整する。CEOは認証ミドルウェアがどのファイルにあるかを知る必要がない。

私はますます、そのような方法でソフトウェアを作るようになっている。例えば、こう言う。

• この製品を作って。
• このエピックと、すべての子課題を解決して。
• このシステムが失敗する理由を調べ、根本原因を解消して。
• リリース前にセキュリティ担当に実装をレビューしてもらって。
• 品質を落とさず、この作業フローのコストを下げて。

これらの指示は、最終的にコードを生み出す仕事につながる。しかしコードは、私が操作しているインターフェースより何層も下にある。

そこから実用的な原則が導かれる。CEOがソースコードをレビューしたり編集したりしているなら、その下のどこかで作業フローが壊れている可能性が高い。

エンジニアリングのエージェントが失敗したのかもしれない。レビューのプロセスが弱いのかもしれない。組織に適切な役割やスキルがないのかもしれない。問題を上位に報告する境界が間違っているのかもしれない。原因が何であれ、CEOをいつまでも実装レイヤーへ引きずり下ろすことが答えであってはならない。次回は組織が適切に処理できるよう、システムを直すべきだ。

これも、IntelliJをCursor、Windsurf、その他のAI IDEに置き換えることにあまり関心がない理由だ。それらのツールは、コーディングのレイヤーにいるプログラマーの効率を高める。Orgabotは、そのレイヤーを私がほとんど入らずに済む場所にしようとしている。

IDEは実装の細部になりつつあるのかもしれない

だから私は、ポストIDEの時代に入りつつあると思う。

明日IDEが消えるという意味ではない。グラフィカルなコードエディターがなくなるという意味ですらない。問題を理解するにはソースコードを直接見るのが最善、という場面は常にあるだろう。ただ、IDEはプログラマーとソフトウェアを結ぶ主要なインターフェースとしての地位を失いつつあると思う。

エージェント実行環境がそのインターフェースになりつつあり、従来のIDE企業にもAI IDE企業にも、厄介な戦略上の問題を生んでいる。分かりやすい対応は、IDEにAIを入れることだった。チャットパネル、自動補完、エージェントモードを追加し、AIが複数ファイルを一度に変更できるようにする。

それらは有益な改善だ。しかし、アーキテクチャが逆なのではないかとも思う。

未来は、エージェントを内蔵したIDEではないのかもしれない。エディターを内蔵したエージェントなのかもしれない。

エージェントそのものが環境になる。リポジトリ、ターミナル、ブラウザー、デバッガー、エディター、テスト、CIシステム、課題管理、デプロイ基盤は、必要なときにその環境が使えるツールだ。大半の時間、人間はその一段上にいる。

JetBrainsが悪くなったから解約したわけではない

この区別は重要だ。JetBrainsが私を失ったのは、IntelliJが悪いソフトウェアになったからではない。むしろ逆だ。IntelliJは今も驚くほど高性能なエンジニアリングの成果である。

解約したのは、自分の作業フローが大きく変わり、その機能の99パーセントを必要としなくなったからだ。そして、それははるかに大きな脅威だ。競争上の最も難しい問題は、誰かが自社製品のより良い版を作ることではない。ユーザーの行動が大きく変化し、製品カテゴリーそのものの重要性が下がることだ。

長い間、私はソースコードを編集するための最高の環境を求めていた。その後は、ソースコードを編集するエージェントを指揮するための最高の環境を求めるようになった。今では、その表現ですら向かう先を十分に表していない。

私が欲しいのは、責任を引き受け、仕事を委任し、互いにレビューし、必要なら上位へ相談し、私を実装レイヤーへ降ろすことなくソフトウェアを生み出せる、エージェントの組織を作るための最高の環境だ。

IDEはその世界の中心ではない。エージェントの一つが使うかもしれない道具にすぎない。

長年IDEの中で暮らしてきたが、私はついにそこを離れたのかもしれない。