一个读你的类型定义，一个只会猜字符串

---

Experience: 6 weeks of daily driving Cursor after 2 years of Copilot – here's my unfiltered take

TIL that switching AI coding assistants feels eerily similar to breaking up with someone you've been comfortable with for years. You know all their quirks, you've built muscle memory around their shortcomings, and you're genuinely not sure if the grass is greener or just fertilized with VC money.

I've been a Copilot user since the early beta days. Remember when it would randomly suggest your own API keys in completions? Good times. Actually, wait—I should clarify that I think they patched that within like 48 hours, but those were a spicy couple of days on Hacker News. About six weeks ago, I finally caved to the relentless hype on r/programming and gave Cursor a proper shot. Not the "install it for an afternoon and write a Medium article" kind of shot, but actually forcing myself to use it on a production Next.js + tRPC project. The kind of project where breaking things has actual consequences.

Here's what nobody tells you.

The good stuff that actually matters

Cursor's tab completion model is genuinely better at understanding context across multiple files. I'm not talking about the marketing fluff – I mean it actually reads your damn types. Finally.

Example 1: I have a Prisma schema with a User model that has a subscriptionTier enum. Copilot would happily autocomplete user.subscriptionTier === "premium" as a magic string. Every. Single. Time. Drove me absolutely nuts. Cursor pulled the actual enum values from the generated Prisma types three files away. That's not magic, that's just actually indexing the project properly. Something that, honestly, Copilot should have figured out by now given they've had access to the TypeScript language server since forever.

The inline editing with Cmd+K is what Copilot Chat wishes it was. You can highlight a block of code, tell it "extract the error handling into a separate function and add retry logic with exponential backoff," and it just... does it. Not perfectly, but the diff view means you can accept/reject changes line by line. That diff view is doing some heavy lifting though—without it I'd probably have shipped some truly cursed code by now.

Example 2: I had a god-awful 200-line useEffect with five different dependencies that I'd been putting off refactoring for weeks. You know the type. The kind where you add a comment like // TODO: clean this up and then proceed to ignore it for three sprints. Highlighted the whole thing, typed "split this into custom hooks and handle the race conditions properly," and it produced something that was honestly better than what I would have written at 4 PM on a Friday. Took 30 seconds.

Well... that's complicated. It was better in structure. But it also introduced a bug where the cleanup function wasn't properly aborting fetch requests on unmount. I caught it because I've been burned by that exact pattern before. If I was newer to React? Would have shipped that straight to prod.

The "oh no" moments

Cursor's composer feature (where it writes multiple files) is simultaneously the most impressive and most dangerous thing I've used. It's like giving a very enthusiastic junior dev unlimited coffee and telling them to go wild. You come back and there's code everywhere. Some of it's even correct.

Example 3: Asked it to "add rate limiting to the API routes." It created a middleware file, updated all 14 route handlers, added Redis integration, and wrote a migration for a rate limit tracking table. Impressive, right? It also decided to silently change my error response format from { error: string } to { message: string, code: number } across the entire codebase. Found that one in code review. From myself. At midnight. The git diff was like 400 lines and I almost just skimmed it because I was tired. That's the scary part.

The "apply" button in the chat interface is addictive in a way that makes me uncomfortable. I caught myself accepting suggestions without reading them properly around week three. That's not a Cursor problem, that's a me problem, but the UX definitely enables it. The button is right there. It's green. It wants to be clicked.

Stuff that surprised me

Cursor's agent mode (where it can run terminal commands) is either brilliant or terrifying depending on your trust issues. I let it run npx prisma migrate dev once and it somehow decided to also run npm audit fix --force which downgraded three packages. Thanks, I hate it. The terminal output was just scrolling and I was sitting there like "wait what are you doing." Had to spend 20 minutes figuring out which versions got bumped down and why my build was suddenly failing in CI.

The .cursorrules file is actually useful, unlike Copilot's workspace settings which felt like writing wishes in a bottle and throwing them into the ocean. I told it "always use the cn() utility for class names, never template literals" and it actually listened. Most of the time. I'd say like 85% compliance rate, which is honestly better than I expected. The other 15% it just... forgets? I don't know how else to describe it. Like it gets excited about a particularly clever template literal and just goes for it.

