CursorがClaudeと共に構築するAIコーディングの未来

この動画は、AI搭載コードエディタ「Cursor」の開発チームとAnthropic社のClaude Relations責任者による対談である。CursorがClaudeを活用してどのようにAIコーディングの未来を構築しているかについて詳しく議論されている。わずか1年で3億ドル以上の収益を達成したCursorの急成長の背景、Claude 3.5 Sonnetの登場がもたらした変革、そして自己改善的なフィードバックループの仕組みが語られる。さらに、新しく発表されたバックグラウンドエージェント機能、大規模コードベースでの課題、コード検証の重要性、そして最新のClaude 4モデルの活用についても言及されている。プログラミングの未来がどのように変化し、開発者の役割がどう進化していくかについての洞察に満ちた内容となっている。

Cursorの急成長と変化

ソフトウェア制作のあらゆる側面が、何らかの形でAIを使用するように変わっていくと思います。

本日はお越しいただき、ありがとうございます。この対話をずっと楽しみにしていました。ご存知の通り、私はアレックスです。AnthropicでClaude Relationsを担当しています。

私はルーカスです。CursorでエージェンティックシステムEの仕事をしています。

私はアマンです。創設者の一人で、CursorでMLと検索の仕事をしています。

私の名前はジェイコブ・ジャクソンです。CursorでMLの仕事をしています。

この対話をとても楽しみにしており、Cursorについて、皆さんが構築しているもの、そしてClaudeをどのように使用しているかについて少しお話しできることを嬉しく思います。

Cursorにとって大きな年でした。AI業界を追いかけている方なら誰でも明らかです。皆さんはわずか1年余りで3億ドル以上の収益にまで成長しました。かなり驚異的で、現在数百万人の開発者がCursorを使用しています。あなたの意見では何が変わったのでしょうか。そして今日のCursorのバージョンは1年前とどう違うのでしょうか。

変わったことはいくつか大きなものがあると思います。

現在の言語モデルのレベルを考えると、それらでどれだけのことができるかという点で、常に大きなオーバーハングがありました。そしてCursorは、少なくともコーディング分野において、その格差を少し埋めることができた最初の企業の一つだったと思います。多くの異なる機能を通じてですね。そして今度は、これらのモデルがコーディングにおいて非常に、非常に優れたものになっているのも見てきました。そして3.5 Sonnetがプログラミングにおけるこの種のステップファンクション的な改善の最初の明確な例だったと思います。

それ以前は、Cursorはタブ補完のようなもの、つまり次の編集を予測することに本当に役立っていました。それだけでも、かなり急速に成長していましたし、単一ファイル内での編集もできました。しかし、3.5 Sonnetのようなモデルの知能と、検索に使用するいくつかの他のカスタムモデル、そしてこの大きなモデルによって作られた編集を適用することを組み合わせると、マルチファイル編集ができるようになったことがわかりました。それがCursorの大量採用につながったステップファンクションだったと思います。それ以来、モデルが良くなることと、私たちがこれらのモデルをどこまで押し進められるかという点で、内部的により良くなろうとすることの組み合わせでした。

モデルの進歩と自然な発展

それは自然な進歩だったのでしょうか、それとも何か偶然生じたものだったのでしょうか。それとも3.5 Sonnetの最初のものが出たときに、皆さんは「すごい、今度は以前は不可能だったこれらすべての異なることが突然できるようになった」と気づいたのでしょうか。それはどのような感じでしたか。

それはある程度段階的に感じられました。

モデルの品質にはこれらのステップがありますが、以前の最先端モデルでその兆候を見ていました。実際、私たちはこれらのモデルのテイストテストが非常に苦手なことで有名です。なぜなら、私たちの使い方が、それを世に出して他の人がどう使うかを見るのとは非常に異なるからです。

