AI-Powered Development with Cursor AI

1 · What Cursor is essential

You've probably already tried "AI in your editor" and been underwhelmed. A little autocomplete plugin suggests the end of a line, you tab it, and that's the whole relationship — the model is a guest sitting in a side panel, occasionally handed a scrap of your file and asked to guess. Cursor starts from the opposite premise: what if the model didn't visit the editor but lived in it — able to read your whole repository, edit files directly, and carry out a multi-step task on its own? That single design flip is the reason this chapter exists, and it changes how you work more than any one feature does.

Here's a useful way to hold it in your head: think of the difference between a dictionary sitting on your desk and a fluent colleague sitting next to you. The dictionary (old-style autocomplete) answers exactly what you point at, one word at a time, with no idea what you're building. The colleague (Cursor) has read the codebase, understands what you're trying to do, and can go make a change across several files while you watch. Same underlying language model — completely different amount of context and agency wired into it. Everything else in this lesson is really about managing that context and that agency.

Concretely, Cursor is a VS Code fork rebuilt around the model. Because it's a fork, everything you already know about VS Code — extensions, keybindings, the terminal, your settings — still works, so there's no editor to relearn; the AI is simply woven through it. The common beginner mistake is to keep treating it like plain VS Code with a fancier autocomplete and never touch the deeper surfaces. The AI isn't a side panel — it edits your files, reads your repo, and runs multi-step changes. It exposes four surfaces, and the skill this whole chapter builds is knowing which one to reach for: Tab (autocomplete), Cmd-K (inline edit), chat (ask about the codebase), and the agent (multi-file tasks). Each is a different point on a dial from "tiny, instantly-verifiable suggestion" to "large, autonomous change you must review" — and matching the surface to the job is what separates someone who's fast and safe with Cursor from someone who's just fast.

2 · The four surfaces essential

The fastest way to get frustrated with Cursor is to use the wrong surface for the job. People open the agent to finish a single line, or type a whole feature request into Tab and wonder why nothing happens. The four surfaces aren't four flavours of the same thing — they're four different sizes of request, and each one asks a different amount of trust from you. Picking the right size up front is most of the skill.

The organizing idea is a dial that runs from tiny and instant to big and autonomous. Think of the range of ways you'd ask a capable colleague for help. Sometimes you just want them to finish your sentence (Tab) — you'll see instantly whether it's right, so there's almost no risk. Sometimes you want them to reword the paragraph you've highlighted (Cmd-K) — a bounded edit to a piece you've already selected. Sometimes you don't want an edit at all, you want to ask a question and understand something (chat). And sometimes you hand them a whole task — "add pagination end to end" — and let them go work across several files, run commands, and come back with a proposal (agent). The bigger the ask, the more autonomy you grant, and the more carefully you have to check what comes back.

The rule that falls out of this — and it's worth tattooing on your workflow — is use the lightest surface that does the job. Verification is the hidden cost of every AI edit: a Tab completion you can eyeball in a second, but an agent run can touch a dozen files and needs a real diff review. If a change is small and mechanical, don't summon the agent just because it's powerful; you'll pay in review time for autonomy you didn't need. Read the table below not as four features to memorize but as that dial, left (cheapest to verify) to right (most powerful, most to review) — and let "how bounded is this change, and how fast can I check it?" pick the surface for you.

3 · Intermediate — context is everything intermediate

Here's the single idea that, once it clicks, makes you dramatically better at Cursor overnight. The model does not know your codebase. It cannot see your files unless something puts them in front of it. When you type "fix this bug" with nothing attached, the model isn't being lazy or stupid — it's answering the only way it can, by guessing what your code probably looks like based on the millions of other codebases it saw in training. Sometimes the guess is close. Often it invents a function that doesn't exist, imports a library you don't use, or "fixes" a bug in a version of your file that lives only in its imagination.

The analogy that makes this concrete: imagine texting a brilliant senior engineer who is not looking at your screen. If you text "the login is broken, fix it," the best they can do is describe a generic login fix — they're guessing at your stack. If instead you text "login throws a 500 — here's the authenticate() function [paste], here's the User model [paste], and here's the stack trace [paste]," they can point at the exact broken line. Same engineer, same question — the difference in the answer is entirely the context you handed over. Cursor's @-references are how you paste those things without leaving the editor.

Cursor is only as good as the context you give it. Use @file, @folder, @docs, and @web to point it at exactly what matters. Vague prompt + no context = generic code; precise prompt + the right files = a correct edit. The common beginner trap is spending all your effort polishing the wording of the prompt while attaching nothing — a beautifully phrased request over an empty context still leaves the model guessing. The reverse is far more effective: attach the two or three files that actually matter and even a terse ask lands well. That's exactly why the little scorer in the lab below rewards attached context more than clever phrasing — because in practice, pointing the model at the right files is the highest-leverage move you can make, and it's the one beginners skip.

prompt_quality.pydef prompt_quality(text, at_refs, has_acceptance):
    score = 0
    score += 2 if len(text.split()) >= 8 else 0     # specific ask
    score += min(len(at_refs), 3)                   # @file/@folder context
    score += 1 if has_acceptance else 0             # "it should ..." criteria
    verdict = "good" if score >= 4 else "too vague — add context/criteria"
    return score, verdict

print(prompt_quality("add pagination to the users endpoint",
                     at_refs=["@users.py", "@schema.sql"], has_acceptance=True))
print(prompt_quality("fix it", at_refs=[], has_acceptance=False))

(6, 'good')
(0, 'too vague — add context/criteria')

4 · Advanced — rules & the agent advanced

