How would you improve Cursor Tab for engineers working in large legacy codebases?

Introduction

Cursor Tab is the feature many developers try first. It predicts not just the next token but the next edit: it can suggest multi-line changes, jump the cursor to the next place that needs editing, and update related lines after a rename. The model behind it was strengthened by Cursor's acquisition of Supermaven in November 2024. Tab feels magical in a fresh TypeScript or Python project. In a 15-year-old Java monolith with custom frameworks, generated code and internal libraries, it can feel far less helpful.

The question is how to improve Cursor Tab for engineers in large legacy codebases. These engineers mostly work at enterprises, which are a large and growing share of Cursor's revenue, so this is a commercially important user.

Step 1

Clarifying Questions (5 mins)

• Looking at the product context, how does Tab perform in legacy codebases today? I'll assume acceptance rate is about 20–30% lower than in modern codebases, with complaints about suggestions that ignore internal conventions.

• Considering user behaviour, are these engineers mostly changing existing code rather than writing new files? I'll assume yes: most work is small edits, bug fixes and migrations.

• On constraints, can Tab use more context (indexing, Rules) without breaking latency? I'll assume we must keep suggestions under roughly 300 ms at p50.

• On company alignment, is the goal enterprise retention and seat expansion? I'll assume yes.

• On measurement, can we identify a "legacy" repository? I'll define it loosely as repositories over five years old and over one million lines, or primarily in older language versions, and validate the definition with customer success teams.