さらなる課題
AI プログラミングの次のフェーズに向けた、いくつかのエキサイティングな課題領域。
最初の課題に関する投稿の続編として、AI プログラミングの次のフェーズに向けて、私たちが特に重要だと考えている課題をさらにいくつか紹介します。
次のアクション予測
Cursor には、次の編集を予測できる、より高性能な Copilot の進化版である Copilot++ が搭載されています。このアイデアを、論理的な極限まで突き詰められないでしょうか。
コーディング中に行うのは、低エントロピーな edits だけではありません。エディタ全体では、低エントロピーなキー入力やクリックといった actions を行っています。これら一つひとつを、低レイテンシで予測するモデルを作れないでしょうか。
まずは、Copilot++ を拡張して、次に移動する場所を予測できるようにしました。これを次の編集予測と組み合わせることで、モデルは低エントロピーな変更のシーケンスを一気に再生できます。
次に移動するファイル。次に実行するターミナルコマンド。さらに、直前のターミナルコマンドに条件づけられた次の編集。こうしたものを予測する 次のアクション予測モデル を開発しています。
さらに、モデルはあなたが必要とするその瞬間に情報を提示できる必要があります。適切なコード片であれ、ドキュメントであれ同様です。
Cursor は、あなたの意志の延長のように感じられるべきです。変更を思いついたその瞬間に、それを即座に実行するために言語モデルに伝えるべき意図は、ほんのわずかで十分であるようにしたいと考えています。
有望な方向性
-
コードベース全体にわたる action prediction に関する基礎研究。
-
約 5–13B のアクティブパラメータを持つコードモデルへの継続的な事前学習・事後学習(prefill が支配的な低レイテンシ予測のため)。
-
Speculative Edits に類似した、さらなる推論テクニック。
「アクション」を邪魔にならない形で提示するための巧妙な UX。(ユーザーが次に移動すべきファイルや、現在のビューポート外の次の場所をどのように提案するか、など)
理想的な編集
より高品質で、より大きな編集を生成するために、推論時の計算リソースをスケールアップできるでしょうか?増加したレイテンシ(待ち時間)にはどう対処すればよいでしょうか?
編集をバックグラウンドで実行する必要があるかもしれません。信頼できるインテリジェントなモデルに、ひとまとまりのタスクを任せるイメージです。
そのためには、エディタ特化の高度なツール活用能力、コードベース全体を賢く把握するコンテキスト、そして長期的な推論能力が強化されたモデルが必要になります。
さらに、非同期なコード生成をフローを崩さずに実現するにはどうすればよいでしょうか。一見矛盾しているように聞こえますが、モデル能力とUXに関する巧妙な研究によって、これは実現可能だと考えています。
ハルシネーション疑似コード
ユーザーは、望む変更内容を記述した疑似コードを書きます。あとは Cursor に任せれば、その疑似コードをバックグラウンドで完全な変更へとコンパイルしてくれます。
マルチファイル編集
Cmd-k はすでに強力ですが、コードベース全体に同じ種類の編集を一括で依頼できたらどうでしょうか? とくに、それが複数ファイルにまたがっても正確に反映されるとしたら?
有望な方向性
-
推論時に使う計算リソースのスケーリング。
reward modelsやrejection samplingによって手軽に改善が得られることは分かっていますが、そこからどこまで伸ばせるでしょうか? -
より高性能な推論モデル(gpt-5、claude-4、gemini 2.0)
-
特定のユーザーのワークスペースに対して、複数の language server / file system のコピーを動かすこと。これには、モデルによるツール利用や、ランタイム環境をリモートで再現することが必要になります。
-
エージェントの軌跡(行動履歴)を用いた学習/モデル性能の向上
-
フローを途切れさせない非同期編集に向けた大規模な UX 実験
最適なコンテキスト
ドキュメントには数百万トークン、ソースコードには数千万トークン、コミット履歴にもさらに数千万トークンといったように、単一のクエリを解決するために役立ちうるトークンが膨大に存在します。
それだけでなく、UI 上のピクセル、本番環境やローカルホストのログ、Slack 上のメッセージなどもあります。
こうしたあらゆる情報を取り込むために、最良のコーディングシステムは、リトリーバル(retrieval)、リカレンス(recurrence)、および長コンテキスト対応のアテンションを組み合わせて活用するようになると考えています。
ここで システム と強調しているのは、短期的には、コーディングのための「無限コンテキストエンジン」を構成する複数のモデルとインフラのアンサンブルになる可能性があるからです。長期的には、それがモデルのアーキテクチャ自体に組み込まれていくことを想定しています。
特に、検索の未来を創造的に考えるときに強い関心を持っています。埋め込み(embeddings)を超えて、「高コストなインデックス構築ステップ」と「低コストなクエリステップ(コーパスサイズに対して劣線形)」というプリミティブが与えられたときに達成しうる、最高の性能とは何かという問いです。
それは、おそらく transformer memory as a differentiable search index のある種の変種のようなものかもしれませんし、まったく別の何かかもしれません。まだ十分に探究されていない研究分野です。
マルチホップコンテキスト
自分のコードベース内で、2つの文字列の差分を計算したいとします。Embedding を使うと、次のようなチャンクが返ってきます。
function computeDiff(
firstModel: ITextModel,
secondModel: ITextModel,
): string {
// ...
}元のクエリを満たすには、文字列から ITextModel を作成する方法を見つける必要があります。これは、解決するのに 2 ホップ必要なクエリです。
コードベースにおける最も難しい質問やクエリは、複数のホップを必要とします。通常のリトリーバルでは 1 ホップまでしか対応できません。
有望な方向性
-
コードベース向けに特化/改良された embeddings と rerankers。
-
マルチホップ embedders の学習。クエリと、これまでに見つかった関連コードを入力として、次にホップすべきコード片を判定する。
-
コードベースにより適した、巧妙なプレフィックスキャッシュやカスタム attention masks。
-
コードベースレベルの検索・取得に関する新しい研究。
-
Transformer を検索インデックスとして使う場合と同様に、コードベースをモデルの重みとして「学習」させること。
バグ検出とデバッグ
既存のバグ検出システムは、精度調整とコードベースの十分な理解の両方に苦戦しています。
モデルはバグを正しく特定できるほど賢い一方で、多くの誤検知に悩まされています。最も厄介なバグを見つけるには、コードベースをより深く理解する必要があります。また、一見バグっぽく見えるコードも、全体像を踏まえると問題がない場合があります。
その一例として、言語モデルを活用した、より優れたコードレビュー体験が考えられます。
AI レビューでバグを検出する
「AI レビュー」の利点は、ユーザー自身がレビューをリクエストしているため、誤検知(false positive)に対して比較的寛容になれる点です。一方で、ユーザーの行動を変えてもらう必要があるという欠点があります。
AI リンティング
バグ検出の最良の形は、常時オンでバックグラウンドでバグを検知してくれるリンターです。これは、1 分間に何度も実行する必要があるため、AI レビューよりも低コストかつ高速なモデルでなければなりません。また、誤検知率がより低くなるようにチューニングされている必要があります。
よりスマートなデバッグ
バグ検出以上に印象的なのは、難しい問題のデバッグです。
LLM ベースの静的解析だけでは不十分です。たとえば、私たちは cursor/debug パッケージを開発しました。これをコードに組み込むと、実行時情報を追跡できます。
バックグラウンドでは、追加の変数状態を追跡することもできます(関連する出力を Cursor のコンテキストに流し込む、プリントデバッグのようなイメージです)。
有望な方向性
-
キャリブレーションを改善するための、賢いデータセットキュレーション(おそらく合成データ)と、最先端コードモデルへの RL の適用。
-
他のインターフェース(ブラウザや非統合ターミナル)から関連情報を追跡する。
-
デバッガ特化のツール利用やチェーンにおける、最先端モデルの性能を向上させる。
-
無限に近いコンテキストと、コードベースのほぼ完全な理解。
-
すべての有用なプログラム状態情報をトラッキングできるよう、
cursor/debugライブラリの機能範囲を拡張する。
これらの課題のいずれかに関心があれば、hiring@cursor.com までご連絡ください。