しかし、時間が経つにつれて、出てくる新しいモデルそれぞれが、推論、よりエージェンティックな種類のコーディングができるようになってきているという兆候がありました。そして多くの微調整と多くのことを試すこと、何が機能し、何が失敗するかを見ることでした。Sonnetがマルチファイルの相互作用を本当にうまく機能させることができた最初のものだったと思います。

それ以来、ツール使用などの多くのステップファンクションがありました。そうすれば、これらのモデルをエディタ内で本当のエージェントのように動作させることができます。

なるほど。新しいモデル、新しい機能の進歩が時間とともに、さらなる微調整、探索を可能にし、それがある程度あなたの製品に反映され、新しい機能を構築できるようになるわけですね。

そうです。

自己改善フィードバックループ

それは興味深く、次に触れたい質問につながります。あなたのチームがCursorを構築するためにCursorを使っているという話をたくさん聞いたことがあります。これは自己改善する再帰的フィードバックループのようなものです。まず、それがどのような感じなのか、日々の業務において、皆さんがCursorで新機能の構築に取り組んでいるときにどのような感じなのかについて詳しく教えてください。

それは従業員それぞれの個別の使用ケースに非常に依存すると思いますし、あなたが作業している製品のどの部分か、そしてその部分がどのような段階にあるかにも非常に依存すると思います。

最初にコードベース、新しい機能をレイアウトする場合、エージェント機能を使って開始し、次に思考モデルを使って直面している個別のボックスを見て、非常に正確な編集を行う場合は、多くのタブも使用します。そして、あまり知識のないコードベースを開始する際に使用するQA機能を多く使用し、多くの検索を使用します。これはClaude 3.7と3.5も非常に優れている分野で、コードベースで研究を行い、特定のものがどのように相互作用するかを理解することです。

なるほど、これらの機能を使ってコードベースを探索することで、プロセスが簡単になり、これらの機能を使いながら、ああ、この分野に欠陥があるから、そこに取り組むべきだということを学ぶわけですね。

はい、簡単になると思います。Cursorは自分たちの問題を解決し、問題を解決するのに苦労している場所を把握し、Cursorを改善することに非常に駆動されています。そして、そこで何ができるかを把握し、多くの実験を行います。誰もが物事を試し、製品に新機能を追加してみて、内部でどのように使用されるか、どのようなフィードバックが集まるかを見るという哲学があります。

自社顧客であることの利点

よりメタレベルで、内部で自分たちが最高の顧客であることの利点があると思いますか。

100%そうだと思います。それが新機能を構築する際に非常に迅速に動き、明らかに機能しないものを捨てることができる理由です。なぜなら、それが役に立つかどうかについて自分たち自身に非常に正直になれるからです。そして、ユーザーに出荷し、人々がどのように使用するかを追跡してから機能を進めるかどうかを決定する必要がありません。機能を構築するための反復ループを単純にスピードアップすると思います。

全体的にAIを使ってプログラムする方法に戻ると、会社内で異なる人々がそれを使う方法に多くの多様性があると感じます。まず、あなたが行っている仕事の種類によって異なると思います。例えば、本当に慣れ親しんだコードベースの部分で作業している人々がいます。その時点で、それがすべて頭の中にあるとき、意図を伝えるのはコードを打つことによってより速いことが多く、その場合Tabが本当に役に立ちます。なぜなら、そこでスピードアップしてくれるからです。

しかし、あまり慣れ親しんでいない場所にいるとき、または多くのコードを書き出す必要があるときは、その多くと推論の一部をこれらのモデルにオフロードできます。そして、ルーカスが説明しているように、新しいコードベースに来て本当に慣れ親しんでいない場所に行くとき、これらのモデルを使用することで得られる大きなステップファンクションがあります。そして、時間が経つにつれて、モデルが良くなり、Cursorがこれらのモデルを使ってより良くなると見ているのは、より流れに乗っているとき、コードベースについてより多くの知識を持っているときに、より良い、より良い仕事をするということです。

