Cursor is a fork of VS Code with language model assistance built into the editing surface rather than bolted on as a sidebar. Because it is a fork, your existing extensions, keybindings, themes and settings import on first launch, and the thing in front of you is the editor you already know with different behaviour when you start typing.
The features that distinguish it are about scope. Tab completion predicts multi-line edits and, crucially, the next place you are going to edit, so renaming a variable propagates through a function as a series of accepted suggestions. The inline edit command rewrites a selection from a natural-language instruction. The agent mode is the significant one: given a task, it reads across the repository, proposes changes to several files at once, runs terminal commands, reads the errors and iterates. The diff is presented for review before anything is written, which is the safeguard that makes it usable on real code.
Context handling is what separates it from a general chat window. Cursor indexes the repository so answers reference your actual functions and types rather than plausible-sounding inventions, and you can point it explicitly at files, folders, documentation or a web page. Rules files checked into the repository let a team encode conventions, so suggestions follow the project's patterns instead of generic ones.
The honest limitations. It is a fork, so it trails upstream VS Code releases by a little and a small number of Microsoft-licensed extensions do not work. Quality degrades on very large codebases where the relevant context does not fit in a window, and the failure mode is confident, plausible and wrong, which is more expensive to catch than an obvious error. Pricing is a subscription with request limits, and heavy agent use reaches those limits faster than people expect. Sending proprietary code to a model provider is a policy decision some organisations cannot make, though a privacy mode exists that avoids retention.
The productivity claims around this category are hard to verify and worth treating carefully. What is reasonably well established is that the gains are largest on unfamiliar code, boilerplate, test writing and languages you know less well, and smallest on the parts of a system you know intimately, where you are faster than the review cycle.
Who it suits: developers who already live in VS Code and want assistance that understands the whole project. Who should be careful: teams under strict code-confidentiality rules, and anyone inclined to accept large diffs without reading them.