Cursor Basics

Cursor is a code editor built with AI assistance as a core part of the editing experience, rather than as an add-on extension to an existing editor.

Editor-first design. Unlike tools that add AI features to an existing editor, Cursor is built from the ground up around AI-assisted coding, which allows deeper integration between the AI features and the editing experience itself.

Core features. Cursor offers AI-powered code completion, chat-based interaction with the codebase, and the ability to make multi-file edits directly from natural-language instructions, letting developers describe a change and have it applied across the relevant files.

Codebase awareness. Cursor is designed to understand the broader context of a project, not just the currently open file, which helps its suggestions and edits fit naturally with existing code.

Access and plans. Cursor is available as a downloadable editor with different subscription tiers offering different levels of AI usage and model access.

Coming from an existing editor. Because Cursor is a full editor rather than a plugin, adopting it means changing where you work, not just what is installed. It is built to make that transition inexpensive: the general editing experience, keybindings, and extension ecosystem are deliberately familiar to developers arriving from mainstream editors, and settings can typically be carried across rather than rebuilt. The practical consequence is that the AI features are what you are actually evaluating, since the surrounding editor should feel largely unchanged.

The interaction modes, at a glance. Cursor's assistance is generally reached in a few distinct ways: inline completion while typing, a targeted edit applied to a selection you describe in natural language, and a broader chat or multi-file editing surface for changes that span the project. Knowing which mode a task calls for is most of the skill — reaching for a project-wide change when you wanted to rename one variable is slower, not faster, than doing it yourself.

How codebase awareness actually works. For an assistant to answer questions about a project, it needs some representation of that project beyond the open file, which is typically built by indexing the codebase so relevant sections can be retrieved when a question is asked. This is why the editor can respond usefully to questions about code you have never opened. It also means the quality of an answer depends on whether the right files were retrieved, which is why explicitly pointing the assistant at particular files or folders tends to beat relying on retrieval alone.

Encoding project conventions. Cursor supports project-level configuration in which you record standing instructions — the conventions, patterns, and constraints that apply to this codebase — so they inform generated code without being restated in every request. This is worth setting up early on any project with real conventions, because it converts repeated corrections into a rule that applies automatically. It is also the natural place to record what the assistant should not do, such as libraries the project has deliberately avoided.

Reviewing what the AI changed. Any tool that can edit several files from one instruction needs a review step, and Cursor surfaces proposed changes as diffs to be accepted or rejected rather than applying them silently. Reading those diffs is not optional overhead — it is the control that keeps a fast tool from quietly introducing changes you did not intend. Working on a clean version-control state, so that everything the assistant touched is visible in your own diff afterwards, is a common and sensible precaution.

Usage, models, and cost awareness. Because AI features are central rather than incidental, usage is metered in ways that vary by plan and by which underlying model a request uses. More capable models cost more per request and generally respond more slowly, which makes model choice a real decision rather than a preference. Matching the model to the task — something fast for routine edits, something stronger for genuinely hard reasoning — is how experienced users keep both cost and latency reasonable.

Privacy and what leaves the machine. An assistant that answers questions about your codebase necessarily sends portions of that codebase to a model running elsewhere, and any project-wide index implies that a broader slice of the code is reachable than whatever file happens to be open. Cursor exposes settings covering this, including modes intended for stricter handling of code and controls over which files are excluded from indexing entirely. Anyone working on proprietary, client-owned, or regulated code should read those settings before the first project is opened rather than after, and confirm what their organization's policy actually permits — this is configuration to verify, not to assume.

When editor-first matters, and when it doesn't. The argument for a purpose-built editor is that features spanning many files, and workflows where the AI proposes and the human reviews, are easier to build well when the editor itself was designed around them. The counter-argument is that extension-based assistants let you keep your existing environment unchanged. Which matters more depends on how much of your work involves multi-file, instruction-driven changes rather than in-the-flow completion.

Understanding Cursor's editor-first approach — rather than an add-on to an existing tool — is key to understanding how it differs from other AI coding assistants.