Cursor for Beginners: A First-Week Guide

Cursor is a code editor built on VS Code with an AI model wired into the places you already work: the autocomplete, an inline edit box, a chat panel, and an agent that can change several files at once. It is easy to start and easy to misuse. This guide covers the first week: what each feature does, how to stay in charge of the changes, and how to use it without letting your own skills stall.

Day 1: set up#

On first launch Cursor offers to import your VS Code settings, extensions and keybindings. Accept; everything you know about VS Code still applies. Most extensions work, because Cursor uses the Open VSX registry. A few Microsoft-published ones do not, so if you rely on Pylance or the C# Dev Kit, expect to substitute.

Open a real project rather than an empty folder. The assistant is dramatically better with code to read, and you learn more by seeing what it does to something you understand.

The four surfaces#

Tab: autocomplete#

As you type, Cursor suggests the next few lines in grey; Tab accepts. Unlike older autocomplete, it predicts across the whole file — rename a variable and it offers the next occurrence to change. It is the feature you notice least and use most.

The trap for beginners is accepting suggestions you have not read. Read every one. If you would not have written it, do not accept it until you understand why it is right.

Inline edit#

Select some code and press Ctrl+K (Cmd+K on a Mac). A small box appears; type what you want changed — “make this handle an empty list”, “add type hints” — and the change appears as a diff you accept or reject. This is the most controlled way to use the assistant: one place, one change, reviewed.

Chat#

Ctrl+L opens a panel for conversation: explain this function, why does this test fail, what is the difference between these two approaches. Chat can propose code changes, shown as diffs you apply one at a time. Use it for understanding before you use it for writing.

Agent#

Agent mode takes a task — “add a settings page that saves to localStorage” — reads the codebase, and edits several files, running commands where needed. It is powerful and it is where beginners get into trouble, because it produces more code than they can review. Leave it for the second week, and start it on small, well-bounded tasks.

Giving it context#

The quality of what you get back depends on what the model can see. Three ways to point it at the right things:

• @ mentions in chat: @file, @folder, @codebase for a search, @docs for library documentation Cursor has indexed, @web for a search.
• Rules: a rules file in the project that is included in every request. Put your conventions there — language version, style, “always write tests”, “never use any in TypeScript”.
• Selected code: whatever you have highlighted is included automatically.

# .cursor/rules/project.md
This is a Python 3.13 project using FastAPI and SQLAlchemy 2.
Use type hints everywhere. Prefer small functions.
Run tests with: pytest -q
Do not add dependencies without asking.

A rules file is the single highest-value thing to set up on day one. Without it, the assistant guesses your conventions every time.

Reviewing changes#

Every change Cursor makes appears as a diff with accept and reject controls, per file and per hunk. Use them. The workflow that keeps you in control:

1. Ask for one thing at a time.
2. Read the diff. If any part is unclear, ask in chat what it does before accepting.
3. Run the tests, or the program, after accepting.
4. Commit. A small commit per accepted change means any mistake is one revert away.

Cursor keeps a checkpoint before each agent run so you can restore the previous state, but git is the real safety net. Commit before starting anything ambitious.

Staying a programmer#

The risk with a good assistant is that you stop understanding your own project. Habits that prevent it:

• Write the first version yourself for anything you are learning. Use the assistant to review or improve it.
• Ask why, not just for code. “Why did you use a context manager here?” teaches you something. “Fix it” does not.
• Turn Tab off for an hour a day when practising a language you are new to. The setting is in the status bar.
• Read the diff out loud, or at least line by line. If you cannot explain a line, you do not own it yet.
• Keep the agent for chores: boilerplate, renames, test scaffolding, migrations. Keep the design decisions for yourself.

Things that go wrong in week one#

• The assistant invents a library function. It happens. When something looks too convenient, check the documentation. @docs in chat reduces this.
• It changes more than you asked. Reject the extra hunks and say so; “only change the function I selected” in the prompt helps.
• It cannot see a file. Large folders and anything in .gitignore or .cursorignore are excluded from indexing. Mention the file explicitly.
• Agent runs a command you did not expect. Cursor asks before running most commands; read the prompt rather than approving by reflex. Set an allowlist in settings if you want stricter control.

Where to go next#

• Cursor vs Claude Code — the comparison once you know one.
• How to check AI-generated code — the review skill in depth.
• Vibe coding for beginners — building a whole app this way, and its limits.