最初の課題に関する投稿の続編として、AIプログラミングの次の段階で私たちが最も重要だと考える課題を、さらにいくつか紹介します。

次のアクション予測

Cursor には、次の編集を予測するより賢い Copilot の進化版であるCopilot++が搭載されています。この発想を突き詰められるでしょうか？

コーディングでは、低エントロピーな編集だけを行うわけではありません。エディタ全体で、低エントロピーなキーストロークやクリック、アクションを行います。これら一つひとつを低レイテンシで予測するモデルを構築できるでしょうか？

まず、次に移動する位置を予測できるように Copilot++ を拡張しました。これを次の編集内容の予測と組み合わせることで、モデルはエントロピーの低い変更を連続して実行できます。

次に移動するファイル、次に実行するターミナルコマンド、そして直前のターミナルコマンドに基づく次の編集――それらを予測することに取り組んでいます。つまり、次のアクション予測モデルです。

さらに、このモデルは、必要な瞬間に情報を提示するべきです。適切なコード片であれ、ドキュメントであれ。

Cursorはあなたの意志の延長のように感じられるべきです。変更を思いついた瞬間、言語モデルは最小限の意図だけで即座に実行します。

有望な方向性

• コードベース全体にわたるアクション予測に関する基礎研究。
• 約5～13Bのアクティブパラメータを持つコードモデルに対する継続的な事前学習および事後学習（prefillに制約される低レイテンシ予測のため）。
• さらに、Speculative Edits

押しつけがましくない形で「アクション」を提示する巧妙なUX。（ユーザーが次に移動すべきファイルをどう提案する？ あるいは、現在のビューポート外で次に行くべき場所は？）

完璧な編集

推論時の計算量をスケールアップして、より高品質で大規模な編集を生成できますか？ 増加したレイテンシーにはどのように対処しますか？

編集をバックグラウンドで実行する必要がある場合があります。信頼できるインテリジェントなモデルに、独立した作業単位を切り出して任せましょう。

エディタ特化のツール活用能力が高く、コードベース全体をより賢く把握でき、長期的な推論が強化されたモデルが必要になります。

では、非同期のコード生成をどのようにしてフローを保ったまま実現できるのか。矛盾して聞こえますが、モデル能力とUXに関する巧妙な研究によって可能になると私たちは考えています。

幻覚的な擬似コード

ユーザーは、望ましい変更内容を記述する疑似コードを書きます。あとはCursorに任せれば、バックグラウンドでその疑似コードを完全な変更にコンパイルしてくれます。

複数ファイルの編集

Cmd-kはすでに素晴らしいですが、コードベース全体に対して汎用的な編集を依頼できたらどうでしょうか？とりわけ、複数ファイルにまたがる変更を正確に反映できるものを。

有望な方向性

• 推論時の計算リソースをスケールさせる。報酬モデルやリジェクションサンプリングで素早く手軽な改善が得られることは分かっているが、さらにどこまで到達できるのか？
• 高度な推論モデル（gpt-5、claude-4、gemini 2.0）
• 特定のユーザーのワークスペースに対して、複数の language server／ファイルシステムのコピーを並行稼働させること。これには、モデルのツール利用と、実行時環境のリモートでの再現が必要になります。
• エージェントの軌跡に基づくモデル性能の学習／改善
• フロー内の非同期編集に向けた大規模なUX実験

最適なコンテキスト

ドキュメントが数百万トークン、ソースコードが数千万トークン、コミット履歴もさらに数千万トークンに及ぶことがあり、単一の問い合わせを解決するために有用となり得るトークンがこれだけ存在します。

言うまでもなく、UI のピクセル、プロダクションやローカルホストのログ、Slack のメッセージなど……

私たちは、最高のコーディングシステムは、リトリーバル、リカレンス、そして長文脈アテンションを組み合わせて、これらすべての情報を取り込むようになると考えています。

私たちはシステムを重視しています。短期的には、これはコーディングのための無限コンテキストエンジンを構成する、複数のモデルとインフラのアンサンブルになるかもしれません。長期的には、それがアーキテクチャに組み込まれると見込んでいます。

私たちは、リトリーバルの未来を創造的に考えるとき、特に高い期待を抱いています。エンベディングを超えて、コーパスサイズに対してサブリニアな「高コストなインデックス作成」と「低コストなクエリ」という原始的構成要素があるとき、どの程度まで性能を引き上げられるのでしょうか？

もしかすると、トランスフォーマーのメモリを微分可能な検索インデックスとして用いるといったバリアントに見えるかもしれません。あるいは、まったく別物かもしれない。未開拓の研究方向です。

マルチホップ・コンテキスト

私のコードベース内で、2 つの文字列の差分を計算したいと考えています。埋め込みを使うと、次のチャンクを取得します:

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel,
): string {
  //...
}

元の問い合わせに応えるには、文字列からITextModelを作成する方法を特定する必要があります。これは解決に二段階を要する問い合わせです。

コードベースで最も難しい質問やクエリには、複数のホップが必要です。バニラなリトリーバルは1ホップにしか対応しません。

有望な方向性

• コードベース向けに特化・改良された埋め込み表現とリランカー。
• マルチホップ埋め込みモデルの学習。クエリと、これまでに見つかった関連コードを与えられたとき、次にホップすべきコード片を特定します。
• コードベースにより適した、巧妙なプレフィックスキャッシングと、場合によってはカスタムのアテンションマスク。
• コードベース全体の検索・取得に関する新規性の高い研究。
• モデルに、検索インデックスとしてのトランスフォーマーに近い形で、重みの中にコードベースを学習させること。

バグの検出とデバッグ

既存のバグ検出システムは、校正（誤検出率の調整）と十分なコードベース理解の両面で課題があります。

モデルはバグを正しく特定できるほど高性能ですが、偽陽性に悩まされがちです。最も厄介なバグを見つけるには、コードベースへのより深い理解が必要です。また、一見バグっぽく見えるコードも、全体像を踏まえると無害な場合があります。

その一例として、言語モデルを用いたコードレビューの体験が大幅に向上することが挙げられます。

AIレビューでのバグ検出

「AI レビュー」の利点は、ユーザーがレビューを依頼しているため、誤検知に対して寛容になりやすい点です。欠点は、ユーザーの行動変更を必要とすることです。

AI リンティング

バグ検出の最良の形は、バックグラウンドで常時動作し、バグを検知するリントツールです。毎分複数回実行するため、AI レビューよりも低コストかつ高速なモデルである必要があります。また、誤検知率を低く抑えるように調整されていなければなりません。

よりスマートなデバッグ

バグの検出以上に印象的なのは、難しい問題のデバッグです。

LLM ベースの静的解析を超える必要があります。たとえば、cursor/debug パッケージを構築しました。これをコードに挿入すると、実行時情報を追跡します。

バックグラウンドでは、追加の変数状態を追跡するためにも利用できます（関連する出力をCursorのコンテキストにパイプする、いわゆるプリントデバッグに近い形で）。

有望な方向性

• 巧妙なデータセットのキュレーション（おそらく合成データ）と、フロンティアのコードモデルに対するRLを用いたキャリブレーションの改善。
• 他のサーフェス（ブラウザや未連携のターミナル）から関連情報を追跡します。
• デバッガー特有のツール使用やチェーンにおけるフロンティアモデルの性能を向上させる。
• 無制限のコンテキストと、コードベースをほぼ完全に理解。
• 有用なプログラム状態情報をすべて追跡できるよう、cursor/debug ライブラリの対象範囲を拡張します。

これらの課題のいずれかに関心がありましたら、hiring@anysphere.inc