Ship in 3 Hours with Cursor

The format was the argument: one hour of tips, then two hours where everyone in the room had to ship something real. Not a demo, not a plan — deployed, or demoed to the group.

Nick Miller from Cursor joined us. He’s forward-deployed with customer teams integrating LLMs into production workflows, so his Q&A was the part I’d have paid to attend.

The rest was twelve habits I’ve accumulated from using these tools every day. They divide into four groups.

Mindset

1 — Vibe engineer, don’t vibe code. This is the same distinction I drew in January: prompt → code → hope, versus research → plan → build → review. Same tools, same speed, different outcome when someone else has to maintain it.

2 — Review everything. Read every line. Understand why it works. Check the edge cases. The model is a junior developer and you are the senior one, and the MIT finding is the cautionary note: developers expected to be 24% faster with AI and were measured 19% slower at first. Learn the tool before expecting the payoff.

Strategy

3 — Match the model to the task. Using one model for everything is the most common waste I see. Planning wants a thinking model. Execution wants a fast one. Agentic work wants something built for it.

4 — Don’t start from scratch. A blank editor is the worst place to begin, because it asks you to make every decision at once. Generate a scaffold in Lovable or v0, pull it into Cursor, and refine. Editing is easier than writing. That’s true of prose and it’s true of code.

Features people don’t use

5 — Index your docs. Models have training cutoffs and APIs change. Point Cursor at your libraries’ documentation URLs, and @docs gives you current answers instead of confidently outdated ones.

6 — Write rules. User rules are global preferences — always TypeScript with strict mode, prefer functional components. Project rules live in .cursor/rules/*.mdc and encode team conventions, architecture patterns, domain context. Rules are persistent context. Teach it once instead of repeating yourself every session.

7 — Use MCPs. The ones I actually keep installed: Perplexity for search with citations without leaving the editor, Context7 for live library docs, TaskMaster for breaking projects into tracked tasks, and Mobile for driving a real iOS or Android device while testing. MCPs are what turn Cursor from an editor into a command centre.

Workflow

8 — One task, one chat. Mega-threads are where context goes to die. Fifty messages deep, the model has diluted its own instructions and forgotten what you said at the top. Start a fresh chat per task.

9 — Plan before you execute. Jumping straight into Agent mode means it edits twenty files before you discover the approach was wrong. Plan mode first: argue the approach, agree the architecture. Then let Agent execute something you’ve already blessed.

10 — Be specific. “Fix the bug” is not a prompt. “The login form in @file:auth.tsx throws a 401 when the refresh token has expired” is. Use @file, @folder, @codebase, @web, @docs, @git — the context tools exist precisely so you don’t have to describe your codebase in prose.

11 — Checkpoint often. Cursor’s checkpoints are automatic snapshots; git commits are yours. Small atomic commits after each working feature mean a rollback costs seconds. Treat it like quicksaving in a game.

12 — Parallelise. Cursor Agent on the main feature, a background agent writing tests or docs on a separate branch, and a terminal agent working alongside. Background agents don’t collide with your main work. It’s the closest thing to having several junior developers at once.

Then two hours

The constraint is the teaching device. Two hours is long enough to build something real and short enough that you have to make decisions instead of polishing. Pick an idea, apply the tips, deploy it or demo it.

Nobody learns this from a slide. They learn it from running out of time.

Thanks to Sard Cultural Center for hosting, and to Nick for making the trip.