Khurram Badar / Archive / Courses / Learning Cursor a hands-on course

Learning Cursor a hands-on course

course · 2026-08-27 · 2165 words · Khurram Badar · for professionals · intro

Learning Cursor — a hands-on course Built around your own project yusuf-study-hub, not a toy app. Nine modules.

ai · education · energy · technology

Learning Cursor — a hands-on course

**Built around your own project (`yusuf-study-hub`), not a toy app.**

Nine modules. Each one has a *goal*, a *do this*, and a *check yourself*. Don't skip the check-yourself parts — they're the difference between knowing Cursor and knowing what Cursor did.

---

A note before you start

You said you want it to do everything for you. It can, and it will — that's genuinely how Cursor is designed in 2026. But there's a trap here worth naming once and then not nagging you about:

The people who get badly stuck with these tools aren't the ones who let the AI write the code. They're the ones who can't tell when the AI has written the *wrong* code. The whole skill now is **reading, judging, and steering** — not typing.

So this course is designed so Cursor does 95% of the typing and you build the 5% that actually matters. Every module ends with "can you explain what just happened?" That's the real curriculum.

---

Module 0 — Setup (30 min)

**Goal:** Cursor installed, your project open, models configured.

**Do this:**
1. Download from cursor.com/downloads. Install like any normal app.
2. On first launch it offers to import VS Code settings, extensions, and keybindings. Accept — Cursor is built on VS Code, so everything carries over.
3. Open your project: `File → Open Folder → yusuf-study-hub`
4. Let it index. Cursor builds a searchable map of your codebase in the background. Wait for it to finish before your first real prompt — it's the difference between the AI guessing and the AI knowing.
5. Open Settings → Models. You'll see a list (Claude, GPT, Gemini, Grok, and Cursor's own Composer). Leave the defaults for now; Module 7 covers picking.

**Check yourself:** Open the Command Palette (`Cmd/Ctrl + Shift + P`) and type "cursor". Skim what's there. You don't need to understand it yet — you're just learning that this palette is where everything lives when you forget a shortcut.

---

Module 1 — The four surfaces (1 hr)

**Goal:** Know which tool to reach for. This is the single biggest thing beginners get wrong — they use the agent for everything, including things that should take two seconds.

Cursor gives you four ways to interact with AI, escalating in power and risk:

| Surface | What it does | Use when |
|---|---|---|
| **Tab** | Predictive autocomplete. Suggests the next edit, sometimes across multiple lines or a jump to another spot in the file. | You're typing and know what you want |
| **Inline edit** (`Cmd/Ctrl + K`) | Select code, describe a change, get a diff right there | One file, one focused change |
| **Agent panel** (`Cmd/Ctrl + I`) | Full conversation. Reads files, writes across your repo, runs terminal commands, iterates | Multi-file work, "build me X", debugging |
| **Agents window** | Multiple agents running in parallel, each on its own task | Later. Don't start here |

**Do this — one exercise per surface, in your repo:**

1. **Tab:** Open `components/QuizTab.tsx`. Start typing a new function — `const handle` — and watch what it proposes. Press `Tab` to accept, `Esc` to reject. Do this five times. Get a feel for when it's right and when it's confidently wrong.
2. **Inline edit:** Select any function in that file. Hit `Cmd/Ctrl + K`. Type: `add a JSDoc comment explaining what this does`. Look at the diff. Accept or reject.
3. **Agent:** Open the panel, and ask a *question* rather than requesting a change: `Explain how QuizTab.tsx gets its data. Trace it back to Supabase.` Read the answer carefully.

**Check yourself:** Without looking above — which of the four would you use to rename a variable in one file? To add a whole new route? To fix a typo you're already mid-typing?

---

Module 2 — Context is the whole game (1.5 hrs)

**Goal:** Understand that Cursor's output quality is almost entirely a function of what you put in front of it.

The AI can't see your whole repo at once. You control what it sees using **@ symbols** in the agent panel or inline edit:

**Do this:**

Run these three prompts in your repo and compare the answers:

```
1. How should I add a leaderboard to this app?

2. @components/QuizTab.tsx @lib/supabase/client
How should I add a leaderboard to this app?

3. @components/QuizTab.tsx @lib/supabase/client @Docs Supabase
How should I add a leaderboard? Use a Postgres view for the ranking.
```

**Check yourself:** Which answer was most specific to *your* code rather than generic Next.js advice? Write down one concrete sentence explaining why. This is the lesson of the whole module.

---

Module 3 — Plan Mode (1 hr)

**Goal:** Stop letting the agent start coding immediately.

Plan Mode makes the agent research your codebase and write a plan *before* touching a single file. You read the plan, edit it, then approve. This is the highest-leverage habit in the entire tool and it's the one most people skip.

**Why it matters for you specifically:** when the agent writes a plan in plain English, you can actually understand and critique it. When it writes 400 lines of TypeScript, you can't — not yet. Plan Mode is a literacy tool disguised as a productivity tool.

