Your First Five Minutes in Cursor
Open Cursor for the first time, put your cursor at the end of a real line of code, and pause. Within a second or two, grey text appears after it: a guess at what you'd type next, sitting in the editor but not yet in the file. That's the moment this lesson gets you to, in the next five minutes, on a repo you already have on disk.
You already know how to install developer tools and open a terminal, so this lesson does not slow down for that. What it does assume is zero prior time in Cursor specifically: not the install, not the layout, not what happens the first time you press a key you've hit in every other editor for years and get a very different result.
Skip the empty-project tutorial instinct. Open Cursor on a real repo you already have on disk, one with actual functions in it, because the whole point of this lesson is watching it react to code that already exists.
Installing Cursor
Cursor is a fork of VS Code, so if you've used VS Code the shell will feel immediately familiar: same layout, same command palette, same extension model. What's different lives inside the editing surface, and that's the part the rest of this lesson covers.
Download from cursor.com and drag the app into Applications, the same as any other Mac app. First launch will prompt macOS's usual "downloaded from the internet" warning; that's Gatekeeper, not a sign anything is wrong.
:::
On first launch, Cursor offers to import your VS Code settings, keybindings, and extensions. Take it if you have a VS Code setup you like. It saves you from rebuilding a familiar editor from scratch, and nothing about the import touches the parts of Cursor this course is actually about.
Open a real repo, not a scratch file
New-project tutorials are a bad way to learn Cursor, because its suggestions are only as good as the code surrounding them, and an empty folder gives it nothing to work from.
Any repo with real functions in it works: something you wrote last month, a side project, even a small script with two or three routines. Avoid your largest, messiest codebase for this first pass; something you can hold in your head is easier to judge its suggestions against.
File > Open Folder (or File > Open... on macOS), and select the repo's root. Cursor indexes the folder in the background as soon as it opens; you'll see a small progress indicator in the status bar while it does.
Pick something ordinary. A function that takes a couple of arguments and does one clear thing is a better test case than your most tangled file.
That indexing step matters more than it looks. Cursor's suggestions later in this course (@codebase, the agent's ability to find the right file on its own) all depend on that background index existing. It happens automatically, on every folder you open, with no action from you.
Tab: place your cursor and watch
Find a function in the file you opened. Go to the end of an unfinished or obvious line: the tail of a variable declaration, the last statement before a function's closing brace, anywhere the next line is fairly predictable from what's already there.
Pause. Within a second or two, grey text appears after your cursor: Cursor's guess at what comes next, rendered as ghost text, the same visual convention VS Code and most editors use for inline completions. It is not in the file yet. Nothing has changed on disk. It's a proposal sitting in the editor's rendering layer, waiting on you.
Press Tab to accept it, or keep typing to ignore it and it disappears. That's the entire interaction: propose, then you decide.
GitHub Copilot and other inline-completion tools use the same grey-text convention. If you've used any of them, Tab's basic shape will already feel familiar. Cursor's version differs in what it's trained to reach for and how far it looks across your open files for context, both of which later lessons build on, but the accept-or-ignore mechanic itself is the same one you may already know.
Try it now, on the file you have open: go to the end of a real line and see what Cursor proposes. Accept it if it's right. Delete it if it's wrong. Either outcome tells you something about how Tab reads your code, and both are normal for a first try.
Try it once more on a line where the "right" continuation genuinely isn't obvious, one with two or three reasonable ways to finish it, not the easy case where only one continuation makes sense. Cursor still proposes something with the same confidence it showed on the easy line. That's the tell worth noticing this early: ghost text doesn't come flagged with how sure Cursor actually is. A confident-looking suggestion on an ambiguous line and a confident-looking suggestion on an obvious one render identically, and only reading the proposal tells you which kind you're looking at.
Cmd-K: select something small and ask for a change
Tab predicts what comes next. Cmd-K (Ctrl+K on Windows and Linux) does something different: you select existing code and describe a change to make to it, in place.
Highlight a single function, or a few lines inside one. Small is deliberate here: Cmd-K on a tiny selection is the easiest place to see exactly what it changed and why.
A text box opens right above your selection. Type what you want in plain language: "add a null check for the second argument," "rename this variable to something clearer," "add a docstring." No special syntax.
Cursor proposes an edit shown as a diff directly in the editor: red for what it would remove, green for what it would add, laid over your actual code rather than in a separate panel. Accept, reject, or ask it to try again, all without leaving the file.
That diff view is the detail worth sitting with. Cmd-K never overwrites your selection silently. It always shows you the change as a diff first, the same shape you'd see reviewing a colleague's small pull request, and the review happens before anything lands, not after.
Tab extends. Cmd-K edits. Both stop and wait for you before anything is written. Lesson 3 adds a third mode, Agent, that works across multiple files instead of one selection, but the same waiting-for-you shape underlies all three, and this lesson is where that shape should start to feel automatic.
What you should have by the end of this
Cursor installed, a real repo open in it (not an empty scaffold), one Tab suggestion you watched appear and either accepted or dismissed, and one small Cmd-K edit you reviewed as a diff before accepting. That's the full first-timer's motion: propose, review, decide. Everything else in this course scales that same motion up to bigger changes and more files at once.
Tab, Cmd-K, and Agent as three distinct interaction modes with different scopes, and how to know which one a given task actually calls for.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