機能のスペクトラム

使用ケースに最も適用可能な機能に変動があり、ある程度スペクトラムのようなものですね。

はい、一端では、完全にコントロールしていて、何をしているかわかっているときのTabがあり、それから単一の指定領域、おそらくファイル全体を編集するCommand Kに進み、他端では複数のファイルを編集するのにかなり良いエージェントがあり、最後に私たちが取り組んでいるバックグラウンドエージェントがあり、それは基本的に完全なPRを行うのに役立ちます。

バックグラウンドエージェントの新機能

皆さんはバックグラウンドエージェントのプレビューを発表しました。バックグラウンドエージェントとは何ですか。

モデルがエンドツーエンドのタスクをますます上手にこなせるようになっているが、まだ100%ではないことは明らかだと思います。100%に達するまでにはしばらく時間がかかると思います。

開発者をスピードアップする方法は、これらのことを並行して行わせることです。しかし、単にバックグラウンドで実行させて、GitHubで見るPRをスピンアップするのではなく、90%しか完了していない場合、入って制御を取り、残りを行いたいのです。そして、そのためにCursorの機能を使いたいのです。

バックグラウンドとフォアグラウンドの間を迅速に移動できることが本当に重要です。この機能の初期段階にいると思いますが、例えば3つまたは4つの変更に同時に取り組み、それらを迅速にバックグラウンドにポップし、フォアグラウンドに移動するなど、多くの興味深い操作方法があると想像できます。

これが人々のCursorの使い方、そして一般的なソフトウェア開発の方法をどのように変えるかを見るのは興味深いでしょう。

バックグラウンドエージェントを、非常に多くの異なる場所で使用できる新しいプリミティブとして基本的に見ています。現在の公開方法は非常に直接的で、プロンプトを取得してバックグラウンドにプッシュし、それが独立して反復するというものです。

しかし、これらのものがどのようにスポーンオフされるかについて、さらに多くの統合があり得ますし、そこから作成できる多くの製品があると思います。

これはあなたのコードベースを仮想マシンに置くということですか。正確にはどのような転送が起こっているのでしょうか。

まさにそうです。

わかりました。

すべての開発者環境ユーティリティがすでにインストールされた十分に小さな独立環境があり、エージェントはそれらを使用でき、利用可能なすべてのVS Code拡張機能を持っており、それを通じて取得できます。

非同期タスクの未来

コーディングから研究まで、多くの異なるもので非同期タスク、バックグラウンドタスクのこの傾向を目撃していることはわかっています。あなたの見解では、これが進行して、数千のこれらのエージェントが潜在的に実行され、エージェントのチーム全体がすべてバックグラウンドで問題を攻撃するのを見ることができるようになると、どのような感じになるでしょうか。

その未来はどのような感じでしょうか。

次に遭遇するボトルネックは、ソフトウェアの検証、コードの検証になると思います。モデルは本当に、本当に多くのコードを生成し、書くのが上手になっていますが、開発者が時間の30%をコードを書くのに費やし、70%をコードをレビューするのに費やすと仮定しましょう。適当な数字ですが。

コードを書くことを完全に解決しても、ソフトウェアエンジニアリングを3倍以上スピードアップしたことにはなりません。そうですから、人々がコードをレビューしやすくし、エージェントが行っている変更が正しいだけでなく、正しいということは曖昧な場合があります。指定したことかもしれませんが、最高の人間プログラマーでさえ可能だった最善のことを実際に行うのに十分に仕様不足だったかもしれません。しかし、実際にあなたが心の目で持っていたものであり、そのプロセスをはるかに、はるかに良くすることが本当に、本当に重要になると思います。それは私たちも本当に興味を持っていることです。

コード検証の改善アイデア

そこでの初期のアイデアはありますか。どのような感じになるでしょうか。

