Cursor Basics: Start Using Cursor on Real Code

Cursor is a fork of VS Code with coding help built into the editor. Your extensions, keybindings and themes carry over. Cursor adds autocomplete, codebase chat and an agent that can edit across files and run your terminal.

Do VS Code extensions work in Cursor?

Extensions are the wrinkle in that inheritance. Cursor installs them from the Open VSX registry rather than the VS Code Marketplace, so check the two or three you cannot work without before you move over.

How different is Cursor from a normal editor?

The shift from a normal editor is, to me, smaller than the demos suggest. You still open a folder, you still read code, you still commit, and you still decide what ships. What moves is where your attention goes. Less of it on typing each character, more on describing the change and then reading what came back.

Which is the half that gets skipped. Describing the work is easy and mildly fun; reading a diff you did not write is neither.

I suspect most people who bounce off Cursor in the first week never hit a model limitation at all. They hit the review step, decide that reading the change is slower than writing it themselves, and go back to typing. On a small edit in a file you know by heart, that is a fair call. It stops being fair once the change spans files you would have had to open and read anyway, and it is that second case where the time actually comes back.

Cursor gives you four ways to work, and most days you move between them. Tab finishes the line you're typing, Ask answers questions about your code, Agent takes on a task across files, and inline edit changes a selection in place. Each one suits a different size of job.

What modes does the Cursor agent have?

The agent side has grown through Cursor 3Cursor's agent-forward interface (also called the agent window or Glass), built to run and supervise many agents at once rather than edit one file. Press Enter for the full definition..x. The panel opens with ⌘/Ctrl+I, and a mode picker (⌘., or ⇧+⇥ to rotate) switches between Ask, Agent, Plan (which researches and writes an editable plan before any code changes) and Debug, which instruments your code and uses runtime evidence to find the root cause. Agents can also run in the cloud and be managed from your phone.

How do you choose which surface to use?

Choose on blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. rather than on which surface is newest. Tab touches the line you are on; Agent can touch files you have never opened. Pick the smallest one that still does the job and the review afterwards stays small too.

Except that is not what happens. Agent is the most capable surface, so it becomes the default, and then a two-line fix arrives as a nine-file diff with a refactor nobody asked for. The work got done. The reading did not, and after the third time that happens people stop reading carefully at all. Which is the actual failure.

Getting this choice right is probably the first real beginner win. The guide below goes further, into Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. and into the ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. naming that trips everyone up.

Learn the surfaces in the order that builds review practice fastest: Tab first, then inline edit, then Ask, then Agent, with Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. once a task is big enough to be worth planning. Each step hands you a slightly bigger change to check.

Tab suggestions are a line or a few lines, so you judge them in a second, and you start learning what this model gets right about your code. Inline edit is the first time you find out whether the instruction you typed said what you meant, on a selection you are already looking at.

Ask is free to be wrong. It never edits anything.

Start at Agent and the first diff you ever read is a multi-file one. No baseline for what good looks like from this thing, and a lot of change to check at once. So people accept it. Something breaks two days later in a file they did not know had been touched, and the conclusion they draw is that the agent is unreliable. It might be. Nobody checked the diff, so there is no way to know.

None of that is a law. On a throwaway repo, go straight to Agent. There is nothing to break, and it is the fastest way to see what the product actually does. The order earns its keep on code you care about, where it keeps what you have to review smaller than what you will realistically read.

Context is the set of files, docs and conventions Cursor can see when it answers. Point it at the exact thing instead of hoping it finds it. The three below work at different scales, and the third is not a feature at all.

• @-mentions pull specific @Files, @Folders, @Docs or @Web results into the prompt.
• Rules make .cursor/rules/*.mdc files carry your conventions across chats.
• Tight scope means fewer open tabs and a focused selection beat dumping the whole repo.

An @ mention is a claim that a file is relevant. Cursor's own guidance is narrower than people expect for that reason. Mention files when you already know they matter. Skip the mention when you do not, because Agent searches the codebase on its own anyway. Guessing at attachments in a repo you have not learned yet mostly adds noise, and noise looks exactly like context from the outside, so you cannot tell it is hurting.

The index is what does that searching. Cursor embeds your repo when you open the folder, semantic search switches on at 80% indexed, and after that it re-syncs every five minutes over changed files only.

A weak answer in the first minute after a fresh clone may just be a half-built index, so ask again before you conclude anything about the model. And anything matched by .gitignore or .cursorignore never gets indexed at all, which is the dull explanation for most 'why can't it see my file' reports.

Rules sit at the other end of the scale. They are .mdc files under .cursor/rules/, they load automatically, and every rule that applies spends context on that request. That last part is what people miss when they paste a whole style guide in there. Short and scoped beats thorough, I'd say, at least until you have watched the agent quietly ignore a long one.

A rule that says use our logger rather than console.log changes behaviour. A rule describing your philosophy of clean code mostly spends tokens.

Read the diff, and keep the task small enough that reading it is realistic. Agent applies its edits as it works rather than asking permission first, so what you are looking at is a change that already exists in your files. The diff view is where you decide whether it stays.

Rejecting is a normal outcome, not a failed prompt.

It took me a while to stop treating a rejected run as wasted work. What changed my mind is that even a bad run tells you which files the change touches, and the second attempt, with that written into the prompt, is usually much better than the first.

Scan the file list before you read a single hunk. A file you did not expect to see in there tells you more than any individual line will, and the list takes five seconds. Then the deletions. Those are the quiet ones. A removed guard clause reads like less code, and less code looks like progress.

Review time does not disappear because the writing got faster. Assume the model can be confidently wrong, and keep the diff at a size where being wrong stays cheap to catch.

Four mistakes account for most of the early frustration: treating mode and model as one dial, handing over the whole repo instead of the right file, judging a change by whether it runs rather than whether it is correct, and reaching for a bigger model before fixing the prompt.

Mode and model are separate choices. Mode decides which tools the agent may use, so Ask reads without writing and Plan produces a plan instead of code. The model decides which system does the reasoning. ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. is the name that muddles this, because it sounds like a mode and you pick it from the model list.

The bigger-model reflex is the one I would push back on hardest. When an answer is wrong, the usual cause is that the thing it needed to see was not in front of it, and swapping models re-rolls the dice on the same bad input. Adding the file, or stating the constraint you left implicit, changes the input instead. Try that first. It costs less and it fixes more of what actually went wrong.

Then there is the prompt with no acceptance test in it. 'Make the login better' gives the agent nothing to aim at. Say what should be true when it is done, name the file if you know which one it is, and name the thing you do not want touched.

That last one is, I think, the cheapest sentence in the whole prompt.

The main change is that conventions stop living in your head and start living in the repo. Rules are files under .cursor/rules/, so they get committed and reviewed like code, and a convention written down once applies to everyone's runs instead of being retyped in everyone's prompts.

On a team of three or four I would keep that set deliberately thin to begin with. One rule for the stack, one for the paths nothing should touch, and nothing more until you have seen the same problem show up in a diff twice. Rules written in advance encode what people believe their conventions are. Rules written after a bad diff encode what they actually are.

The second change is quieter. If everyone is producing more code, the extra volume lands in review, and a team can hand back in queue time a good part of what it gained in writing speed.

Nobody wants to hear that the answer is smaller pull requests. Granted, nobody wanted to hear it before any of this either.