Privacy-wise, Cursor has an option to not store code on their servers, which Copilot also offers now. I'm not qualified to audit either claim, so I just assume both are lying and don't paste my .env files. Standard operating procedure. I think Cursor's privacy mode is called "Privacy Mode" in settings, Copilot's is buried somewhere in the GitHub settings labyrinth. Neither of them make it particularly obvious whether it's actually doing anything.

What Copilot still does better

Copilot's suggestions feel more "invisible" in a good way. They just appear as you type, and the latency is slightly lower. Cursor sometimes has this micro-pause that makes me second-guess whether it's working. We're talking maybe 200-300ms difference, but when you're in flow state, you feel it. It's like a tiny stutter in an otherwise smooth conversation.

Copilot also has better support in JetBrains IDEs if that's your thing. I'm a VS Code gremlin so it doesn't affect me, but my coworker who lives in IntelliJ tried Cursor and went back within a week. He said the plugin felt "bolted on" which, fair. Cursor is basically a VS Code fork, so expecting it to work seamlessly in IntelliJ is probably unrealistic.

GitHub's ecosystem integration is the obvious elephant in the room. Copilot has context from your PRs, your issues, your entire GitHub workflow. Cursor can't compete there, and honestly, I'm not sure they should try. That's a different product at that point. Though I saw somewhere that Cursor is working on some kind of codebase indexing thing that pulls from git history? Could be wrong. Might have dreamed that.

The real talk

After six weeks, I'm sticking with Cursor for my personal projects but keeping Copilot on the work machine. The context awareness is genuinely better, and the inline editing has become part of my workflow in a way that would be hard to give up. I keep hitting Cmd+K in Copilot out of muscle memory and getting disappointed.

But – and this is the important part – neither tool will save you from bad architecture decisions. I've seen threads where people talk about AI coding assistants like they're pair programming with a senior engineer. They're not. They're pair programming with someone who has read every Stack Overflow answer ever written but has never actually maintained a production system for five years. That person who read Clean Code once and now thinks every function should be exactly four lines. You know the type.

The best analogy I can give: Copilot is like a really good autocomplete on steroids. Cursor is like having a very fast, somewhat reckless junior dev who occasionally commits war crimes against your codebase but also ships features while you're making coffee. Sometimes that's exactly what you need. Sometimes it's absolutely not.

I think the real skill with these tools—and this is something I'm still figuring out—is knowing when to let them run and when to reign them in. The composer feature is amazing for boilerplate. It's terrifying for business logic. But the line between those two things isn't always obvious until you're staring at a PR that somehow changed your API contract without asking.

TL;DR:

• Cursor's multi-file context awareness is legitimately better than Copilot
• Inline editing (Cmd+K) is the killer feature Copilot is missing
• Composer/agent features are powerful but dangerous – review everything
• Copilot wins on latency, JetBrains support, and GitHub integration
• I'm using Cursor for personal projects, Copilot for work (for now)
• Both will happily generate confident-looking garbage if you let them

What's your experience been? Anyone found a .cursorrules config that prevents the AI from going rogue on refactors? Drop your horror stories below, I need to feel better about my rate limiting incident. Also if anyone's figured out how to make the agent mode ask for confirmation before running random npm commands, please enlighten me. I'm tired of living in fear.

Edit: formatting

Edit 2: Several people asked about the .cursorrules file. Here's what I'm using currently – YMMV heavily depending on your stack. The key is being specific about patterns you want enforced, not vague instructions. "Use functional components" is useless. "Always use arrow function components with explicit return types" actually works. Specificity matters way more than I expected.

Edit 3: Thanks for the gold, kind stranger. Glad my suffering is entertaining.

Edit 4: Since a few folks asked—I'm on Cursor version 0.42.5 (the one that dropped like November 15th-ish) and Copilot's latest VS Code extension as of last week. Not using the Copilot Chat beta that just came out, so can't compare that yet. Maybe next month's post.

#cursor #githubcopilot #devtools #ai #webdev