コードベースの異なる表現で操作するというアイデアなど、会社のさまざまな人々からいくつか浮かんでいると思います。マイケル、私たちのCEOが本当に、本当に気に入っているものの一つです。

疑似コードのような見た目で、この本当に簡潔な方法で変更を表現でき、実際のソフトウェアで行われた実際の変更にきれいにマッピングされるという保証があれば、検証時間を大幅に短縮できるはずです。しかし、それは可能なルートの一つです。

いわゆるバイブコーディングが機能することが多い理由は、検証プロセスが本当に簡単だからです。すべてがただソフトウェアで遊ぶことだからです。変更を加えて、実際に構築したソフトウェアで遊ぶのです。実際の本番コードベースではそれを行うのが本当に困難になると思いますし、その問題を解決することは本当に重要です。

本番コードベースでの課題

バイブコーディングをしているスタンドアロンのものと、数百万、数百万行のファイルを持つ本番コードベースとの違いについての良い質問があります。皆さんは心の中でそれら二つの違いをどう見ていますか。そして現在のモデルでそれらの中で作業する点で、どこにいるのでしょうか。

バックグラウンドエージェントでそれについて多く考えたことだと思います。なぜなら、これらのモデルで本当に簡単で明らかに非常に簡単であるべきことの一つは、ここにテストがあり、テストは現在失敗していて、テストが通るようにコードを修正できるかということです。さて、どうやってそれを実現するのでしょうか。

モデルがテストを実行できる必要があります。非常にシンプルなリポジトリがあれば、それは非常にシンプルですが、これらの大きなエンタープライズコードベースに移ると、モデルがテストを実行できるように依存関係を適切にセットアップすることが複雑になり得ます。

しかし、これはバックグラウンドエージェントで多く考えたことです。開発者がエージェントがテストを実行できるこの環境を作成するプロセスをどのように直接的にし、コード状態が変更されたときに迅速に更新できるようにスナップショットできるように繰り返し可能にするかです。これにより、バックグラウンドでVMをスピンオフし、モデルに実験をさせ、いくつかは通過し、いくつかは通過しない能力が解放されます。

そして最終的に、開発者としてのあなたは、成功した場合についてのみ心配すればよく、そこには多くのインフラストラクチャと、正しくする必要がある多くのユーザーエクスペリエンスがあります。

大規模コードベースの根本的問題

そして他の根本的な問題があると思います。一つの方法は、モデルにテストを通過させようとさせることです。それが何らかの正しさを保証する方法です。

しかし、これらの大きなコードベースでは、独自の言語のように見えるものを扱うことが多く、いくつかの言語内でこれらの種類のDSLを持ち、すべてがこの特定の方法で行われ、数百万のファイルにわたって本当に広がっているもので、それは数億のトークン、おそらくそれ以上になる可能性があります。

これをはるかに良くするために、検索モデルの訓練と、他のコンテキストソースの統合も含む多くのことを行いました。例えば、最近行った変更には多くの豊富さがあると想像できます。コードを編集するとき、それは作業している方向を示します。

チーム内の他の人があなたのコードベースで行った変更、特に最近のものにも豊富さがあり、それらをヒントとして使用できます。しかし、本当に良い検索にモデルがアクセスできるようにするだけでは、モデルがコードベースを本当に理解するには不十分だと思います。私たちが解決に本当に興味を持っている問題だと思います。

おそらくメモリと長いコンテキストなどの組み合わせを通じて。

メモリは、人々がモデルにその使用から学習させるために取った興味深いアプローチの一つだと思いますが、パフォーマンスの小さな向上のように感じられ、大きなコードベースで優れたものを得るために必要な場所と比較して、かなりプリミティブに感じられます。

コード構造とガイドラインの重要性

大きなコードベースでは、テストを通過させることだけではなく、正しい方法でそれを行うことについてでもあります。既存のコードを見て、新しいコードをそれに合わせ、正しい構造に持ち込み、すべてのガイドラインを正しく使用することです。Cursorルール、異なる種類のコンテキストの統合などを通じて、それを実現しようと非常に努力してきました。

