Okay, this is going to sound dumb, but I spent about three hours last weekend going through every Cursor setting one by one and deciding whether I actually use it. Not because I love settings menus, but because the surface area has roughly tripled since I started using Cursor in 2024 and I had a creeping feeling that the editor was doing too much without my consent.
If you’re new to it, Cursor is a fork of VS Code with first-class AI features baked in (tab autocomplete, an inline edit shortcut, a chat sidebar with codebase awareness, and an agent mode that can edit multiple files). I’ve been writing TypeScript, Go, and PHP in it as my daily driver. This is what survived the audit.
The two-year version of my Cursor setup
I’ll lead with the short version, because everything else is justification.
On: tab autocomplete, inline edit (Cmd-K), chat with codebase indexing, agent mode for multi-file edits, custom rules file (.cursorrules).
Off: auto-apply suggestions, auto-include open files in chat, the “explain this code” hover, automatic commit message generation, and the Composer-as-default behaviour.
That’s it. Six things on, five things off. The rest I either tolerate at defaults or have never opened.
Why I keep tab on but auto-apply off
Tab autocomplete is the feature that quietly earned its place in my workflow. It guesses the next chunk of code at the cursor and lets me accept it with Tab. After two years I trust it for boilerplate (loop scaffolding, mock data, switch arms) and I do not trust it for business logic. I’m not the first person to find this trade-off; the Cursor documentation on tab is explicit that it’s optimised for completion, not authoring.
What I turned off, hard, is anything that applies a suggestion without an explicit keystroke. There used to be a setting that auto-saved generated code as soon as the model finished. I disabled it the day I noticed it had silently rewritten a config file while I was reading the chat panel.
The pattern I now follow is, the model can suggest as much as it wants. Nothing reaches disk without me pressing Tab, Cmd-Enter, or hitting Accept. Friction is the feature.
The .cursorrules file does more than people think
I used to ignore the rules file, until I read a Cursor changelog entry describing how it gets injected into every chat as system context. Once I realised it was running on every request, I started treating it like a tiny coding style document for the project. Here’s a redacted version of one I keep in a Laravel codebase:
# Project conventions
- This is a Laravel 12 app. Prefer first-party Laravel APIs over Composer packages when both exist.
- Use form requests for validation. Do not validate inline in controllers.
- Use Filament Resources for admin screens. Do not write Blade admin tables by hand.
- All money is stored as integer cents in the database. Never store decimals.
# Style
- PHP 8.4. Use property hooks where they remove a manual getter/setter.
- TypeScript strict mode. No `as` casts in feature code; prefer `satisfies`.
- Tests live next to the code they test, never under tests/.
The payoff is that the model stops suggesting things that are technically valid but wrong for the project. I’ve had it stop reaching for raw Eloquent in places that have a repository, stop generating Bootstrap markup in a Tailwind app, and stop adding decimal money fields because I told it once in eight lines.
The trick is to write rules as constraints, not preferences. “Prefer” works less reliably than “Do not”. And keep it short, because every token costs round-trip latency.
Agent mode is great for boring edits, not for thinking
Cursor’s agent mode (now the default Composer behaviour) can edit multiple files in one go. I use it for rote refactors: rename a function across the codebase, add a field to a migration plus its model plus its form, add the same defensive check to every route handler.
What I learned the hard way is that agent mode is not a substitute for design. I tried using it to “add a comments feature” to a side project a few months ago. It produced a stack of files that compiled, ran, and were structurally wrong. The schema put comments under posts but not under any other model. The component was a one-off instead of reusable. The auth check was missing on delete. It took longer to untangle than it would have to write it myself.
Since then I follow a rule I lifted from my own post on AI debugging and feedback loops: if I can’t describe the change in one sentence, I shouldn’t be in agent mode yet. I open inline edit, work through the design with chat, and only switch to agent mode once I’d be comfortable doing the change manually.
What I turned off and why
A few specific settings I disabled, in order of how much focus they were costing me:
Auto-include open editors in chat context. By default, Cursor will quietly attach the files you have open as context for your chat. Useful sometimes. Distracting when I have ten tabs open and I just wanted to ask a Stack Overflow style question. I now attach context explicitly with @.
Auto-suggested commit messages. The model is fine at summarising a diff, but it has no idea what “why” my change is, so the commits read like generated changelogs. I’d rather write fix: clamp avatar upload at 2MB so mobile users stop hitting timeout than Updated AvatarController and added validation.
The “explain this code” hover. This is the small grey popover that appears when you hover over a function. It looked useful once. In practice, it kept popping up when I was just trying to read code. I now use Cmd+L to ask the chat when I actually want an explanation.
Composer auto-open on new file. I’d rather pick when the AI gets involved than have a side panel open every time I create a Blade view.
How I’d think about Cursor vs Copilot in 2026
I still get asked this every few weeks. The honest answer: if your editor of record is VS Code and your codebase fits in Copilot’s context window comfortably, Copilot is excellent and cheaper. Cursor wins when you want multi-file edits and codebase-aware chat in one tool, and you’re willing to pay for the model usage that buys you.
For solo devs and small teams shipping greenfield code, Cursor’s agent and chat surfaces are genuinely faster than Copilot’s. For large monorepos with strict review processes, I’d still default to Copilot plus an external assistant, because the surface area is smaller and easier to govern.
If you want me to help your team set up a sensible Cursor or Copilot baseline, that’s part of what I do for clients. Either way, please go open your settings and turn half of them off. Your editor should help you think, not race you.
