How to Actually Get Real Work Out of Cursor (Without Torching Your Credit Pool on Vibe Prompts)

1. Set up .cursor/rules/ before you write a single prompt

This is the single biggest shift from the old Cursor, and most tutorials still tell you to drop a .cursorrules file at your project root and call it done. Stop doing that.

.cursorrules was Cursor’s original single-file format for project-specific AI rules. It’s been functionally deprecated in favor of the .cursor/rules/*.mdc directory. Cursor moved to a directory-based system because a single file couldn’t express the granularity teams needed. The new format is genuinely better: multiple rule files, each scoped to file globs and tagged with metadata. Cursor loads only the rules that match the current context.

Here’s the format. Each rule is an .mdc file that you can name anything you want. Project rules must use the .mdc extension. A plain .md file in .cursor/rules gets ignored by the rules system because it has no frontmatter to specify description, globs, and alwaysApply. If you prefer plain markdown, use AGENTS.md instead.

A minimal .cursor/rules/typescript.mdc looks like this:

---
description: "TypeScript and React conventions for the frontend"
globs:
  - "src/**/*.tsx"
  - "src/**/*.ts"
alwaysApply: false
---

- Use functional components with hooks. No class components.
- Prefer named exports over default exports.
- All new files use TypeScript strict mode.
- Use absolute imports with the @/ prefix.

Cursor’s own guidance is refreshingly blunt: keep rules focused on the essentials, the commands to run, the patterns to follow, and pointers to canonical examples in your codebase. Reference files instead of copying their contents. Don’t paste your whole style guide in. Point at it.

And here’s the part nobody tells you: start simple. Add rules only when you notice the agent making the same mistake repeatedly. Don’t over-optimize before you understand your patterns. Check your rules into git so your whole team benefits. When you see the agent make a mistake, update the rule. The rules file is a living document, not a manifesto you write once.

2. Add an AGENTS.md if anyone on your team touches another AI tool

If you’re the only one using Cursor and always will be, skip this step. If literally anyone on your team also uses Claude Code, Codex, or Copilot, you need this.

AGENTS.md is a simple markdown file for defining agent instructions. Drop it in your project root as an alternative to .cursor/rules for straightforward use cases. Unlike Project Rules, AGENTS.md is a plain markdown file without metadata or complex configurations. It’s perfect for projects that need simple, readable instructions without the overhead of structured rules.

The important gotcha: Cursor has multiple modes with different configuration loading. Chat and Composer modes read .cursorrules (deprecated) and .cursor/rules/.mdc files. They don’t read AGENTS.md. Agent mode reads AGENTS.md and .cursor/rules/.mdc files. It doesn’t read root .cursorrules. So if you use Cursor Agent mode and you have only .cursorrules, your rules are silently ignored.