スクラッチから深いバウンス関数を書いて、それを使うだけでテストを通過させることができますが、それは正しい方法ではありません。デバウンスの一つを使うべきで、コードベース全体で使用される3つまたは4つのデバウンス関数があるかもしれません。

どれが使うべき正しいものかをどうやって知るのでしょうか。多分誰かがSlackで「これがやり方だ」とメッセージを送ったからという理由だけで知っている人がいるかもしれません。そして、非常に大きなコードベースでこれらの問題を解決することは本当に、本当に困難になると思います。

それは興味深いです。コードベース自体の外に存在する組織知識の要素もあり、それが特に大規模なコードベースで操作しているときに、これらの決定の主要な要因になることがあります。

今日のボトルネックだとは思いませんが、もしモデルを完璧にし、コードベースを知ることで、5倍、10倍の改善を得られるかもしれませんが、それ以上は進めません。なぜなら、今度はPRや実際のコードの状態で明示的に言及されたり、示されたりしたことのないこれらのことをどれだけ知っているかによって完全にボトルネックになるからです。

そして、ビジネス側から、営業などからの外部の懸念もあります。そして、それらをCursorに持ち込んで機能させる必要があります。

明確にしておくと、他のことと比較して、それが本当に、本当に重要になるまでには、まだいくらか時間があると思います。ユーザーが持つ相互作用、コードベースの詳細、コミットされた内容を使用して、Cursorをはるかに良くするために、まだ長い道のりがあると思います。

LLM最適化コードの変化

興味深いことの一つに、少なくともWebページやコンテンツで、人々がLLMが読んで閲覧するためにページを最適化する方法を考えようとしているのを気づき始めました。

主に人間のレビューアーと、コードベース内で作業する人間のために書いていたコードから、モデルのために書くコードへと、コードが変換される可能性がある類似のものが見られると思いますか。

それは既に完全にそのケースだと思います。API設計は既に、LMSがより快適になるように調整されています。

例えば、内部のバージョン番号を変更するだけでなく、これが何らかのソフトウェアの新しいバージョンであることをモデルに非常に見えるようにして、APIが正しく使用されることを確実にします。そして同じことが通常のコードベースや内部ライブラリにも当てはまると思います。そこでは、エンドレベルの相互作用を通り抜ける必要がなく、おそらく2レベルの相互作用だけを通り抜けるようにコードを構造化することで、LLMモデルがそのコードベースで作業するのが良くなります。

しかし、人々とモデルによって読まれることを望む場合、クリーンソフトウェアの原則は根本的にそれほど異なりません。クリーンなコードを書こうとするとき、自分自身を繰り返さず、必要以上に複雑にしないことを望みます。そして、それは人々にとって重要であるのと同じようにモデルにとっても重要です。

これらのモデルが良くなるにつれて、コードの味覚と、必要以上に複雑でないクリーンなソリューションとは何かが実際にさらに重要になると思います。なぜなら、より多くのコードを書くことがより簡単になるので、味のある方法でそれを構造化することがますます重要になるからです。

プログラミング教育とスキル開発

味覚についての本当に良い点です。

味覚は、一部の人々が他の人より多くの味覚を持って生まれてくるようなものかもしれませんが、一般的に経験を通じて味覚を発達させ、何が機能するかを学び、失敗と成功を見ることです。AIに私たちのコードのより多くを書かせている世界で、プログラマーを怠惰にしたり、ジュニアに大きなコードベース内で作業し、これらすべてのことを行うことが実際にどのような感じかを学ぶ機会を与えないという本当の反発がありました。

この種の自動化や支援とソフトウェアエンジニアが通らなければならない、それらの試練と苦難のようなコアエンジニアリングスキルを保持することとのバランスをどう考えますか。

