How to Actually Ship Real Features with Cursor (Without Burning Through Your Credits)

1. Stop typing one-shot prompts. Write a brief in a scratch file.

This is the single biggest habit shift, and it’s the one almost nobody does. The chat panel feels like a chat panel, so people type into it like it’s a chat panel. That’s the trap.

Open a Markdown file in your project, call it scratch.md or brief.md, gitignore it, and write a real problem statement before you touch Agent mode. Two hundred words. What you’re trying to build, what files it touches, what the acceptance criteria are, what edge cases you’ve already thought about. Then paste it into chat when it’s ready. Cursor’s chat is good; a 200-word problem statement written in a Markdown file is better. Paste it into chat when it is ready.

The reason this works is mechanical, not magical. A vague prompt makes the agent spend its first ten tool calls guessing what you meant, reading files, asking clarifying questions, exploring the wrong directories. A real brief skips all of that. You get to the actual work on tool call one instead of tool call eleven, and on a system where standard agent mode allows 25 tool calls per interaction and each file read, edit, terminal command, or web search counts as one call , that math matters.

2. Use Plan mode before you use Agent mode

This is the second-biggest habit shift, and it’s the feature people skip because the name sounds boring.

Plan mode doesn’t touch your files. You describe what you want, Cursor crawls the project, asks clarifying questions, and spits out an editable Markdown plan (file paths, function names, the actual to-do list) that you review before any code gets written. Kick off Plan Mode by typing a prompt, but selecting “plan” instead of “agent” in the chat window. Let Cursor crawl the project — it reads docs and rules, asks clarifying questions, and generates an editable Markdown plan with file paths, code references, and a to-do list.

The plan itself is just a markdown file. The plan in reality, is just a markdown file that is stored (.cursor/plans) that is written out in human readable instructions. Think of this as the detail you have in a Jira ticket to hand off to a developer to complete. You can edit it. You can delete the bad steps. You can add the constraint the model didn’t think of. Then you hand the finished plan to Agent mode and watch it execute the thing you actually wanted.

The shortcut: short prompt, plan it, fix the plan, then build. Trying to write the perfect one-shot prompt and praying is the workflow that empties your wallet.

3. Write a real rules file. Use .cursor/rules/, not the legacy single file.

If you’re still using a single .cursorrules file at the project root, you’re working with deprecated tooling. The 2026 format is multiple .mdc files in a .cursor/rules/ directory, each scoped to specific file globs so the rule only loads when it’s actually relevant. The .cursor/rules/ directory (the preferred 2026 format, replacing the legacy single .cursorrules file) holds multiple rule files scoped to file globs, so Cursor loads only the rules matching the current context — your standing conventions, banned patterns, and architectural preferences applied automatically.

Why this matters: every always-on rule is tokens. Tokens you’re paying for. Use auto-attached rules with glob patterns instead of always-on rules to reduce the token tax. A backend rule that fires on src/api/**/*.ts doesn’t need to be loaded when you’re editing a Tailwind config.

What goes in a rule file? Not “write clean code.” That’s filler. Real, project-specific stuff:

• Your actual tech stack and version numbers (Next.js 14 App Router, not “React”)
• Naming conventions you actually enforce in review
• Banned patterns (// TODO, default exports, whatever your team hates)
• The dependency rule: verify a package exists in package.json before importing it
• Where files belong (the folder structure for new routes, services, tests)

Good rules are specific and actionable — “use camelCase for variable names,” “limit functions to 20 lines maximum,” “include type annotations for all parameters.” Bad rules are vague — “write clean code,” “make it efficient,” “follow best practices.” If a rule could appear in a fortune cookie, delete it.

4. Scope context with @ mentions instead of letting Agent guess

Cursor’s codebase indexing is genuinely good. In a hundred-thousand-file repo it’s the difference between an agent that works and one that invents module paths. But “good” doesn’t mean “free.” Every file the agent reads to figure out scope is a tool call you’re paying for and a chunk of context window you’re filling.

Scope it yourself. Use @codebase for cross-file questions, @file for one file, @folder for a specific subdirectory. Cursor’s symbol awareness is good but scoping the query is faster and cheaper.

In practice: if you’re refactoring auth, drop @folder src/auth/ and @file src/middleware.ts at the top of your message. Don’t make the agent explore. You already know where the code lives. Tell it.

And for the love of git, use .cursorignore to exclude node_modules, build artifacts, and large generated files from indexing. A dist/ folder in the index is a credit tax you’re paying for nothing.

5. Commit before every agent run. Treat git as your undo button.

Agent mode is good. Agent mode is also confidently wrong sometimes, and the version that’s confidently wrong while running terminal commands is the one that deletes a file you needed.

Commit often during agent runs. A clean git history is your rollback path. Before a multi-file refactor, before you let YOLO mode loose, before any task that touches more than three files: git add -A && git commit -m "checkpoint: before refactor". It takes four seconds. It has saved me hours, plural, on multiple occasions.

The corollary: turn off auto-run for shell commands on any production-adjacent repository. The convenience is not worth the blast radius. YOLO mode is a fine tool for greenfield prototyping in a sandbox. It’s a terrible tool on a repo with a database migration, a secrets file, or anything you can’t git reset --hard your way out of. By default, Agent asks for confirmation before running terminal commands. YOLO mode removes all confirmation dialogs. The agent runs commands, deletes files, and installs packages without asking. Enable it in Settings > Features > Chat & Composer. Only use this in sandboxed environments or projects backed by Git where you can easily revert. Read that sentence twice.

6. Start a new session per task. Stop letting context pile up.

This is the habit that separates people whose Cursor “feels slow lately” from people whose Cursor still feels sharp in month six.

The agent isn’t slow. It’s drowning in irrelevant context from the last three tasks you worked on. Start new sessions per task. Do not let unrelated context accumulate. Compact proactively at 70% context usage, not 90%.

Rule of thumb I follow: one chat per ticket. Finished the auth bug? Close that chat. Open a new one for the dashboard work. The temptation is to keep the running thread because “the agent knows the project now,” but it doesn’t, really. It knows a soup of half-finished side quests that are now noise in every new prompt.

If you need to hand off a long-running task and step away, that’s what background agents are for. Agent mode is interactive and local. Background agents are asynchronous and cloud-based. Use agent mode when you are actively working and want to steer the AI. Use background agents when you have a well-defined task you want to hand off entirely, like “add unit tests for every function in src/utils/” or “refactor all class components to functional components.” Different tool for a different job.

7. Read the diffs. Every single one.

This is the discipline one. The reason “AI coding tools made my codebase a mess” stories exist is almost never the tool. It’s the operator clicking “accept all” because the diff was long and they were tired.

Agent’s edits are applied as it works. Review them in the diff view and reject anything you don’t want. That second sentence is not optional. If you don’t have time to read the diff, you don’t have time to merge the diff.

A few specific failure modes to watch for, because they’re the ones that bite repeatedly:

• Phantom imports. The agent confidently imports a package that isn’t in package.json. A good rules file helps, but eyes on the diff confirms it.
• Silent type widening. It “fixes” a TypeScript error by changing a type to any. Compiles green, production red.
• Test deletion. A test was failing, so the agent “fixed” it by deleting the assertion. Watch for diffs that shrink your test files.
• Placeholder comments. // TODO: implement actual logic left inside a function the agent claimed it finished. Ban this in your rules file and grep for it before you push.

One more, because it matters: keep a pinned terminal

A small habit that pays for itself every day. Keep one terminal pinned. The agent will sometimes run a command and miss the output; you want to be able to rerun it yourself.

When the agent says “the tests pass” and you’re not sure, the pinned terminal is one tab away. Re-run the thing. Trust nothing the agent claims about runtime output until you’ve seen the runtime output yourself. That’s the difference between using Cursor as a collaborator and using it as a vending machine you keep feeding quarters.

The habit that ties it all together: treat Cursor like a junior engineer you’re pairing with, not a slot machine you’re pulling. A junior engineer needs a brief, a plan, a style guide, scoped context, and a code review on the way out. Give Cursor all five and it ships real work. Skip any one of them and you’ll spend your afternoon arguing with a model about why it keeps importing a package that doesn’t exist. The people getting senior-engineer output from this editor aren’t smarter. They’re just running the playbook.