You installed Cursor because your coworker said it changed their life. You use it every day. You type in the box, accept the code, push. And you're getting maybe a quarter of what it can actually do.

I've been using Cursor since early 2025. The first month was frustrating — code that half-worked, context that drifted, agents that went rogue. Then I started digging into the settings nobody talks about. The difference between where I started and where I am now isn't a better model. It's knowing what's already there.

Tip 1: The Rules System Has Five Levels. You're Using One.

What everyone does: Creates a .cursorrules file in the project root, pastes in "don't be lazy" and a few style preferences, and calls it done.

What I do: I use a layered rules architecture that saves tokens and actually works:

  1. Global IDE Rules (Cursor Settings > Rules for AI): Universal standards that apply to every project — "strict typing", "pure functions only", "raise errors explicitly". Set once, never repeat.
  2. Repository Rules (.cursor/index.mdc with Rule Type "Always"): The project's README for AI. Architecture decisions, stack choices, folder conventions. This is what replaces the old .cursorrules.
  3. Dynamic Rules (.cursor/rules/*.mdc): Context-aware files that auto-attach only when relevant. A testing.mdc that activates when the AI touches tests. An api.mdc for authentication patterns. Each one is under 30 lines.
  4. Team Rules: Organization-level rules that sync across all devs. If you're on a team and don't have these, you're the only one whose Cursor behaves differently.
  5. Inline prompts: The .cursorrules file you already know. Use it as the fallback, not the foundation.

Why nobody knows about it: The .cursor/index.mdc format replaced .cursorrules relatively recently. The documentation buries it in a "Project Rules" page that most users never visit. And the dynamic rules system lives in a separate settings tab that looks like it's for enterprise users only.

What broke: I stuffed my index.mdc with 200 lines of style rules on day one. The agent started ignoring half of them because the context window was saturated before it even saw my code. Split into focused .mdc files under 30 lines each and it worked immediately.

Tip 2: YOLO Mode Isn't Just "Run Without Asking"

What everyone does: Turns on YOLO mode (or doesn't — they're scared of it) and watches the agent make changes without understanding the allow/deny lists underneath.

What I do: I configure YOLO with a deny list for destructive commands and an allow list for safe ones:

  • Allowed: npm test, tsc --noEmit, eslint, git diff, pytest
  • Denied: rm -rf, git push --force, DROP TABLE, anything with sudo

Then I tell the agent: "Run tsc. If there are errors, fix them. Run tests. If they fail, iterate." The agent loops until the build is green. I get a working PR without babysitting every command approval.

Why nobody knows about it: The allow/deny list settings are tucked under Settings > Features > YOLO Mode > Allowed/Denied Commands. Not in the onboarding flow. Not in the Cursor docs homepage. You have to click through three menus to find it.

What broke: I once allowed npm run build without realizing it triggered a deployment script in our CI config. The agent deployed a half-finished feature to staging. Now I deny anything with deploy, publish, or release in the name.

Tip 3: There's a "Bug Finder" That Checks for Regressions Before You Push

What everyone does: Runs their own tests, maybe glances at git diff, and hopes nothing broke.

What I do: I press Cmd+Shift+P and type "Bug Finder". It compares my current changes against the main branch and flags potential regressions — things like removed imports, changed function signatures, or logic that no longer matches how the rest of the codebase works.

Why nobody knows about it: It's buried in the command palette, not on any toolbar. No keyboard shortcut by default. No menu entry. You'd only find it if you already knew to search for it.

What broke: Bug Finder caught a subtle bug where I'd changed a function's return type but forgot to update a caller two directories over. It flagged it as "potential type mismatch". Would have been a runtime error in production.

Tip 4: "Explain This Code" Changes How You Read Codebases

What everyone does: Highlights a block of code, hits Cmd+L, and types "explain this". Gets a generic summary. Moves on.

What I do: I select code, right-click, and use the dedicated "Explain This Code" action (not the chat prompt). The difference: it uses the codebase index to pull in the call graph, variable origins, and related files. Instead of "this function loops over items and returns a list," I get "this function is called by three other functions, the items parameter comes from the database query on line 42, and the return value is consumed by the caching layer on line 87."

Why nobody knows about it: Most users don't realize there's a dedicated action separate from the chat. The right-click menu is crowded with extensions. And the feature doesn't advertise that it uses the codebase index — it just works better, and nobody asks why.

What broke: On a legacy codebase with 200+ files, Explain This Code gave me a wrong explanation because the index hadn't been refreshed after a major refactor. Force re-index (Cmd+Shift+P > Cursor: Reindex) fixed it, but I lost 20 minutes trusting bad output.

Tip 5: The "Zombie Revert" Bug Steals Your Changes Silently

What everyone does: Makes edits in Cursor, accepts the AI's changes, and five minutes later discovers the file reverted to an older version. Blames the AI. Restarts Cursor. It happens again.

What I do: I know it's a file-locking conflict between the Agent Review Tab and the editor. The fix:

  1. Close the Agent Review Tab before using "Fix in Chat"
  2. Disable "Format On Save" (it triggers the race condition)
  3. Commit to git frequently — git add -p after each meaningful change

This bug exists in Cursor versions 2.4.x through 2.6.x. It's been reported on the forum but not fixed yet.

Why nobody knows about it: Cursor doesn't tell you when a revert happens. There's no "file was reverted" notification. The changes just quietly disappear. Most users blame their own memory or the AI's stability.

What broke: I lost about 40 lines of auth middleware code to this. Took me an hour to realize the file on disk didn't match what I'd accepted. Now I commit after every significant AI edit. It adds 10 seconds but saves hours.

Tip 6: Terminal Cmd+K Lets You Speak English to the Command Line

What everyone does: Opens the integrated terminal, forgets the exact flag syntax for a command they use once a month, and Googles it.

What I do: I press Cmd+K inside the terminal and type natural language: "show me the five most recent git branches sorted by last commit date" or "find all Python files modified in the last 24 hours". Cursor generates the command, I review it, hit Enter.

Why nobody knows about it: The terminal Cmd+K prompt isn't mentioned in Cursor's main feature tour. It's the same keyboard shortcut as the inline code editor prompt, so context is everything — most users never try it in the terminal specifically.

So What

Cursor isn't an AI code editor. It's an operating system for AI-assisted development, and most people are using it like a fancy autocomplete.

The gap between a developer who types code into Cursor and a developer who configures rules, manages context, and orchestrates agents isn't talent. It's fifteen minutes of settings exploration.

Pick one of these. Not all six. Open Cursor right now, go to Settings, and change one thing. The people who get 10x out of these tools aren't the ones who read every release note. They're the ones who found the one setting that fixed the thing that annoyed them every day.