これらのツールは教育的にも非常に良く、優秀なプログラマーになるのを助けることができると思います。

何かがどのように機能するかについて質問がある場合、何らかの概念を説明してもらいたい場合、Command Lを押してClaudeに「これは何ですか？どのように機能しますか？説明してもらえますか？」と尋ねることができます。それは非常に価値があると思います。より多くのコードを書き、より多くのことを行うことを簡単にし、それがより高品質とより低品質のコードが出回ることにつながる可能性があります。

それは真実ですが、一般的に、基準を上げる非常に、非常に強力なツールだと思います。

品質は迅速な反復、間違いを犯すこと、なぜ特定のことが失敗するかを理解することから非常に来ると思います。そしてモデルはこの反復プロセスを大幅に加速し、実際にそれを通じて、何が機能し、何が機能しないかをより迅速に学ぶことができると思います。

長期的には、開発者が始めたばかりで、より大きく、より大きなプロジェクトに取り組み、何が機能し、何が機能しないかを理解するのに超役立つツールだと思います。

プログラミングがどのように進化するかを見るのは本当に興味深いと思います。非常に長い間、詳細を知っているエンジニア、詳細に入り込める権利が必要だと思います。

多くの詳細を知らないが、それでもかなり効果的である、今プログラミングを学んでいる人々をどれだけ見始めるかと思います。今日でも、まだ多くの詳細を知る必要があると思います。時間が経つにつれて、非常に少ない低レベルの詳細を知る必要があり、それでもより高いレベルで操作でき、それは味覚のより多くがUX味覚のようなものである、より高いレベルでの思考により多く似ているかもしれません。

例えば、Notionのようなものを構築しようとしているとしましょう。最終的には、その全体を言語モデルにオフロードすることはできないと思います。この種の相互作用を行うとき、この特定の方法でポップアップすることを期待すると説明する必要があります。それを行う純粋なソフトウェアを書く詳細に入る必要はないかもしれませんが、それでもそれらの相互作用を説明し、このものが大体どのように機能するかを説明することです。それはプログラミングの一形態です。

新しいClaudeモデルについて

モデルのトピックで少し話を変えて、このビデオが出る頃には、Claude Opus 4とClaude Sonnet 4が世に出ているでしょう。新しいモデルについてのあなたたちの考えと、Cursor内でそれらをどのように統合し始めているかを聞きたいと思います。

新しいモデルを本当に楽しんでいます。

新しいSonnetを試して、本当にショックを受けました。3.7は素晴らしいモデルだと思うからです。エージェンティックコーディングではより良かったですが、誰もがそれには欠点があることを知っていました。少し熱心すぎるかもしれません。

多くのことをするように。

そうでした。テストを変更して、それらが通過するようにしたがることがありました。

Sonnet 4はそれらすべてを効果的に修正し、はるかに良く、知能も大きなステップアップでした。知能のステップアップである他のモデルを見てきましたが、エージェンティックコーディングにはそれほど強くないかもしれませんが、O3は例であり、はるかに安いモデルであるにもかかわらず、それと互角に戦えることがわかりました。

そして、Opusについて非常に興奮しています。なぜなら、バックグラウンドで使用する素晴らしいエージェントになると思うからです。

モデル開発の背景

それを聞くのは素晴らしいです。テスト書きと熱心すぎることは、これらのモデルで非常に激しく取り組もうとしていたことで、RLでモデルが最終的な報酬に到達するためのショートカットを基本的に見つける報酬ハッキングの概念です。

それを削減するために多くの作業を行いました。これらの新しいモデルで80%削減したと思います。

3.5 Sonnetがどのように生まれたかについて本当に興味があります。なぜなら、それはAnthropicにとって本当に良いコーディングモデルのような最初のパンチのように感じられたからです。

どのように生まれたのでしょうか。私たちが訓練しました。ただ、良かったのです。

