Zedの創業者Nathan Soboが、AI時代におけるIDEの存続について語る。ターミナルベースや会話型のAIコーディングツールが台頭する中、IDEは死ぬのかという問いに対し、彼は明確な反論を展開する。ソースコードは人間が読むための言語であり、AGIに到達するまで人間がコードと相互作用しなくなることはないと主張する。GitHubでAtomを、そしてElectronを開発した経験から学んだ教訓を活かし、Rustで書かれた高性能エディタZedを構築した。現在15万人以上の開発者に使用されるZedは、リアルタイムコラボレーションとAIエージェントとの統合を重視し、エージェントクライアントプロトコル(ACP)を通じて様々なコーディングエージェントと接続する。Nathan は、コードそのものをメタデータのバックボーンとして、会話、編集、コンテキストがすべて結びつく未来のビジョンを描いている。
IDEの死は訪れない
人間がソースコードとまったく相互作用しなくなるというのは、私には理解できません。AGIに到達するまでは、つまり人間が多くの異なることをやらなくなるまでは、そうはならないでしょう。でもそれまでは、私たちはコードを見る必要があると思います。コードを見る必要があるんです。
そうなると問題は、そのための最良のユーザーインターフェースは何かということになります。今日はZedの創業者Nathan Soboさんとお話しします。彼は20年近くIDEの構築に費やしてきました。最初はGitHubでAtomを構築し、今はZedを作っています。ZedはRustで書かれた現代的なIDEで、15万人以上のアクティブな開発者に使用されています。また、異なるコーディングエージェントを異なるコーディング環境(Zedを含む)に接続するACP、つまりエージェントクライアントプロトコルも作成し、メンテナンスしています。
Nathanは逆張りの見解を示しています。チャットやターミナルベースのAIコーディングツールに関する誇大広告にもかかわらず、彼はソースコード自体が人間が読むための言語であり、AIエージェントが何をしているかを理解するためには常にビジュアルインターフェースが必要だと主張します。私たちは、LLMが実際にコーディングできるのか、コーディングにおける人間とAIの間のより豊かなコラボレーション層がどのようなものになるか、そしてコードを会話、編集、コンテキストがすべて結びつくメタデータのバックボーンに変えるというNathanのビジョンについて深く掘り下げます。
それではお楽しみください。Nathan、今日はご参加いただきありがとうございます。
お招きいただきありがとうございます。
IDEは死ぬのか
まず核心を突く質問から始めたいと思います。インターネット上では、これはIDEの死なのかという話題が多く出ています。2年前を振り返ると、誰もが主にIDE内でコーディングしていましたよね。そして今、人々がターミナルやより会話的な体験に移行しているように見える中で、疑問が浮かんでいます。これはIDEの死なのでしょうか。
そうですね。実際、私自身も異なる時期に、異なる不安の状態で、自分にその質問を投げかけたことがあります。これはIDEの死なのか、と。私は人生のすべてを、この究極のツールを構築するために費やしてきたのに、それが重要でなくなるのか。これらの人々は正しいのか、と。
しかし、真剣に考え抜いた後、私は絶対に衰退しつつある馬車の装飾を金メッキしたくはありませんから、そういった見方は現実的ではないと思います。ターミナルに座って、LLMと話すスクリプトと英語で話し、コードベースで本当の進歩を遂げることができるというのは驚異的です。そして、私を含めて、明らかに数百万人の人々がそれを行っています。
しかし、私が直面した問題は、例えばClaude Codeが私が最も多くの時間を費やしたものだと思いますが、それがちょうど何をしたかを見せたいときに、ターミナルの10行か、ほんの小さな抜粋でそれを確認することになります。そして、もっと見たいと思ったら、どうしますか。
だから、IDEが死ぬと信じるなら、それは人間がもうソースコードと相互作用する必要がなくなると信じることを必要とすると思います。エージェントがちょうど行った編集のコンテキストや、それが接続されているすべての異なるものを見て理解し、それを自分の脳に読み込む必要がない、と。
私は根本的に、ソースコードは自然言語が言語であるのと同じように言語だと思っています。だから、私たちには自然言語を処理するための革命的な新しいツールがあります。これまで持っていなかったものです。しかし、ソースコードはプロセッサに供給するバイナリではありませんよね。それは人間の消費を意図しているのです。
私のヒーローの一人で、多くを学んだHarold Abelsonという人がいます。彼はコンピュータサイエンスの教授だと思います。MITにいたと思います。彼には私がずっと好きだった素晴らしい言葉があります。「プログラムは人々が読むために書かれるべきで、機械が実行するのは偶然に過ぎない」というものです。
これは極端な立場です。なぜなら、機械に実行させたくないならなぜプログラムを書くのか、となるからです。Haskellでプログラミングする人たちの多くは、このすべてのプログラム的操作で何が行われるかを実際には気にしていないように見えます。私は気にする傾向がありますが、その中にも多くの知恵があると思います。
根本的にプログラムは、何らかの抽象的なプロセスを非常に正確な方法で表現することについてなのです。そして、チューリング完全なプログラム的概念について話すためのより良い言語は、ソースコード自体以外にはありません。
だから、人間がソースコードとまったく相互作用しなくなるというのは、私には理解できません。AGIに到達するまでは、つまり人間が多くの異なることをやらなくなるまでは、そうはならないでしょう。でもそれまでは、私たちはコードを見る必要があると思います。コードを見る必要があるんです。
そうなると問題は、そのための最良のユーザーインターフェースは何かということになります。そして最良のユーザーインターフェースはGUIなのでしょうか。
私はそう思います。あるいは、コードへのインターフェースを表現する方法はたくさんあります。グラフィカルである必要がありますか。例えば、Vimを使っている人はたくさんいます。Vimはグラフィカルユーザーインターフェースではありませんが、インターフェースではあります。ソースコードを提示し、ナビゲートし、そして時にはそのソースコードを手動で編集することに最適化されたインターフェースです。
なぜなら、ソフトウェアを理解する最良の方法は、多くの場合ソフトウェアを見ること、この抽象的なプロセスを表現するために導き出せる最良の人間が合成した言語を見ることだと思うのと同じように、それを表現する最良の方法は時にはただそれを書くことだからです。直接的に。
私は、反復的な作業を頑張ることや、LLMによって書かれる可能性のあるものを特に好むわけではありません。そういうものを必ずしも書きたいとは思いません。しかし、何かを明確に表現する最も明確な方法が、ただコードを書いてデータ構造を定義することである場合が、ソフトウェアには今でもよくあると思います。
私はLLMに文章を書いて、次の4つのフィールドを持つ構造体が欲しいと説明することもできますし、それをより抽象的なレベルで説明することもできます。しかし、何を表現したいか分かっているなら、ソースコードが実際に最も効率的な方法であることがあります。
そして、その世界では、ソースコードをナビゲートして編集するために設計されたツールは、今でも非常に関連性のあるツールのように思えます。そして、ターミナルでツールを使って激しくバイブコーディングしている人たちでさえ、おそらく何が起こっているかを調べるために、そのツールと一緒にエディタを実行しているのではないかと思います。
Atomからの教訓
冒頭で、あなたがキャリア全体でIDEに取り組んできたとおっしゃいました。あなたはIDE界の伝説です。リスナーの方々のために、あなたの背景について少しお話しいただけますか。
大学を卒業したとき、私は自分自身のエディタを構築することに決めました。それは2006年、大学卒業の翌年でした。そして、私はずっとキャリア全体をかけて、自分が思い描いたエディタを構築するために働いてきました。それは常に、当時TextMateが非常に人気のあるツールでした。私はDHHがRailsをデモしているのを見てTextMateを知りました。軽量でシンプル、親しみやすく、速かったのです。
私はEmacsを使ったことがあり、Eclipseを使ったことがあり、JetBrainsの製品も使ったことがあります。それらは今でも非常に強力です。それらはすべて、拡張性、反応性、機能の豊富さという点で何かをテーブルにもたらしました。しかし、それらのすべてを1つのパッケージに統合したものはありませんでした。
だから、2006年に私は、起動に10年かかるような最も有能なIDEと同じ力か、それ以上の力を持ち、指先で少し重く感じるようなエディタを構築したいと決めたのです。しかし、TextMateやVimのような反応性も持ち、本当に拡張可能で、しかし、毎週末に餌をやらなければならないペットのような、秘伝のVimscriptで拡張可能である必要がない、つまりVimの設定が壊れないようにする必要がないものを作りたかったのです。私はVimでAtomを書きました。
実際にAtomについて、そしてそこからの教訓、そしてなぜZedを始めたのかを話してください。
私の夢のIDEを提供する最初の試みがAtomでした。そして、私はGitHubにそのプロジェクトに取り組む最初の2人のエンジニアの1人として参加しました。私たちはそれを極めて拡張可能にしたかったので、ウェブ技術で構築してはどうかと決めました。Atomを作る過程で、私たちはAtomの周りのシェルを構築し、それを最終的にElectronと名付けました。
Electronは、さまざまなアプリケーションの基盤となりました。ちょうどその参照に気づきました。それは実はChris Wanstrathのアイデアで、私のものではありませんでした。
私たちがやったことは、当時非常に人気が出ていたNode.jsをChromeと結婚させて、デスクトップアプリのように見えるウェブページを構築できるこのフレームワークを提供したのです。そして、それは非常に成功しました。Atomには全盛期がありました。
そして、MicrosoftがPrivateのアイデアをコピーし、Electronを取り、すでにウェブ上で動いていたコードを取って移行しました。そして残りは歴史です。VS Codeは業界を支配することになりました。
しかし、ある時点で、私はAtomがその道を走り切ったと感じるところに到達しました。そこで難しい教訓をいくつか学びました。その一部は、大量のテキストを効率的に表現し、編集するデータ構造をどう設計するかということについてでした。それは、ある程度正直に言えば、言語に中立的な教訓です。
そして、教訓の一部は、人々をメインスレッドにコードを持ち込んで、ランダムな拡張コードを実行することでアプリケーションのパフォーマンスを破壊することに招待しないということでした。私たちはそれを非常に拡張可能にしました。私たちは非常にオープンでした。それが素早く人気を博した理由の一つですが、その後、私たちは時期尚早だった約束の下で溺れてしまいました。
しかし、1つには、私はウェブ技術にうんざりしていました。Electronに組み込まれているパフォーマンスプロファイル、基本的にChromeの開発ツールを開いて、最適化しようとしているものを見て、このフレームグラフの中の小さな線が何であれ、その中に入ってそこで何が起こっているかを理解する必要があると思ったことを覚えています。そして、私はこれをどれだけ速くできるかの天井に達したのです。
だから、2017年だったと思いますが、私たちは最初からやり直す必要があると決めました。ウェブブラウザは、私が本当に構築したいツールの適切な基盤ではないと。それはパフォーマンスと大いに関係がありました。それは大したことではないように聞こえるかもしれません。しかし、パフォーマンスは後から追加できる機能ではありません。
アーキテクチャを選択したら、そのアーキテクチャのパフォーマンス能力を受け入れることになります。そして、ウェブは私にとってそれではありませんでした。
コラボレーションとAIエージェント
あなたは元々、人間が他の人間とペアプログラミングをしやすくするためにZedを構築しましたよね。それが、AIエージェントが登場し、人間がAIエージェントと協力する必要が出てきたときに非常に便利だったことが分かりました。そのダイナミクスについて少し話してください。
業界全体が、私たち全員がどのように協力すべきかについてのアイデアを持っていると思います。そして、私は実際、現在の協力方法が人気になるときにGitHubにいました。それはすべて非同期であるということです。あなたは自分の隅に行って大量の作業を行い、そのスナップショットを撮ってアップロードし、そして、ウェブブラウザで誰かがあなたのスナップショットにコメントを書き、そして多分1時間後か、多分1日後に、あなたが返信するのです。
そして、それは非常にメール指向の体験、非同期の体験です。それは、あなたが全員同じページにいるときには適切かもしれません。あるいは、もしかしたらLinuxに取り組んでいるときには、それがGitが元々設計されたものですが、世界中の人々がこれらの非常に異なるものに取り組んでいるときには、それが適切なモダリティかもしれません。
しかし、私は常に、ソフトウェアで協力する最良の方法は、コード内で一緒にいて、コードを一緒に書いたり、コードについて話し合ったりする時間をもっと多く含むことだと信じていました。実際にお互いに話すことができ、お互いを中断することができ、また、Gitベースのフロー上では起こらないと思う方法で、人間としてお互いに関係することができる形式です。
私たちは常にGitを使っていますし、多くのチームほどコードレビューを行っていません。なぜなら、私たちが好むのは、コード内でリアルタイムでお互いに話すことだからです。しかし、それを可能にする良いツールがなかったのです。
スクリーン共有を使うこともできますが、スクリーン共有の問題は、キーストロークを往復させる必要があるため、一人が非常に助手席にいることになります。だから、AIが来ることを知らずに、最初に解決したかった2つの大きな問題は、根本的により良いパフォーマンスでした。
キーを入力したら、モニターの次の同期で応答するピクセルが欲しいのです。だから、知覚可能な遅延はゼロです。私たちはかなり近いです。100%完璧だとは言えませんが、ウェブブラウザで得られるよりもはるかに近いです。
それをどうやって達成したかについて一言言っていただけますか。話が脱線していますが、あなたの2番目のことを言ってから、パフォーマンスをどう達成するかについて一言言ってください。
しかし、最初のパフォーマンス以外のもう1つの大きな柱は、開発者がソフトウェアで協力する方法を変えることでした。そしてそれを行うために、私は、Figmaがデザイナーのために行ったのと同じように、チームメートの存在を作成環境自体に実際に持ち込む必要があると本当に感じています。
さて、デザイナーは多くの良い選択肢を持っていませんでした。魅力的な代替手段としてGitのように良いものは何も持っていませんでした。しかし、私は今でも、ツール内にいて、作成している実際のものを見ていて、他の人々がそこにあなたと一緒にいるというビジョンが、ソフトウェアを作成する体験にもたらされるべきだと思います。だから、このような深いレベルでUIを所有することが適切だと感じたのです。
さて、AIへの影響についてのあなたの質問の残りの部分について。Zedのビジョンは常に、会話をコードが書かれている作成環境のコードにリンクしたいというものでした。だから、実際、コード内での会話は、以前は少し奇妙なアイデアだったと思います。なぜなら、なぜコード内で会話する必要があるのか、ということです。あなたは自分でそれを書いて、スナップショットをプッシュし、それからあなたが書いたコードについてウェブサイトで会話をするわけですよね。
しかし、この霊的な存在のようなもの、幽霊と常にこの会話をしている世界では、それがずっと関連性が高く感じられ始めています。この、より同期的なコラボレーションモードの大ファンである私を含めた私たち全員が、コード内でコードについてより多くの会話をしています。
そして、このスナップショット指向のパラダイムが本当に崩壊しているのを見ているのはそこです。エージェントと相互作用していて、それが行っていくつかの変更を加え、私がそれらの変更についてフィードバックを与えたいとき、理想的には、私がそれらの変更に与えたフィードバックを永久に保存し、それの記録を持ちたいのです。
それのためのGitのようなツールはありません、理解できますか。しかし、私はそれが出力するすべてのトークンでコミットして、それについてプルリクエストレビューを行うようなことはしないでしょう、そうですよね。
だから、正直に言うと、Zedは非常に進行中の作業です。そして、この体験を提供する権利を得るために、私たちはまず、誰かが自分でソフトウェアを作成するために使いたいと思う有能なエディタを構築する必要がありました。
私たちはそこで大きな進歩を遂げたと思いますし、今、このフェーズ2、つまりこの細かいトラッキングメカニズムにより本格的に取り組み始めています。それは同等のものです。正確にそうではありませんが、すべてのキーストロークでコミットを持つか、エージェントがストリーミングするすべての編集でコミットを持ち、それに直接相互作用や会話をアンカーできるようにするのと同等です。
だから、私たちが構築している技術は、おそらく単独で構築できたものだと思います。しかし、問題は、その上にどんな体験を提供するかということです。そして、私は常に、最良の体験は、この垂直統合だと思っていました。
私たちはUIとすべてのインフラストラクチャを上から下まで設計して、コード内で直接相互作用する没入型の能力を提供します。別の存在と。
エージェントクライアントプロトコル
あなたは、人間が異なるAIエージェントと協力するためのほぼスイスのようなIDEにするという選択をしましたよね。そのビジョンにおいて、エージェントクライアントプロトコル、ACPと呼ぶのでしょうか、が果たす役割について話してください。
私は本当に、私たちの仕事を、人間、ソースコード、他の人間、または基本的に他の人工人間との間の究極のインターフェースを提供することだと見ています。私たちは今年の初めにファーストパーティのエージェントを構築しましたが、それを行っている間、プロンプトを調整するのは非常に挑戦的です。
IDEを構築するのと同じようなアルゴリズムの複雑さ、データ構造を正しく取得すること、物事がパフォーマンスが高いことを確認するという点で、挑戦的に感じるものはありません。実際のチューリング完全なソフトウェア部分はかなり簡単です。難しい部分はAI部分です。
そして、それはチームとしてまだ学んでいることだと思います。私たちは非常に異なる視点から来ています。一方で、AnthropicやGoogle、GoogleのGemini CLIのような大手AIラボからかなり資金提供されているように見えるチームがたくさんいます。彼らは私たちが統合した最初の人々でした。Claude Codeもです。
誰もがエージェントを構築しているように見えます。そして、これらすべてのエージェントは、私がかなり貧弱だと考えるターミナルベースの体験をレンダリングしています。それはエディタで補完される必要があるでしょう。
だから考えは、私たちは素晴らしいエディタを持っていて、これらすべての人々がこの問題を解決しようとしているということです。ここで起こる必要があるのは、Language Server Protocolが行ったのと同じことです。
MicrosoftがVS Codeで行った素晴らしいことの1つは、通常JetBrainsスタイルでIDEにバンドルされていたすべての知能、つまりIDEがすべてを知っている状態で事前設定されているものを、コミュニティに移したことです。だから、PHPには今言語サーバーがあり、TypeScript言語サーバーなどがあります。
私たちはエージェントでも同じことをしたかったのです。おそらく異なる種類のエージェントが異なるドメインで実験しているだろうという考えです。特定の問題に最適化された特定のエージェントがあるかもしれません。エージェントはお互いに競争しています。だから、時には1つが最良であっても、別のものに追い抜かれることもあります。
それをすべて外部化して民主化し、「どのエージェントを使いたくても、そのエージェントとソフトウェアと相互作用するための優れたUIを提供したい」と言うことを試みました。それがその背後にある考えでした。そして今のところ、実際に私が期待していたよりもうまくいっています。
このアイデアに共鳴する人がどれだけいるか、本当に分かりませんでした。しかしJetBrainsが参加しました。そして、それは本当にエキサイティングだと思います。彼らは理論的には競合相手ですが、反対側に誰かがいるのは良いことです。そして今、多くの異なるエージェント開発者が反対側で参加しています。
私たちは自分たちのエージェントに取り組み続けますが、それと競争するのではなく、すべてのその努力と連携しているのは良いことです。
バイブコーディングの実践
あなたは時々バイブコーディングをしますか。
ええ、そうです。バイブコーディングの成功例の1つは、私たちには置き換える必要のある非常に古いサーバーサイドのインフラストラクチャがあったということです。それで、私はすべてのサーバーサイドインフラストラクチャをCloudflareに移動することにしました。
そして、私はCloudflare APIのシミュレーターをバイブコーディングしました。基本的に、私たちはRustにトレイトを持っていて、それがCloudflareができるすべてを抽象化します。そして、私は基本的に午後の時間とアイデアを持っていて、それはエージェントコーディングの素晴らしいユースケースでした。
何をしましたか。私はエージェントにアイデアを説明しただけです。私はCloudflareのJavaScript APIからいくつかのAPIドキュメントを供給したと思います。そして、私はこれらのAPIへのRustバインディングを構築したいと言いました。しかし、それから、これらのAPIのシミュレーターもプラグインできるような抽象化を構築したいと言いました。そして、私は自分が何を望んでいるか正確に知っていました。ビジョンがありました。そして、そのビジョンを表現する時間があまりありませんでした。
だから、過去には、自分でやったかもしれません。でも絶対に時間がありませんでした。当時は他のことが起こっていました。あるいは、何らかの漠然とした文書を書いて、私が考えていることをチームのエンジニアに説明しようとしたかもしれません。
しかし、このバイブコーディングセッションが私にできるようにしたのは、その中間のどこかに到達することでした、理解できますか。だから、私はこの生成されたコードの山をクラウドで働いている人たちに申し訳なさそうに手渡して、「これを生成しました。これは私が進みたい方向性です。ここに奇妙なものがあっても、あまり厳しく判断しないでください。それは生成されたものなので、念のため」と言いました。
でも、それは大成功でした。つまり、彼らはそれを使って前進することができたのです。私は、バイブコーディングボス、つまり、よく分からないバイブコーディングボスにはなりたくないと思っています。彼らは問題の95%を解決したと思っていますが、実際には5%を解決しただけで、自分をだましているだけです。
私は意識的な方法でそれを行い、実際にボールを前に進めていて、迷惑をかけていないことを確認したいのです。大きなスロップの混乱を誰かに手渡して、「ほら、これを片付けて、私の素晴らしいアイデア」と言うのは嫌です。
ユーザーベースとAI採用
実際、スロップについて言えば、あなたのユーザーベースは、10万人規模のアクティブな開発者ですが、彼らは非常にハードコアなエンジニアのような傾向があります。長い間コーディングしてきたエリートです。AIに対するユーザーベースの全体的な視点は何ですか。彼らはそれを受け入れていますか。
私たちが持っている指標に基づくと、それは完璧ではありません。オープンソースのIDEだからです。人々が簡単にオプトアウトできるようになっています。Zedを使っている人の約半分が、私たちの編集予測機能を使っています。これは、私がコーディングしている間に次のことを提案してくれるものです。だから、プログラマーが非常に運転席にいます。
そして、私たちのアクティブユーザーの約4分の1が、何らかの形でエージェント編集を使用しています。群衆の中には嫌いな人もいました。私たちがAIを受け入れ始めたとき、彼らがそれについてどう思っているかを知らせてくれた人々が間違いなくいました。しかし、私はそれを気にしません。
何かが起こっているんです。私たちはそれに向かわないわけにはいきません。私はそういう人間ではありません。だから、もし彼らが伝統に必死にしがみついているとか、頭を砂に突っ込んでいるということでZedにサインアップしたのなら、私たちは参加していません。私は未来に向かって進みたいのです。
私たちは、おっしゃるように、よりプロフェッショナルなハードコアな聴衆を惹きつけています。少なくとも今のところは、完全なビジョンはまだ構築されていないからだと思います。私たちが提供しなければならないものの1つは、この極端なパフォーマンスです。日々、他のものと同じ機能を持ちながら、はるかに優れたパフォーマンスを持っています。
だから、開発者がより熟練するにつれて、彼らは手の下で使っているツールの触感体験を気にし始めると思います。1日40時間何かを使うと、フレームをドロップしているときや、基本的に手に追いつけないときにイライラし始めます。
だから、今Zedに引き寄せられる傾向がある人々の種類は、本当によく作られた速いツールを気にする種類の人々です。私の娘は、あるお母さんが歯科医の女の子と一緒に学校に通っています。彼女は今、自分の歯科診療のためにいくつかのソフトウェアをバイブコーディングしていますよね。
彼女は、指の下で気持ちの良い速いエディタが必要だと知っていますか。分かりません。私は彼女にそうあってほしいです。それは私の仕事の一種です。私たちにはもっと大きな計画があると思いますし、時間の経過とともに、より広い聴衆に訴えるものがあると思います。しかし今のところ、本当に気にする人々は、かなり経験豊富な人々である傾向があります。
LLMの能力と限界
あなたのエンジニアの1人、Conradが書いた記事を覚えています。あなたはそれを私にほとんど恥ずかしそうに、または申し訳なさそうにテキストで送ってくれました。それはHacker Newsで1位でした。「なぜLLMはソフトウェアを構築できないのか」というものです。ソフトウェアにおいてLLMが得意なこととそうでないことについて、あなたの精神的モデルは何ですか。そしてそれはどれくらい速く変わっていると思いますか。
私は、LLMがソフトウェアを構築できないというConradの確信ほど確信していません。彼らができないことについての彼の精神的モデルは、おそらく私のものよりも優れているか、彼は自分の見解に対して私よりも自信があるのだと思います。私は、彼らが決してできるようにならないことについてはあまり確信していません。しかし、私自身の経験で彼らがうまく機能したことと、物事がイライラしたり、うまくいかなかったりすることについては話すことができます。
私は先ほど、Cloudflareの生成について触れました。私が持っていた別の初期の体験、エージェント的なもの以前、エージェント以前の、GPT-4だけを使った体験は、私たちのグラフィックスフレームワークのための新しいバックエンドを生成したことです。それは、私たちが書かなければならなかったものです。
あなたは先ほど、私たちがどのようにパフォーマンスを達成するかについて尋ねていましたが、私たちがやっていることの1つは、Zedアプリケーション全体が、GPU上で実行されるシェーダーにデータを提供することを中心に組織されており、ビデオゲームがそのUIのフレームや体験をレンダリングするのとほぼ同じ方法で、UI全体をレンダリングします。つまり、2D UIをレンダリングしており、ビデオゲームがその3D世界をレンダリングするために使用するのと同じ技術のいくつかを使っています。
興味深いですね。
とにかく、私はグラフィックスバックエンドを書き直していました。元のグラフィックスバックエンドは書きましたが、十分に機能していましたが、私が望む形ではありませんでした。そして、私は、GPUとすべての異なるステージとすべてのこれらのものを設定するレンダリングパイプラインを生成することができました。
過去には、Stack Overflowで検索したり、あいまいなドキュメントを掘り回したりしていたようなことです。私はただそれを行くことができました。なぜなら、そのすべての知識を私は持っていませんでしたが、それは間違いなくそこにあるからです。これらのモデルの分布の中に。
その同じ書き直しの間、またはUIフレームワークの根本的な変更の間に私がやったもう1つのことは、たくさんの手続き的マクロを書いたことです。Rustのマクロは本当に強力です。何かの上に小さな注釈を置くだけで、コンパイラが実行される前に裏でこれらすべてのコードを生成する方法です。
しかし、私はRustマクロを書くことを本当に学んだことがありませんでした。確かに、これらの手続き的マクロは学びませんでした。私は、Tailwind CSSからのすべてのアイデアを私たちのRustグラフィックスフレームワークに引き込むために書く必要がありました。それは本当に私を喜ばせました。
このアイデア、つまり、私たちは、Tailwindのようなポップカルチャーのようなウェブアイデアをシステムプログラミング言語に引き込んで、これら2つのものを組み合わせているのです。しかし、TailwindはLLMの分布の中に間違いなくあります。それはRustを十分によく知っており、私が生成する方法を知らなかったこれらの手続き的マクロを生成する方法を知っていました。
だから、私が決して試みなかったようなことを、私が行ったよりも速く行いました。Tailwindクラスごとにメソッドを生成するマクロを書くつもりだ、というようなことです。でも、ここにいくつかのドキュメントを供給することで。
私はそれを知識押出機のように見ています。そこには一般化された知識がすべてあり、確かに私はそれについて読んで学ぶことができますが、いいえ、私はそれを私が望む形に絞り出してほしいのです。だから、それは完璧なユースケースでした。すべてかなりよく知られた標準的なものでしたが、私が必要とする形ではなかっただけです。
だから、彼らが本当に得意なのは、コピー&ペーストのようなものですが、はるかにそれを超えています。でも、あなたはまだグローバルな知識セットから借りているようなものです。
私がもっとイライラしてきたのは、今私たちはこのDelta DBシステムに取り組んでいるところです。それは、個々の編集が発生したときに細かいトラッキングとリアルタイム同期を行おうとしています。それはGitの上に層を成しています。
それは楽しいです。なぜなら、問題の前に座って、同時に解決する必要があるすべての異なる制約を頭に読み込んで、すべてをそこに十分長く保持するのに苦労するこれらの瞬間のいくつかをしばらくぶりに持っているからです。LLMはそれほど役に立っていません。
少なくともコードを書く際にはそうです。なぜなら、これを解決するときに制約はコードではないからです。はい、私たちはコードを書いていますが、もっと重要なのは、実際にはそれほど多くない総行数のコードの背後にある思考です。それらはただ正しい行であり、私はそれがどれだけ少ない行であるかを誇りに思っています。
人々は彼らが生成しているコードの行数に興奮しますが、異なる種類のソフトウェアにとっては、それが意味を成すかもしれません。しかし、私は今でもLLMを使っています。ただコードを書くために使っているわけではありません。アイデアを探求するために使っています。あるいは、実行するつもりのないコードを生成させて、それがどのように感じるかを素早く見るためです。
だから、それらを私のプロセスの固有の部分として使用していないわけではありません。ただ、私がやっていることによって、コードを書くことで私を速くしてくれるかどうか、常にそう確信しているわけではないということです。
それをあなたに読み返すと、LLMがトレーニングデータの分布内にあるようなことをしていて、あなたがやりたいことのほぼ疑似コードの良い抽象モデルを持っているとき、モデルは実際にコードを実装するのが非常に得意です。
分布外に出るとき、またはコードを書くことが実際に手元のタスクではないとき、実際にはコードに何をさせたいかの思考であるとき、そのときLLMはまだそこにはいません。
それが正しいと思います。そしてもう1つ言いたいことは、LLMがもっと速くなることに私はワクワクしています。例えばHaikuは、直接使用することを意図していないと思います。より速いモデルまたはよりスマートなモデルにいつ切り替えるかを把握するために、ツールビルダーとしてやるべき仕事がいくつかあります。
しかし一般的に、彼らが完全にばかげて unintelligent でない限り、より速く行けることが、それがトリックです。しかし、私は、まったく unintelligent でない限り、要求に応じてdiffを召喚できることにワクワクしています。なぜなら、私がエージェントにこのことをやってくれと頼んでいるとき、私にはいくつかの異なる選択肢があると思うからです。
そこに座ってそれを見ることができます。それは時々役に立つことがあり、時には重要です。なぜなら、私は「止まって。あなたが今やっていることは何でも、私が頼んでいないテストを書いているようなものです。あなたがそれを合格させている間、私が合格させたいテストはまだ合格していません」というようなことができるからです。
私はコーヒーを作りに行くこともできますし、他のタスクの世話をすることもできます。あるいは会社レベルの懸念事項にコンテキストスイッチすることもできます。私はそれと競争しようとして、それにそのことをさせることもできます。しかし、それらすべてが少しイライラします。
繰り返しになりますが、私は速いフィードバックを与えることに取りつかれている人間です。私は文字通り、次のフレームでキーストロークフィードバックを与えるためにツールを設計しました。だから、その待つことが私にとってイライラしてきたのだと思います。
しかし、10分の1の時間でほぼ正しいものを得ることができたら、多分私たちは再びシフトについて話しているのだと思います。だから、それがどこに向かっているのか、私にとって陪審員はまだ非常に出ていません。
IDEの未来ビジョン
これらのエージェントがたくさんあることになるIDEが最終的にどのように進化するかについてのビジョンは何だと思いますか。彼らはますます有能になりますよね。GUIはどのように進化しますか。
それにはいくつかの異なる部分があります。私にとってより深い部分は、IDEをこの根本的に協調的な環境として扱うという概念です。正直なところ、今日Zedに展開されているものは、その面ではまだかなりアルファ品質ですが、私たちはそれらすべての教訓を取り入れており、コラボレーションを表現する新しい方法について非常に良い進歩をしています。
IDEはそれがすべて表面化される場所になるでしょう。だから、私にとって本質的に協調的な体験は、複数の人間と複数のエージェントです。エージェントと会話しているとき、それは潜在的に他の人間を引き込むことができるもので、エージェントとの会話を背景コンテキストとして使用したり、話したい関連するコードや議論したい問題をすべて非常に消化しやすい方法で読み込むための近道として使用したりできます。そしてチームメイトを引き込んでその会話をすることができます。
そして、永続性のアイデア、コード内の場所を安定した方法で参照できること。コードの進化の連続的な表現を持つこと、この句読点のあるスナップショットベースの表現ではなく、私にとっては、LLMとのあらゆる種類の相互作用を構築するために必要となる根本的な抽象化になるでしょう。そうすれば、私たちはすべてを覚えることができ、LLMがコードのセクションについて、このコードの背後にあるすべての会話は何かを尋ねることができます。そのコンテキストを掘り下げることができます。
そして、アイデアは、コードベースをこのバックボーンにして、コードに関連するすべてのデータがそこにぶら下がることができるようにすることです。今はそうなっていません。コード内にコメントを持つことはできますし、GitHubでコードのスナップショットに結びついたものを持つこともできますが、ほとんどの場合、コード自体にはメタデータがありません。
だから、本当にそれをアンロックして、コードをこのメタデータバックボーンに変えることが、UI内での大きな部分です。私があなたに見せていたものの一部は、自分自身に質問を投げかけています。そして多くの人々が、エディタの見た目は、長い間同じだったと思います。典型的なものです。左に木、中央にタブ、右側に多分gitのものか、多分エージェントパネル。
それが今日私たちがエージェントパネルを持っている場所です。そしてそれは非常に、時間とともに進化して、1人の人間が1つの作業コピーで1つの問題を手動で解決する、多分真ん中に編集予測があるというものです。
しかし、もし誰かが本当に主な作業手段としてエージェント的に働いているなら、会話を前面と中央に置くとはどういう意味でしょうか。そして、これについて考えているのは私たちだけではありません。これを探求している他のツールもあります。
しかし、私たちについてのクールなことは、私たちは本格的なIDEだということです。だから、私は本当に、これらすべての異なる作業方法のための場所があると見ています。そして、私は間違いなく、この伝統的な方法、つまり、この1つの作業コピーで何が起こっているかにいて、問題を解決するまでこのコピーの状態を前進させる必要があるという方法には、非常に長く存続する場所があると思います。それには場所があります。
しかし、それから、複数の潜在的な会話、多分異なるプロジェクトで同時に進行している会話を持つ場所があると思います。LLMがもっと速くなればそれがあまり問題にならないかもしれません。しかし、それでも、もっと大きなことをやりたくなると思います。
だから、時間がかかるこのプロセスを持つと、マルチタスクをしたいという自然な欲求があります。だから、複数のエージェントとの複数の会話をどのように管理するか。そして、その会話をもっと価値のあるものにするにはどうするか。それが私たちがモックアップで本当に推し進めていることです。
今、私たちはこれらの会話を非常にチャットのようにモデル化していると思います。できることはもっとあります。そう言っておきましょう。この会話が進化していくとき、それをチャットとして見ることもできますが、時間とともに進化しているドキュメントのようなものでもあります。
会話をモデル化していますが、ドキュメントとして見ることもできます。だから、そのドキュメント内には、コードベース内の異なるスポットから注入されているこれらすべての参照があります。編集が発生していて、それがすべてこのログとして時間とともに展開されています。
私が本当にやりたいことは、そのドキュメント表面を読み取り専用のアーティファクトではなく、理解できますか、より有用なものにすることです。主な編集表面として、カーソルを「エージェントに次に何を言いたいか」から上に移動して、以前の会話に入って有用なことをできるようにする、ということです。
だから、私がやりたい有用なことの1つは、今私たちがコードをレンダリングしているとき、それは読み取り専用のようなものです。私たちが今取り組んでいることは、コードへのウィンドウをレンダリングしていて、そのコードが新鮮なとき、あなたはそこで直接編集できて、それが実際の場所と同期されるべきだということです。例えばGitHubのプルリクエストのようにコンテキストを展開できるようにすることです。
だから、Zedには、マルチバッファという概念があります。それは、コードベース全体からコードの小さなピースを取り、それらを1つのユーザーインターフェースに組み合わせて、それを単一のバッファであるかのように編集できるようにするものです。
だから、私は、私が行っている会話が、私に向かってコードを引っ張り、潜在的にいくつかの編集を行い、なぜ私は会話内で直接コードに手を伸ばして相互作用できないのか、という程度のアイデアに本当に興味があります。
そして、2つのポイント間を選択したとき、その期間に発生した変更をレビューできますか。だから、本当にその会話をチャット以上のものにし、Vimバインディングを持つ誰かが会話を素早くナビゲートでき、エディタのような感じにする、新しい種類のエディタにする試みです。
これをゼロから構築し、すべてのプリミティブの深い制御を持っていることで、私が掴みに行くことにワクワクしている機会は、この新しい種類のエディタをどのように持つことができるかということです。それはコードベース内のファイルを見せるだけではなく、会話と、これらすべての異なるファイルのピースを見せて、エディタでできるようにそれに手を伸ばして相互作用できるようにすることです。
とても素晴らしいですね。ありがとう、Nathan。あなたは長い間、自分のクラフトのための完璧なツールを構築する探求をしてきました。そして、Zedであなたがやったことを見るのはエキサイティングです。エージェントとのインターフェースやDelta DBで何をするのか、待ちきれません。今日は参加してくれてありがとう。
ええ、どういたしまして。本当に楽しかったです。
コメント