Cursor
An AI-native code editor that edits whole files, not just the line under your cursor.
You've been stuck on a refactor for two hours. You know roughly what you want — “pull this logic out of the handler into a separate module, update the three callers, keep the tests passing” — but the path between knowing and doing involves opening eight files and holding everything in your head at once. You are about to type the entire instruction into a chat window and hope for the best.
Why this tool matters
Cursor is a fork of VS Code rebuilt around the assumption that you will be collaborating with an AI on almost every change. Unlike GitHub Copilot (Day 8), which completes the line or block under your cursor, Cursor operates at the project level: you can describe a multi-file change in plain English and watch the editor propose diffs across your entire repository.
The central experience is the Composer (Cmd+I). You open it, describe
what you want — “extract the auth logic from routes/login.js into
a new lib/auth.js module; update the two callers; don't touch the
tests” — and Cursor proposes a multi-file diff. You review each file's
changes, accept or reject, and the work is done. For tasks that would have required
thirty minutes of window-switching, you get a reviewable pull-request-sized change in
about ninety seconds.
What makes Cursor genuinely different from “AI autocomplete” is the depth of project context. It indexes your whole repository, understands imports and dependencies, and references your actual code in the suggestions it makes. When it writes a function call, it uses the argument names your other files use. When it changes a type, it updates the dependents. This is the step-change from AI-as-autocompleter to AI-as-collaborator, and it is the reason professional developers have moved to it in droves over the past eighteen months.
Setup
Install: download from cursor.com for Mac, Windows, or Linux. Log in with GitHub or Google. The free tier gives you enough requests to try the tool seriously; the $20/month Pro tier removes the cap and unlocks faster models.
Bring a project: open a real repository — even a small one (a personal site, a class project, a half-finished script). Cursor's value is proportional to the size of your codebase; a blank folder does not showcase what it can do.
Prereq: basic comfort in the terminal and git. Cursor assumes you know how to read a diff.
Walkthrough
Step 1: Open your project and index the codebase
In Cursor, use File → Open Folder and pick a real project. Give it 30 seconds to index. In the bottom status bar you'll see Indexing … finish. This is the moment Cursor reads every file and builds a semantic map — the thing that makes everything that follows work.
Step 2: Inline edits (Cmd+K)
Open a file. Put your cursor on a line or select a block. Press Cmd+K. Type an instruction in plain English: “Add input validation; reject emails without an @ sign.” Cursor inserts a diff inline; press Tab to accept or Esc to reject. This is the 10-second version of AI editing and you'll use it fifty times a day.
Step 3: Chat (Cmd+L) — the conversation pane
Press Cmd+L to open the chat pane on the right. Drag any file into the chat to add it as context, or type @ to search your codebase by name. Ask a question: “Where does this app handle user registration?” Cursor answers by citing specific files and functions.
Step 4: Composer (Cmd+I) — multi-file changes
This is the flagship feature. Press Cmd+I. Describe a change that spans multiple files: “Add a dark-mode toggle. Add the CSS variables, the toggle component, and wire the state to localStorage so it persists.” Cursor proposes a multi-file diff. Review each file, accept/reject per-file or per-hunk, then apply.
Step 5: Use Cursor Rules to lock in your conventions
Create a .cursor/rules file in your repo. This is a plain-text briefing for the AI: your coding style, the libraries you want it to prefer, the patterns it should never produce. Every request to Cursor reads these rules. The difference between Cursor with and without a rules file is dramatic; a good rules file is the single highest-leverage 20 minutes you'll spend.
Step 6: Always read the diff before accepting
This is the one habit that separates people who ship bugs with AI from people who ship clean code. Cursor will occasionally propose changes that look right but do the wrong thing. Treat every diff like you would a pull request from a competent but unknown junior engineer — trust, but verify.
Your turn
Basic: Make one real change on a real project
Open a project you have — yours or a cloned open-source one. Think of a small change you've been putting off: add a console log, fix a typo in a label, add one more validation check. Do it using only Cmd+K (inline edit). Read the diff before accepting.
Goal: feel how different it is from typing the code yourself.
Advanced: A Composer-driven feature
Pick a small feature you actually want on a real project — a dark-mode toggle, a “copy to clipboard” button, an export-as-CSV, a sort-by-date option. Write a .cursor/rules file first (about 10 lines) declaring your coding style and preferred libraries.
Then use Cmd+I (Composer) to describe the feature in 2-3 sentences. Review every file in the proposed diff before accepting. Run the tests (or the app manually). Fix anything that's wrong via iterative prompts: “the toggle flickers on load because the initial state is wrong — fix it by reading localStorage before first paint.”
Ship the change (commit, push). Write yourself a 50-word note: what was faster than doing it by hand? What did Cursor get wrong the first time?
Pitfalls and pro tips
It will confidently delete things you wanted. Always read the full diff, not just the first file. Cursor sometimes removes code it considers redundant but that was actually load-bearing somewhere else. Version control (git) is not optional — commit before any Composer run so you can revert in one command.
Context limits matter. If you send Cursor ten huge files in one Composer request, it will forget half of them. For large projects, use @ to reference only the files that matter, or break the change into two smaller passes.
A weak rules file leads to drift. Without a .cursor/rules file, Cursor gradually introduces new libraries, new style conventions, and its own preferred patterns into your codebase. After a month this adds up to real inconsistency. A rules file is the fence that keeps the AI inside your style.
How it compares
Cursor's direct competitor is Windsurf (Day 7). The two are extraordinarily similar in capability — both are VS Code forks with inline edits, multi-file composer, and project indexing. Cursor tends to be slightly ahead on raw edit quality; Windsurf tends to be slightly ahead on its agentic “Cascade” mode, where the AI takes multi-step actions (running commands, reading output, iterating). GitHub Copilot (Day 8) is line-by-line autocomplete inside VS Code — a different and complementary paradigm. Most professional developers I know use Cursor or Windsurf as their primary editor, and keep Copilot installed as a background autocomplete.
When to use — and when not to
Use Cursor when you have a real codebase to work in and need changes that span multiple files or require real project context. It is particularly good for refactors, bug fixes in unfamiliar codebases, and “I know what I want, I don't want to type it all” tasks.
Do not use Cursor when you are writing from a completely blank slate with no existing code (v0 and Bolt.new — Days 9 and 10 — are better for that), or when you are exploring a design idea and need to throw away and restart often (a scratch file in a regular editor is lighter).