**Do this:**
1. In the agent panel, switch to Plan Mode (it's a mode toggle near the input box).
2. Ask for a real feature you actually want in the study hub. Something like: `Add a "review incorrect answers" screen that shows questions the user got wrong in their last quiz attempt.`
3. Read the plan it produces. Don't approve it yet.
4. Find one thing you'd change. Anything — file placement, naming, an approach that seems overcomplicated. Tell it: `Change step 3 — put that in lib/ rather than components/, since it's not a UI concern.`
5. *Now* approve and let it build.

**Check yourself:** After it finishes, can you list which files it created or changed, and say in one sentence what each one is for? If not, ask it: `Walk me through each file you changed and why.`

---

Module 4 — Reading diffs, not vibes (1.5 hrs)

**Goal:** Build the review muscle. This is the skill that makes you dangerous.

When the agent finishes, you get a diff view. Green is added, red is removed. **Review it before accepting.** Every time. Even when it's boring.

You already know how to read diffs from Claude Code — same skill, different UI. Cursor's Agent Review view gives you the changes file by file, with accept/reject per file or per hunk.

**Do this:**

Take the feature the agent just built in Module 3 and interrogate it:

1. Go through each changed file's diff and, for every change, silently answer: *what does this do?*
2. Anywhere you can't answer, select the code and ask: `Explain this like I'm new to TypeScript. What is this line doing and why is it necessary?`
3. Find one thing you'd have done differently and change it yourself by hand. Even something trivial like a variable name. Do it *manually*, not by asking. This matters more than it sounds.
4. Run the build: `npm run build`. Confirm it passes.

**Check yourself:** Reject a change on purpose. Pick a file, hit reject, then ask the agent to redo it differently. Learning that you can say no — and that nothing breaks — changes how you use the tool.

---

Module 5 — Rules (1 hr)

**Goal:** Stop repeating yourself. Teach Cursor your project's conventions once.

Rules live in `.cursor/rules/` as files in your repo. They're version-controlled, so they travel with the project. The agent reads them automatically on every request.

**Do this — create your first rule:**

Ask the agent: `Create a .cursor/rules/ file capturing this project's conventions. First, analyse the codebase to work out what those conventions actually are, then show me a draft before writing it.`

Then edit the draft by hand. A starter for your stack might cover:

```
- This is a Next.js App Router project with TypeScript.
- Use the @/ import alias, which resolves from the project root.
- Supabase client lives at lib/supabase/client — never instantiate a new one.
- Server Components by default; add "use client" only when the component needs
interactivity or browser APIs.
- Explain the "why" when you make non-obvious choices — I'm learning.
```

That last line is a real rule and worth keeping. It turns every agent run into a small lesson.

**Check yourself:** Ask for a small new component. Did it follow your rules without being reminded? If not, your rule was probably vague — tighten it and retry.

---

Module 6 — Debugging (1 hr)

**Goal:** Use Cursor when something's broken, which is most of the time.

Cursor has a Debug Mode built for this: it adds instrumentation, reproduces the issue, narrows the root cause, and verifies the fix rather than guessing.

**The pattern that works:**

```
Bad: "the quiz is broken, fix it"
Good: "When I submit a quiz on /quiz, the score shows as NaN instead of a number.
Expected: a percentage. @components/QuizTab.tsx
Here's the console error: [paste it]"
```

Three ingredients: what you did, what you expected, what actually happened. Paste real errors. Never paraphrase an error message.

**Do this:** Break something on purpose. Change a variable name in `QuizTab.tsx` so it no longer matches, save, and see the app fail. Then hand Cursor the error and watch how it traces it. Undo when done.

**Check yourself:** Could you have found that bug yourself from the error message alone? Next time, try for two minutes before asking.

---

Module 7 — Choosing models (30 min)

**Goal:** Know that the model picker isn't decoration.

The dropdown in the agent panel currently includes Claude (Opus 5, Sonnet 5, Fable 5), GPT-5.6 variants, Gemini 3.x, Grok, and Cursor's own **Composer 2.5** — a model Cursor trained in-house specifically for fast, codebase-aware editing.

A reasonable default policy:

Every prompt costs credits against your plan's usage pool, and the bigger models cost more. That's the real tradeoff: speed and cost versus depth.

**Check yourself:** Run the same non-trivial prompt through Composer and through a frontier model. Compare. You'll feel the difference.

---

Module 8 — The rest of the surface area (browse, don't master)

You don't need these yet. Know they exist so you recognise the names:

**Do this:** Just read `cursor.com/docs/mcp` and set up the Supabase MCP server. It's the one on this list with immediate payoff for your project.

---

Cursor vs Claude Code — do you switch?

You don't have to pick. They overlap heavily and a lot of people run both:

Given you're learning, Cursor's visual diff review is a genuine advantage — it's much easier to build reading skills when changes are laid out in front of you rather than scrolling past in a terminal.

---

Suggested schedule

| Week | Modules | Time |
|---|---|---|
| 1 | 0, 1, 2 | ~3 hrs |
| 2 | 3, 4 | ~2.5 hrs |
| 3 | 5, 6, 7 | ~2.5 hrs |
| 4 | 8 + build a real feature end to end | ~3 hrs |

Total: roughly 11 hours across a month, all of it spent on your actual project so nothing is wasted.

---

The one habit that matters

After every single agent run, ask yourself: **"Could I explain this change to someone else?"**

When the answer is no, ask Cursor to explain it before you move on. Do that for three months and you won't need to ask anymore.

← UAE National MRV System: Professional's GuideFull Stack Vibe Coding for Dummies →
Two years of working thought, indexed.
Ask me to present it in your conference room — WhatsApp +971 55 623 9111
Book Session →