Reframe: From Tab-Complete to Agent
Cursor is not a chatbot with a text editor stapled to the side of it. It is a fork of VS Code with an agent built into the editing loop itself, and that distinction matters more than it sounds like it should, because it changes what "accepting a suggestion" actually means from one part of the product to another.
You already have instincts for this. You have been accepting and rejecting Tab-complete for months, maybe years, and those instincts are fast, cheap, and almost entirely correct. The problem this lesson exists to fix is that those same instincts, unchanged, will walk you straight into approving changes you never actually read.
What Cursor actually is
Cursor ships three distinct interaction modes, and they are not three UI skins on the same underlying action. They differ in scope: how much of your codebase a single accepted action can touch.
Tab is inline, single-cursor completion, accepted with the Tab key, same shortcut on every platform. It predicts the next few tokens, or the next edit, at the location your cursor already sits. Cmd-K is Cursor's inline edit (lesson 2 covers the platform-specific shortcut): you select a range, describe a change in a prompt box, and it rewrites that range. Agent (the current name; older material may still call it Composer) is the one that breaks the pattern: you describe a task in natural language, and it can read across your repo, plan a sequence of edits, and write to as many files as the task requires, in one turn, before you see a single diff.
Three modes, one editor, and one thing they share: each one ends with something you either accept or reject. That shared ending is exactly what makes the difference in scope so easy to miss.
The instinct that stops working
Tab-complete-brain is a real, well-earned habit. Reject a bad suggestion, accept a good one, keep typing. The blast radius of getting it wrong is a few tokens on one line, in a file you already have open, that you are already reading. Worst case, you delete a line and move on. There is close to nothing to review, because there is close to nothing there.
Composer and Agent mode present the same binary choice: accept or reject. But "accept" on a multi-file agent turn is not a longer version of accepting a completion. It is closer to merging a colleague's pull request, one that might touch a config file, a test, and two modules you have not opened yet, sight unseen.
Nobody decides, out loud, to stop reviewing agent output. It happens by default, because the accept button looks and feels exactly like the one you have clicked ten thousand times for a single-line suggestion. The interface didn't change enough to trip your guard.
Nobody would merge a five-file pull request from a new contributor without reading the diff, checking that the tests still make sense, and confirming nothing outside the stated scope moved. Yet that is precisely what a reflexive "accept" on an Agent turn does, because the two actions share a keystroke and a green button, not because they share a risk profile.
Lesson 8 walks the case that makes this concrete instead of abstract: a diff that reviews clean on sight, with a bug seeded inside it that a glance would miss and only a running test catches. That's not a hypothetical risk this lesson is asserting. It's a worked failure, start to finish, later in this course.
Why the review discipline has to change
The fix is not to distrust the agent, and it is not to slow every Tab completion down to PR-review pace, that would just make the tool worse than typing. The fix is to match your review effort to the actual blast radius of what you are about to accept, not to the effort the interface makes that acceptance feel like it costs.
A completion that changes one line gets the one-line review it deserves: does it look right, does it compile, move on. A Composer turn that touches five files earns the review a five-file pull request would get from you if a teammate opened it: read the diff, check what changed outside what you asked for, confirm the tests it modified (if any) still test the right thing. Cursor gives you the tools for that review for free, checkpoints per turn, a diff view per file, and later lessons in this course build the habit of actually using them. This lesson is only asking you to notice that the habit has to exist at all.
What's ahead
The rest of this module gets you running Cursor in five minutes, then lays out all three modes side by side so you know which one fits a given task before you reach for it. The review habit this lesson names gets its own full lesson and worked demo later in the course, once you have seen enough of the product to practice it on something real.
Installing Cursor and getting from a blank editor to your first accepted change, in about five minutes.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