私たちは長い間、おそらく会社の創設から、モデルをコーディングで本当に良くしたいということを常に知っていたと思います。特に、より多くのモデルを作るにつれて、他のすべてのことにとって重要に思えるからです。

3.5 Sonnetは、3-Opusも本当に良いコーディングモデルでした、特にその時代においては。しかし、3.5 Sonnetは、ヘイ、これらのモデルをコーディングで良くしようという強い専用の努力を本当に最初に行った時でした。しかし、ただ特定のコーディングだけでなく、異なるファイルで編集を行う、ここでコマンドを取得し、ツールを呼び出してから、他の場所で変更を行うような、より長い水平線のコーディングでした。

それがすべてをまとめることができた最初のモデルで、本当にうまくいったと思います。そして、私たちの将来のモデルがどのようになるかの舞台を設定したのです。

モデルの専門分野とバランス

皆さんはSonnetとOpusが優れてほしいコードと他の分野についてどう考えますか。

コードは主要分野の一つですが、唯一の分野ではないと思います。モデルがコードで本当に良くなることから、多くの推論を取って多くの行動を取り、このエージェンティックな方法で作業することでただ良くなることへの良い転移があると思います。そして、その持ち越しは、コードを混ぜるかもしれないが、他の場所から知識を取得したり、研究を行ったりする必要があるアプリケーションを扱うときに非常に良いです。

一般的に、私たちはモデルで可能な限りフロンティアを押し進めることに関してです。もちろん、安全性を中心とした考慮事項と、ユーザーとしてのあなたが望むものと、私たちがモデルがすべきだと信じることに沿ったモデルであることを確実にすることがあります。しかし、一般的に、これらのモデルができることの限界を押し進め、開発者と世界にモデルが何ができるかを示したいと思います。

10月に公開したコンピュータ使用のようなことも、モデルが主に人間のインターフェースであるものを実際にナビゲートするのが良いかという点で、私たちが本当に前進を押し進めている別の方向でした。APIやツール呼び出しやそのようなものの世界ではありません。人間のように画像を見て、そのスクリーンに行動を向けなければならないのです。

これらのモデルのキャラクターについてどう考えるかにも強い部分があります。現在はキャラクターとして知られており、アマンダ・アスケルがこの努力のリード研究者の一人で、Claudeのキャラクターを作成し、Claudeがどのような感じで、どのような音がして、AIが誰かの人生で本当に重要な役割を果たすことの意味について多くの思考と考慮を行っています。

ただのコーディングエージェントとしてではなく、ある意味での親友のような、多くの時間を話し相手として過ごすエンティティとして。それも、これらのモデルを中心とした私たちが行うすべての決定と、どのように訓練するかに本当に組み込まれています。

将来の展望

Anthropic全体として、ソフトウェアエンジニアリングの観点と、研究の観点の両方で、これらのモデルがどれだけ作業を拡張、置換、多く行うかという点で、物事がどこに向かっているかについてどう考えますか。

個人的にここで話すことができます。個人的には、先ほど話したように、置換するつもりはないと思います。モデルが基本的にあなたのためのコードのタイピングのナットとボルトをすべて行えるようになったので、できることがはるかに多くあります。

私自身でもそれを見ています。大学でコンピュータサイエンスを学び、ソフトウェアエンジニアリングを行いましたが、今ではモデルが私よりもコードを生成するのが良い地点にいると感じています。LeetCodeの問題や、それに似たようなもの、含まれた環境でモデルがコードを書かなければならない場合を考えるだけなら、それは私を負かすでしょう。それでも、これまで以上に多くのことができると感じています。

何でもプロトタイプを作ることができます。新しい概念を見せたい場合、超、超高速でデモをスピンアップできます。それは、私がやってきたことを奪うか軽視するというよりも、その意味で非常にエンパワーメントを感じています。そして、過去からソフトウェアエンジニアリングの知識を持っているからこそ、実際にそれをはるかに良く活用でき、単にコードが何かについてまだアイデアを持っていない場合よりも、モデルをより遠くまで押し進めることができると感じています。

