What Cursor actually is
Cursor is a code editor built around AI that understands your entire codebase rather than just the line you are typing. Forked from VS Code, it keeps the familiar editing experience but adds context-aware generation, multi-file edits, and an agent that can carry out larger tasks from a plain-language description. The mental shift is the important part: instead of accepting line suggestions, you direct changes the way you would brief a fast junior developer — describing intent, pointing at the relevant files, and reviewing the result. Used well it removes enormous amounts of mechanical work; used carelessly it ships confident, wrong code.
The core features
@-mentions for context. The single most important skill is feeding Cursor the right context. Typing @ lets you reference specific files, symbols, folders, or documentation, so the model edits with knowledge of your actual code rather than guessing. A request grounded in the relevant files produces changes that fit your patterns; an ungrounded request produces generic code that you then have to rework.
Inline edit. Select code, invoke the inline edit, and describe the change in words — rename, refactor, fix, optimise. This is the right tool for a focused change in one place that you can point at directly. It shows a diff you accept or reject, keeping you in control.
Composer and agent mode. For tasks that span several files — adding a feature, wiring a new endpoint, refactoring across modules — Composer and agent mode plan and apply multi-file changes from a single description. Agent mode can run commands and iterate toward a goal. These are powerful and the place where review discipline matters most, because the blast radius is larger.
Rules. A project rules file tells Cursor your conventions — frameworks, style, patterns to use and avoid. This is the highest-leverage setup step, because it aligns every generation with how your team actually writes and cuts the after-the-fact editing dramatically.
Using it well — and when not to trust it
The teams that get the most from Cursor treat it as an amplifier of judgement, not a replacement for it. Always supply context with @-mentions, match the tool to the scope of the change, and write a rules file early. Then review every diff before accepting — read it, run the tests, and reject anything you do not fully understand. Cursor will occasionally invent an API, misread your intent, or quietly miss an edge case, and confident-looking wrong code is more dangerous than an obvious error. Enable privacy mode for sensitive repositories and check your organisation’s policy first. Direct it clearly, verify relentlessly, and it becomes the fastest pair-programmer you have worked with.