カーソルが考えるAIプログラミング分野における重要な問題について

以前、元総は Yusen 社長が AI Code 共有の中で Cursor チームの書いた2つの記事を私に送ってくれました。ずっと読む時間がなく、今日ようやく少し時間を取り読みました：

OCTOBER 12, 2023
[Our Problems] - (https://www.cursor.com/blog/problems-2023)
MAY 25, 2024
[More Problems] - (https://www.cursor.com/blog/problems-2024)

Our Problems
01
2023年の具体的な問題リスト

：コードエディタ内では、多くの情報源があります。開いているファイル、意味的に類似したコードブロック、シンボルに関連するクラス、lint の出力、実行トレース、git 履歴、入力履歴、外部ドキュメントなどです。我々はモデルにユーザーの質問に関連する内容を即座に理解させたいと考えています。現在、この問題を解決するためにカスタムの高速リランキングモデルを訓練中です。各リクエストごとに、すべての異なる情報源から50万トークンを集めて、リランキングモデルを使用して最も関連性の高い8k トークンに絞り込んでいます。これは単なるモデルの問題ではなく、ますますインフラストラクチャの問題になっています。
：GitHub Copilot は新しいコードを書く際の低エントロピーなキー入力を削減するのに非常に役立ちますが、既存のコードブロックに対して小さな、単純な修正を行う場合、低エントロピーなキー入力の削減にはそれほど効果的ではありません。例えばリネーム操作では、F2 キーで行う簡単なリネームよりも複雑であり、より多くのナビゲート、削除、および入力が必要です。私たちは UX（コーディングプロセスにおける妨げにならない差異表示）とモデル側（コスト、遅延、インテリジェンスの問題によりプロンプトベースのアプローチでは解決できない）の両方で革新を遂げなければなりません。
：OpenAI のコードインタープリタに似ていますが、大規模なコードベースのエンジニアリングに適用されます。あなたは少数ステップの制限付き命令を与え、それが代わりにコードを検索、記述、実行し、あなたのフィードバックを継続的に求めます。この目標を達成する最初のステップは、このエージェントを数十万トークンを含むフォルダ内で動作させる能力を持つことです。現在私たちはその方向に向けて努力しています。成功すれば、それを全体のコードベースに拡張します。
：ここには2つのモードがあります。（1）バックグラウンドで、Cursor が常にファイルをパッシブにスキャンし、潜在的なバグを探します。（2）デバッグ中にいるとき、Cursor があなたを能動的に支援してバグを見つけます。この分野では興味深いデータ収集作業がたくさんできます。
：Cursor は、ファイル全体、さらにはディレクトリ全体をあなたのために修正できるようになるべきです。これは能力とユーザーエクスペリエンス（UX）の挑戦です。速度を向上させるために、モデルは十分に賢くなければならず、修正が必要な部分を選んで変更し、ファイル全体を書き直すのではなくする必要があります。また、エクスペリエンスを改善するために、変更プロセスはユーザーにパース可能なリアルタイム形式で提示される必要があります。
：2023年10月12日現在、私たちはすでに14億のベクトルと15万のコードリポジトリをインデックス化しており、年末までにこの数値が10倍に増える見込みです。私たちはRustで非常に高速なMerkleツリーに基づくリポジトリ同期エンジンを開発しましたが、まもなくカスタムのインデックスシステムを構築する必要があるかもしれません。

2023年の未来展望

：未来 15 分間以内に行うクロスファイルのコード修正を予測し、表示します。すべての挿入/削除操作を単一のコマンドで受け入れます。
：私たちのモデルは、任意のコードベース内のすべての概念を深く理解し、その理解を重みに反映させるべきです。
：あらゆるレベルのドキュメントと、関連するコードパスを理解するのに役立つボットを通じて、コードの理解を容易にします。
：コードの「概要」表現形式を編集し、変更をソースコードに自動適用させます。
：IDEは自動的にスタックエラーを識別し、コードを自動で修正すべきです。

私たちは現在検討中のすべての問題を収集しようと試みましたが、——これが自分で毎日12時間使う製品を作る際の素晴らしい点の一つでもある——新しいアイデアが次々と浮かび上がり、優先順位を再構成しています。したがって、これを最終的なロードマップとお考えにならないでください。しかし、私たちが日々どのように考えているかについての方向性を示すものであることを願っています。

1. 次のアクション予測

Cursorには **Copilot++** という機能が搭載されており、これはCopilotのより高度なバージョンで、次の編集を予測することができます。このアイデアを極限まで進化させることは可能でしょうか？

コードを書く際に、あなたが行うのは低エントロピーの編集だけではありません。エディタ全体では、低エントロピーのキー入力、クリック、操作を行っています。これらのすべての操作を低遅延で予測するモデルを作ることはできないでしょうか？

まず、次に移動する位置を予測するために Copilot++ を拡張しました。これを次の編集予測と組み合わせることで、モデルは一連の低エントロピーな変更をスムーズに実行できます：

（明らかなる理由で）そう呼びます。

次のファイルに移動しようとしている場所を予測しています。次に実行するターミナルコマンドも同様です。以前のターミナルコマンドに基づいて、次の編集を予測します！これが

さらに、モデルは必要に応じて関連情報を即座に提供する必要があります。それが関連するコードスニペットであろうとドキュメントであろうとです。

カーソルはあなたの意図の延長上にあるべきです。変更を考えたときに、言語モデルは最小限の意図でそれを即座に実行できるはずです。

有望な方向性：

基礎研究。
約5-13Bのアクティブパラメータを持つコードモデルでの継続的な事前学習と後学習（低遅延予測用）。
推理技術。
巧妙に設計されたユーザーエクスペリエンスで、「操作」を非侵襲的に提示する（例えば、ユーザーが次のファイルに移動することをどのように提案するか？または次のビューポート外の位置をどのように提案するか？）。

2. 完璧な編集

推論時間を拡大することで、より高品質で大規模な編集を生成することは可能でしょうか？そして、その遅延はどのように補うことができるのでしょうか？

もしかすると、編集をバックグラウンドで実行する必要があるかもしれません。信頼できるジョブユニットを起動し、それをスマートなモデルに委ねる形です。

私たちは、強力なエディタ専用ツールの操作能力を持つモデルが必要であり、それがより広範なコードベースのコンテキストを理解し、長期的な推論能力を向上させるでしょう。

さらに、非同期のコード生成がプロセスの一貫性をどのように保つかについても考慮する必要があります。これは矛盾しているように聞こえるかもしれませんが、モデルの能力とユーザーエクスペリエンスに関する巧妙な研究を通じて、この目標は達成可能だと信じています。

幻覚的疑似コード

存在しない関数やコードを実装し、その後モデルがバックエンドでそれらのコードを作成します。

ユーザーは必要な変更を記述するための疑似コードを書きます。その後、Cursorがバックエンドでその疑似コードを完全な変更にコンパイルすることを信頼できます。

複数ファイル編集

Cmd-kは既に優れていますが、もしコードベース全体で一般的な編集を要求できるとしたらどうでしょうか？特に、複数のファイルに正確にまたがる変更を行うことができます。

有望的方向：

：報酬モデルとリジェクトサンプリングが迅速かつ簡単な改善をもたらすことはわかっていますが、どこまで進むことができるのでしょうか？
（例：GPT-5、Claude-4、Gemini 2.0）
：これはモデルのツール使用能力が必要であり、リモートで実行時の環境を複製できる必要があります。
モデルをトレーニング/向上させ、エージェント軌跡上のパフォーマンスを改善する
：ストリーム中の非同期編集をサポートするために使用されます。

3. 最良のコンテキスト

あるクエリを解決する際には、何百万ものドキュメントトークン、何千万ものソースコードトークン、そしてさらに何千万ものコミット履歴トークンが関与し得ます。これらすべてが問題解決に役立つ可能性があります。

もちろん、UI内のピクセル、本番環境やローカル環境でのログ、Slack内のメッセージなども含まれます……

私たちは、最良のプログラミングシステムは、これらの情報を処理し活用するために、検索、再帰、および長距離コンテキストアテンションを組み合わせることになると信じています。

、短期的には、これは複数のモデルとインフラストラクチャの集合体となる可能性があり、無限コンテキストエンジンとしてプログラミングに利用されます。長期的には、これがアーキテクチャに統合されることを期待しています。

検索の未来について創造的に考えるとき、特に興奮します。埋め込み技術を超えて、高コストなインデックス作成ステップと低コストなクエリステップ（コーパスサイズに対して亜線形）を考えたとき、達成可能な最良のパフォーマンスは何でしょうか？

可微分の検索インデックスとしてです。また、全く異なるものである可能性もあります。これはまだ十分に探索されていない研究方向です。

多次跳躍のコンテキスト

私のコードベースにおいて、二つの文字列間の違いを計算したいと考えています。埋め込み技術を使用して得られた断片は：

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

。これは、解決するために二回のジャンプを必要とするクエリです。

コードベースでは、最も難しい問題やクエリは通常、複数のジャンプを必要とします。一般的な検索手法は単一のジャンプしか対応できません。

有望的方向

コードベースに特化した／改善された埋め込みとランク付けアルゴリズム。
：与えられたクエリと現在見つけた関連コードに基づき、次にジャンプすべきコード断片を決定する。
カスタマイズされたアテンションマスクを採用することで、コードベースの処理に更适合或许できる。
コードベース検索における革新的な研究。
Transformerを検索インデックスとして使用する方法と似ています。

4. エラーデテクションとデバッグ

現在のエラーチェックシステムは、校正やコードベースの理解において依然として困難を抱えています。

モデルは十分に賢く、正しいエラーを識別できますが、依然として偽陽性を発生しやすいです。最も難しいエラーを特定するには、コードベースに対するより深い理解が必要です。問題があるように見えるコードも、広範なコンテキストを見ると無害である場合があります。

一つの可能性として、言語モデルを使用してコードレビュー体験を大幅に向上させる方法があります：

AIレビューにおけるエラーチェック

「AIレビュー」の利点は、ユーザーがレビューを依頼しているため、偽陽性に寍に寍対してより高い許容度を持つことです。一方で、欠点は、ユーザー行動の変化が要求されることです。

AI Linting

最良のエラーディテクション方法は常にオンラインのリンターです。これにより、バックグラウンドでエラーをキャッチできます。これはAIレビュー・モデルよりも安価で速くなければなりません、なぜなら私たちはそれを数分に一度実行するかもしれませんから。また、偽陽性率を減らすために調整される必要があります。

より賢いデバッグ

印象的なのは、おそらくエラーディテクションよりも、困難な問題をデバッグする能力です。

パッケージを開発しました。コード内に注入されると、実行時情報を追跡することができます。

バックエンドでは、さらにこれを使用して追加の変数状態を追跡することもできます（プリントデバッグに似ており、関連する出力を Cursor のコンテキストに渡します）。

有望な方向性は以下の通りです：

巧妙なデータセット設計（合成データを含む可能性あり）と強化学習に基づく最先端コードモデルのキャリブレーション。
他の表面（ブラウザや非統合ターミナルなど）からの情報を追跡する。
デバッガー固有のツール使用やチェーン操作における最先端モデルのパフォーマンス向上。
無限のコンテキストとほぼ完璧なコードベースの理解。
cursor/debug ライブラリを拡張し、すべての有用なプログラム状態情報を追跡します。