2027年の予測

より楽しい将来の推測に入ると、実用的な質問をしたいと思います。数年後にこれに戻ってきて、どうなったかを見ることができます。2027年1月1日、今から2年弱、何パーセントのコードがAI生成されると思いますか。そして、それに続いて、現在自分を開発者だと考えている人の1日の生活はどのような感じになるでしょうか。

それは、生まれる前、1995年に戻って、将来法律文書の何パーセントがワープロ生成されるかを弁護士に尋ねるのと似ていると思います。答えは100%、または100%に近いのは、AIがほぼすべての書かれるコードに関与するからです。

しかし、弁護士または開発者としてのあなたの役割は、コードが何をする必要があるかを理解し、味覚を持ち、ソフトウェアで何が行われるかを導くことが、これまで以上に重要になるでしょう。

既にCursorでは90%以上だと思いますが、それは多くの部分がエージェントのようなより高レベルの機能を使用しているからです。

そしてCommand Kなどです。しかし、多くの場合、あなたがタイピングしていて、タイピングしながらTabがその70%を行います。

そうです、実際に手動で自分で行っているケースでは、Tabがそれらの変更のほとんどをまだ行っています。

実際にタイプされた文字は非常に、非常に低いパーセントです。しかし、ソフトウェアを制作するあらゆる側面が何らかの形でAIを使用するように変わると思います。

ソフトウェアオンデマンドの世界

ソフトウェアオンデマンドのような世界に到達することは可能だと思いますか。それはどのような感じになるでしょうか。

以前にソフトウェアを構築していなかった人々、組織機能の人々がソフトウェアを構築しているのを見ることになると思います。例えば、以前は自分のツールを構築していなかった営業の人々が、今では自分にとって重要なことを追跡するためのダッシュボードを構築しています。

味覚がこれまで以上に重要になることに戻ると、今ではダッシュボードを構築できますが、ダッシュボードがどのメトリクスを表示するかを決定する必要があります。それを決定することを防ぐものではありません。

多くの人が自分のソフトウェアを構築するのを見ることになると思いますが、既存のニーズによって適切にサービスされていない、ソフトウェアでやりたいユニークなことを持つことによってボトルネックになるでしょう。

私たちが気に入って人々に話している例の一つは、私たちのコミュニケーションチームの人が、実際にClaude.aiのバグフィックスを出荷していることです。

組織の完全に異なる部分にいて、製品にまったく触れていないのに、PRでポップインして、スタンプを求めているようなもので、あなたは「何をしているのですか？」という感じです。そして、Claude codeやClaudeをベースモデルとしたコーディングツールを使って、本番コードベースのバグを修正しているのです。

それも素晴らしいと思います。そして、これは一般的な、ヘイ、味覚があり、良い直感があるなら、単純にこれらのもので多くのことができるということに結びつきます。世界はそのように進歩し続けると思います。5年、10年後には物事は変わり、役割は大きく異なって見えると思いますが、一般的に、これらのもので多くのことができるなら、それは一般的に常に良いことになると思います。

多くの興味深いパスがあると思います。一つは、完全にオンザフライのオンデマンドソフトウェアで、私が自分のバージョンのアプリを使っていて、私が使っているだけで、この相互作用があまり好きでないと、それが私のために変わるというものです。これは、あなたが積極的にそれを行っているのではなく、それとの相互作用に基づいて、ソフトウェア、あなたが使っているものが何でも、あなたに合うように変わるという素晴らしい潜在的な未来の道です。

世界の全員が自分のソフトウェアを構築したいと思うかはわかりませんが、自分のニーズに合うソフトウェアから恩恵を受けることができる人々のサイズは、潜在的に全世界だと思います。