Translation: if you’ve been wondering why the agent ignores your carefully crafted .cursorrules file, that’s why. It literally doesn’t read it in Agent mode. Migrate to .cursor/rules/*.mdc today.

The pragmatic setup for a mixed-tool team: use .cursor/rules/*.mdc as your primary system (it works everywhere in Cursor, including Agent mode), and keep AGENTS.md as the multi-tool foundation for when teammates use other tools.

3. Use Plan Mode before Agent Mode. Every time.

This is the discipline habit that saves the most credits. The temptation with Agent Mode is to type a prompt, hit enter, and let it rip. Don’t. That’s how you end up with 15 files touched, three of them broken, and a diff you don’t understand.

My new workflow with Plan Mode actually builds the plan with me inside the editor. 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.

Read the plan. Edit it. Then let the agent execute it. That single interstitial step is the difference between a clean feature ship and a rollback.

If you skip Plan Mode, use Shift + Tab to enter Plan Mode. The workflow: Research -> Clarify -> Plan -> Build. Why it works: this prevents the “lazy agent” syndrome where the AI writes code based on assumptions rather than reading your existing codebase.

Cursor’s own analysts back this up: they treat agents as capable collaborators. Ask for plans. Request explanations. Push back on approaches you don’t like. Fight the plan. Then ship the fight.

4. Live in Auto mode. Reach for frontier models on purpose.

This is the single biggest lever on your bill, and most people get it wrong. They pick Claude Opus or GPT-5 by default because “more expensive = better,” and then get confused when their $20 pool evaporates in a week.

Here’s how the credit pool actually works. Since mid-2025, Cursor bills on usage, not a fixed request count. Each paid plan includes a credit pool equal to its price. Pro gives you $20 of model usage, Pro+ gives $60, and Ultra gives $200. Credits only drain when you manually pick a frontier model like Claude Sonnet, a GPT model, or Gemini. If you stay in Auto mode, Cursor picks a cost-efficient model for you and that usage doesn’t touch your pool.

The math is embarrassing when you actually run it. For a typical agent task sending 40K tokens of context and generating 4K tokens of output: Composer 2.5 costs about $0.03, Auto mode about $0.074, a frontier model about $0.18. The same task is roughly 6x cheaper on Composer 2.5 than on a frontier model. That single choice is the biggest lever on your bill.

Auto mode = effectively unlimited on paid plans, doesn’t draw from credits. Composer 2.5 = Cursor’s own cheap model, your low-cost daily driver.

The rule I use: start every task in Auto. If the result is wrong twice in a row, escalate to Claude Sonnet or Opus manually, but treat that switch as a deliberate call, not a default. If you’re already a Cursor user, Composer 2 should be your default model for day-to-day coding. It’s unlimited on paid plans when used through Auto mode, and the benchmark data shows it’s now legitimately competitive with the frontier.

5. Commit a checkpoint before every multi-file agent task

This one is boring. It’ll also save your work.

The second most common mistake is skipping the git checkpoint before multi-file refactors. Without a checkpoint, rolling back a partially completed agent run means manually undoing each file, which is painful when the agent touched 20 of them. Run git commit -m “pre-agent checkpoint” before every non-trivial agent task.

You can also encode this in your rules file so the agent does it for you: prevents data loss during long-running agent sessions. Before starting any multi-file refactoring, create a git checkpoint: git add -A && git commit -m "checkpoint: before <task>". After every successful test run, commit immediately.

The agents in 2026 are aggressive. Cursor agent mode in 2026 is no longer an autocomplete assistant, it’s an autonomous coding worker that edits multiple files simultaneously, runs in parallel across git worktrees, and completes long-running tasks without human intervention. To get consistent results, you need the right prompt structure, correct rule format, and a clear architecture for when to parallelize. A pre-agent commit is the one-line insurance policy against all of that ambition going sideways.

6. Actually review the diff. Especially the parts you didn’t ask for.

The #1 mistake I see intermediate Cursor users make is trusting the green checkmark. The code compiled, the tests passed, so it must be fine. It’s not fine.

The most common Cursor agent mistake in 2026 is trusting output without reviewing it. AI-generated code can be syntactically valid, pass type checking, and look logically correct while violating a subtle invariant, an off-by-one in pagination, a race condition in concurrent access, a missing null check in an error path. Review every multi-file diff before accepting, specifically looking for: changes to files you didn’t ask the agent to touch, removal of error handling code, new dependencies added to package.json, and changes to authentication or authorization logic.

Cursor’s own team is direct about this: they review carefully. AI-generated code can look right while being subtly wrong. Read the diffs and carefully review. The faster the agent works, the more important your review process becomes.

There’s a built-in review pass most people don’t know about. After the agent finishes, click Review → Find Issues to run a dedicated review pass. The agent analyzes proposed edits line-by-line and flags potential problems. For all local changes, open the Source Control tab and run Agent Review to compare against your main branch. Use it. It catches roughly a third of the subtle bugs that would otherwise land in your PR.

And if you’re shipping enough PRs to justify it, BugBot is Cursor’s automated pull-request reviewer, priced at roughly $40 per user per month for teams. It posts review comments on PRs before a human reviewer opens them, catching regressions and risky changes early. For teams shipping more than a few PRs per developer per week, the time savings usually pay for the subscription.

7. Turn corrections into rules. Don’t repeat yourself.

This is the habit that separates people who use Cursor for six months and hit a plateau from people who keep getting better with it. Every time you correct the agent on the same thing twice, that correction belongs in your rules file.

Corrections made in chat context aren’t persisted to future agent sessions. To make a correction permanent, encode it as a rule in .cursor/rules/*.mdc with the imperative format: “Do X, not Y, because Z.” A behavioral correction that lives only in conversation history is lost when the session ends, and even within a long session, it can be overridden by context window truncation.

Write rules as imperatives, not observations. Not “we generally prefer async.” Write “All IO-bound operations MUST be async def.” The recommended style is direct imperatives, not observations: write “never use inline mocks, use src/test/factories/*” rather than “we generally avoid inline mocks.” Anthropic’s own docs confirm that emphasis markers (IMPORTANT, YOU MUST, NEVER) measurably increase adherence.

Keep them short. The Claude team also recommends keeping each file under roughly 200 lines, with subagents handling the rest. A rules file that grows past a few hundred lines starts hurting more than it helps, the model’s attention thins out.

And ban placeholders explicitly. This one rule alone will save you hours of “why did it write // TODO: implement this in a function I asked it to build”:

Prevents agents from leaving incomplete code. NEVER use placeholder comments like ”// TODO: implement this” or ”// rest of the code”. Every function must be fully implemented or not included at all. If you can’t complete a function, explain WHY and ask for guidance. Autonomous agents (Automations) can’t ask follow-ups, they must complete or abort.

A bonus, because it matters: know what MCP is and use it

If you’re still copy-pasting error logs, database schemas, and Figma screenshots into chat, you’re doing 2024’s job in 2026’s editor.

Cursor has first-class MCP support. MCP (Model Context Protocol) is like the USB-C port for AI: it lets your editor talk to external tools and data sources via standard “servers.” In practice, adding MCPs to Cursor means less copy-paste and fewer mega-prompts. Your agent can call tools (deploy, query content, run migrations) and read project-aware context (configs, models, docs) directly, which produces more accurate, repeatable outputs.

The 2026 lineup of what Agent Mode can actually touch is genuinely wild: Cursor agents now drive a real browser for E2E testing, navigating pages, clicking elements, and filling forms, which means an Agent Mode task can write a feature, exercise it through the UI, and verify the result end-to-end without leaving the editor. Agents can also query Postgres and Supabase directly with schema reasoning. First-class integrations with Linear, GitHub, and Jira let the agent read tickets, draft PRs, and update issue state, while the Figma integration pulls design screenshots into context for UI work.

Start with one MCP server, probably your database or your issue tracker, and see how much prompt-crafting it eliminates. You won’t go back.

The habit that ties it all together: treat Cursor like an unusually capable junior developer, not a slot machine. Give it a written brief (rules). Make it draft a plan before it codes. Watch the diff. Commit before you let it run. When it makes a mistake, teach it once by writing the rule, and never correct that mistake by hand again. The developers getting real work out of Cursor in 2026 aren’t the ones who found the magic prompt. They’re the ones who stopped looking for it and started building a real working relationship with the agent. Start doing that this week, and the productivity gains stop feeling like luck.