Cursor is a code editor — a desktop app you download and open like any other program — except that instead of just showing you files and letting you type, it has an AI built into it that you can talk to. You open a folder of code, ask the AI a question or give it a task, and it works alongside you: reading the files, suggesting changes, writing new code, and showing you exactly what it wants to modify before it touches anything. That is the whole idea. Not a chatbot you copy and paste between. Not a plugin you bolt onto an existing editor. A purpose-built environment where the AI and the code live in the same place.
If you have been thinking about vibe coding — building something with AI doing most of the actual coding — Cursor is the most practical place to start. It removes the copy-paste loop and puts the AI directly inside the thing you are building.
What vibe coding actually means here
Vibe coding is the practice of building software by describing what you want in plain language and letting an AI write the code. You are not removed from the process — you still make decisions, catch problems, and steer the direction. But you are not writing every line yourself either. Cursor is built for exactly this workflow. The AI does not just autocomplete a line at a time; it can read your entire project, understand how the pieces connect, and make multi-file changes while you watch.
That said, Cursor works best when you treat it like a capable collaborator rather than a magic button. The first session you spend with it should not be a race to ship features. It should be a chance to understand how it thinks about your code — before you ask it to change anything significant.
Installing Cursor and opening your project
Download Cursor from cursor.com. It is available for Mac, Windows, and Linux. Install it the normal way for your operating system, open it, and choose a folder — either an existing project you want to work on or a fresh empty folder if you are starting from scratch.
Once you have a folder open, press Cmd I on Mac or Ctrl I on Windows. A panel opens. That panel is the agent — the AI you will be talking to. Everything from here on happens through it.
You might be wondering: do you need to know how to code to do any of this? Not to get started. But having a real project open — even someone else’s open-source code, even a small one — makes the first session far more useful than staring at an empty folder. Cursor is at its best when it has something to read.
Ask it to explain the codebase first
Before you ask Cursor to change anything, ask it to explain what is already there. A good first message is something like: “Explain this codebase. Point me to the main entry points, key modules, and anything I should read before making changes.”
What comes back is usually a plain-English walkthrough of how the project is structured — which file runs first, which files handle which responsibilities, where the important logic lives. If the project is small, this takes about thirty seconds. If it is larger, it might take a minute or two as the AI reads through the files.
This step matters more than it sounds. When you skip straight to asking for changes, Cursor can still do the work — but you have no idea whether its understanding of your project matches reality. Asking for the explanation first is how you find out. If something in the response seems wrong or confused, that is useful information before anything gets modified.
It is also just genuinely useful if the codebase belongs to someone else. You get a structured orientation in less time than it would take to read through the files yourself.
Ask for safe first suggestions, not big changes
Once you have a feel for what the project contains, ask for something low-stakes. A message like: “Suggest three small, safe improvements in this codebase. Explain the tradeoffs and wait for me to choose one.”
That last part — wait for me to choose — is worth including. By default, Cursor will sometimes go ahead and apply changes after suggesting them. Asking it to pause keeps you in control of what actually gets modified.
When you do approve a change, Cursor shows you a diff before applying it. A diff is a side-by-side or line-by-line view of exactly what will be added, removed, or modified — the old version on one side, the new version on the other, with additions usually shown in green and removals in red. You can read it, reject it, or ask Cursor to adjust the approach. Nothing is committed until you accept it.
Good first tasks to try: fixing a typo in UI copy, renaming something that has an unclear name, removing an unused variable. Not because those are the most exciting changes, but because they give you a clean picture of how the diff view works without any risk of breaking something that matters.
Plan Mode — for when the change is bigger
Once you are comfortable with how small changes feel, you will eventually want to try something more ambitious. That is where Plan Mode comes in.
Toggle Plan Mode by pressing Shift + Tab inside the agent panel. In Plan Mode, Cursor changes how it approaches a task. Instead of immediately writing code, it reads the relevant files, asks you clarifying questions if something is ambiguous, and then produces an implementation plan — a written description of what it intends to do and why. It stops there and waits for you to approve the plan before writing a single line.
This is more like a senior developer saying “here’s what I’m thinking, does this make sense?” before they start. You can push back on the plan, ask it to reconsider a decision, or tell it to go ahead. Only after you approve does it begin writing code.
Plan Mode is worth using any time you are about to ask for something that touches more than one or two files, or anything you are not completely sure how to reverse. The extra step of seeing the plan first gives you a chance to catch a misunderstanding before it is baked into ten changed files.
Closing the loop with tests, linting, and builds
One thing a lot of people do not think to do in their first Cursor session: ask it to run the project’s checks. If the project has tests, a type checker, a linter, or a local build process, Cursor can run them and read the output. You can simply ask: “Run the tests and tell me if anything is failing.” Or: “Run the linter and fix the warnings.”
A linter is a tool that scans code for common mistakes and style issues without running it. A type checker does something similar, but specifically looks for places where the code uses data in ways that do not match its expected type — things that can cause crashes at runtime. Neither of these requires you to understand every rule they enforce. Cursor reads the output and explains what it means.
Cursor will attempt to run the appropriate command for your project type, read what comes back, and either report the results or propose fixes. This closes the loop in a way that pure chat-based AI cannot. The AI and the running code are in the same room, more or less.
Running these checks before you make any significant changes is also just good practice. If there are pre-existing failures, you want to know about them before they get mixed up with anything new.
What a good first session actually looks like
Install it. Open a folder. Ask it a question.
That is really the shape of it. The first session should feel like getting to know a collaborator rather than operating a tool. You are building a sense of how it reads your project, how much it understands, where it tends to get things right and where it occasionally needs correcting.
Resist the urge to immediately ask for the biggest thing you can think of. The people who get the most out of Cursor are the ones who use those first conversations to orient — to understand the project together with the AI before asking it to change anything that matters. Once that foundation is there, you can move fast. Without it, you are just guessing at whether the changes being made actually make sense.
Start with the explanation. Build up to the first small change. Try Plan Mode when the scope grows. Run the checks. That is a first session that leaves you genuinely further ahead than when you opened the folder.