Cursorのある利用者は、アシスタントが約750～800行のコードからなるプロジェクトへの対応を拒み、その後、利用者が突き放すようなものと受け取った返答をしたと述べている。Cursorのフォーラムに投稿されたこの苦情は、AIコーディングツールの魅力がモデルの品質だけでなく、実際のコードベースが玩具のような例では済まなくなった後も、どこまで有用であり続けられるかに左右されることを改めて示している。

投稿によると、利用者はCursorをインストールしたばかりで、Proの試用期間中だった。約1時間コーディングした後、アシスタントは750～800行すべてを確認できなかったという。理由を尋ねると、アシスタントは「LLMが自分たちの用途を理解しているのかは分からない」と返答したとされる。利用者はまた、このセッションがmacOS Sequoia 15.3.1上で行われたとも述べた。

この報告は製品全体に共通する制限を証明するものではなく、問題がコンテキストウィンドウ、ツール上の制約、あるいはそのセッション固有の何かに起因したのかも示していない。それでもこの苦情が有用なのは、コーディングアシスタントが「印象的」な存在から「いら立たしい」存在へと変わる瞬間を捉えているからだ。利用者は通常、根本的なボトルネックがアーキテクチャ上のものか、プロンプトに関係するものか、安全性のために設けられたものかを気にしない。気にするのは、そのツールが進行中のプロジェクトについていけるかどうかだ。

この違いはAIコーディング市場で重要だ。同市場では、製品はより大規模なリポジトリを扱い、周辺ファイルを探索し、タスクが拡大しても継続性を保つ能力によって評価されることが多い。短いコード断片ではうまく機能するモデルでも、利用者がより広範なコードベースについて支援を求めると、はるかに能力が低いように感じられることがある。問題は単なる理解力ではない。運用上役立つのに十分なコンテキストをアシスタントが維持できるかどうかだ。

返答の口調も苦情の一部となった。利用者にとって、回答の失敗は一つの問題だが、軽薄に聞こえる失敗回答はまた別の問題である。投稿は、アシスタントの言葉遣いが制限そのものとほぼ同じくらい重要だったことを示唆している。これは会話型インターフェースを中心に構築された製品にはおなじみのリスクだ。失敗すると、それは人前で起こり、実際には個人的なものではなくても、個人に向けられたように聞こえることがある。

したがって、このフォーラム投稿は技術的なベンチマークではなく、顧客体験についての報告として読むのが最適だ。試用開始後のごく早い段階で、ある利用者が限界にぶつかり、その限界を実用上の重大な制約と解釈したことを示している。Cursorがより大規模なプロジェクトを確実に処理できるかどうかは別の問題だ。この投稿が明らかにしているのは、少なくともある新規利用者にとって、最初の1時間の体験が、アシスタントがパートナーというより門番のように聞こえる形で終わったということだ。