Notice a chore creeping into your Cursor sessions: every few prompts you find yourself re-typing the same reminders. "Use type hints." "We use pytest, not unittest." "Don't touch the generated folder." You're acting as the model's memory, and it's tedious and error-prone — forget the reminder once and the AI happily writes code in a style your reviewer will reject. Project rules exist to end that chore, and the agent exists to take on the tasks too big for a single edit. This section is where Cursor stops being a smarter autocomplete and starts being something that works on your behalf.

Take rules first. A .cursor/rules file is a set of standing instructions Cursor silently prepends to every request in the project — think of it as an onboarding doc the AI actually reads before every single task, instead of a wiki page a new hire skims once and forgets. Your conventions, your stack, your do/don'ts, written once and committed to the repo so every teammate's Cursor obeys the same rules. That's the leverage: you encode "how we do things here" a single time, and it shapes thousands of future edits. The important honesty here — and the next section's exercises hammer it — is that rules are strong hints, not hard walls; they steer the common case beautifully but a determined model wrestling a big diff can still drift, which is why real "must-nevers" belong in a linter or CI, not just a rule.

Then the agent. Where Tab and Cmd-K make one edit you asked for, the agent takes a goal and figures out the steps: it plans, edits across files, runs commands, reads the errors, and fixes its own mistakes — a loop that keeps going until the task looks done or it gets stuck. That autonomy is genuinely powerful and genuinely the risk of the chapter: the same speed that lets it wire up a feature across six files also lets it introduce a subtle bug in a seventh you weren't watching. So the discipline arrives with the power — review its diff before accepting, every time, which is exactly the professional habit the next section is built around. For now, read the rules file below as the AI's permanent instructions, and remember it produces no output on its own; it just quietly bends every later request toward your conventions.

conventions.mdc---
description: Team conventions Cursor must follow
alwaysApply: true
---
- Python: type hints on all public functions; use pytest, not unittest.
- Never edit files under `generated/` or `migrations/`.
- Prefer stdlib; ask before adding a dependency.
- All new endpoints need a test in tests/ and an entry in the OpenAPI spec.

5 · Professional — review the diff, always professional

This is the habit that separates professionals from people who eventually get burned. The agent runs, the terminal scrolls, the tests go green, and there's a powerful pull to just click Accept and move on — the code works, doesn't it? That instinct is exactly the trap. "Tests pass" only proves the code doesn't break the things you happened to test; it says nothing about the untested branch it quietly rewrote, the extra file it edited "while it was in there," or the secret it helpfully hard-coded. Green is a floor, not a ceiling.

The mental reframe that fixes this: an agent's edit is a proposal, not a fact. Treat every agent run exactly like a pull request from a talented but junior developer — one who is fast, eager, and occasionally does something surprising because they didn't share your context. You would never merge a junior's PR unread just because CI was green; you read every line, you question the changes you didn't ask for, and you check the negative space — did they add tests for the new paths, did they remove something they shouldn't have? The same standard applies here, and it does not relax because a machine typed the code.

Here's the part people miss: your job as the human doesn't shrink when the AI writes the code — it shifts. You spend less time typing and more time judging, and judging well is the harder, more valuable skill. The velocity is real and worth having, but velocity without review is precisely the mechanism by which AI edits slip subtle, expensive bugs into a codebase that nobody notices until production. Keep diffs small and single-purpose so they're actually reviewable; reject a sprawling multi-concern change and ask the agent to split it. In short:

The agent can touch many files fast — that's the power and the risk. Treat every agent run like a PR from a junior dev: read the diff, run the tests, don't accept blindly. Speed without review is how AI edits introduce subtle bugs.

6 · Tech-lead — rolling Cursor out to a team tech-lead

The classic way to roll out a tool like this fails quietly. A lead buys thirty licenses, sends a "Cursor is live!" email, and declares victory. Six weeks later the codebase has thirty subtly different styles, review queues are clogged with giant unreviewed AI dumps, and the incident rate is creeping up while everyone insists they're "shipping faster." Nothing dramatic broke — the rollout just optimized for the wrong thing. Handing out access is the easy 5%; the process around it is the 95% that decides whether this becomes a real team gain or a slow-motion quality regression.

The reframe for a lead: you're not rolling out a tool, you're rolling out a practice. Everything you learned as an individual in the sections above — attach the right context, encode conventions in rules, review every diff — has to become the team's default, not each person's private discovery. And because the tool's value is famously bimodal on skill (the same license makes a careful engineer much faster and a careless one much more dangerous), the lever is training the habits, not distributing the licenses. Two things especially don't scale by osmosis and must be made explicit: the verify discipline and context-attachment muscle memory.

The other half of the job is guardrails and measurement, because trust alone doesn't hold at thirty people. Some conventions are non-negotiable and belong in tooling the model can't overrule — secret-scanning in CI, indexing settings that respect what may leave your network, repos that are simply off-limits. And you have to watch the right dials: it's tempting to celebrate a falling PR cycle time, but if review time is rising and incidents are ticking up, you've bought speed by spending quality — the exact trade a good rollout is designed to catch early. A sensible sequence is a small pilot first, then shared rules, then the review standard, then org-wide. In practice:

A lead standardizes the setup: shared .cursor/rules in the repo, a model policy (which models, privacy mode for sensitive code), a norm that agent diffs go through review, and guidance on when to use Tab vs agent. This turns individual speedups into a consistent team gain without a quality regression.

1. Use the existing `db.session` for DB access; never open raw connections.
2. All new endpoints must validate input with the Pydantic models in schemas/.
3. Write pytest tests alongside new functions; match the style in tests/.

Knowledge check check yourself