A friend asked me last month whether he should switch from VSCode to Cursor. He’d done his homework on features, pricing, model quality. The question he hadn’t asked: “What does it cost to switch back?”
For most software-tool decisions this question is irrelevant — switching costs are low, you try it, you decide, you move on. For AI editors specifically, the answer is more complicated than it looks. The lock-in isn’t where most people are looking, and it’s worth thinking about before the switch, not after.
The lock-in that’s obvious
The visible lock-in items, the ones every “should I switch?” article covers:
- Settings, themes, keybindings. Easy to recreate. Maybe 30 minutes.
- Extensions you depend on. Cursor has VSCode extension compatibility for most things. Some niche extensions break. A few hours of pain at most.
- Project-specific configuration.
.vscode/settings.jsonmostly works in Cursor. Minor adjustments.
Nobody loses sleep over these. They’re real friction but bounded.
The lock-in that’s structural
The harder things to switch away from, in order of how much they actually matter:
1. The AI features you can’t get back
This is the biggest one and the least discussed. Once you’ve used Cursor’s Composer for a few months, going back to VSCode without it feels like losing a limb. Once you’ve used Cursor’s codebase indexing, the equivalent in stock VSCode (none, basically) is genuinely worse.
The lock-in here isn’t a contract or a data format. It’s that you’ve adapted your workflow to capabilities the new tool doesn’t have. Reverting means doing things by hand that you stopped doing by hand. That’s not impossible, but it’s slower than the workflow you grew into.
This applies symmetrically: once you’ve used Cmd+I in Zed for a month, going back to Cursor without that specific shortcut feels wrong. The lock-in isn’t to a vendor; it’s to a set of capabilities and shortcuts that exist together.
2. Configuration that lives in the editor
.cursor/rules/ is Cursor-specific. .aider.conf.yml is Aider-specific. Zed’s ~/.config/zed/settings.json doesn’t transfer. None of these have a portable format.
If you’ve spent three months refining a .cursor/rules/ directory that captures your team’s conventions in 200 lines of carefully-tuned guidance, switching to Windsurf means starting that work over from scratch. Windsurf has its own rules system. They’re not interchangeable.
For a single developer, this is a few hours of re-doing setup. For a team that’s standardized on a tool, this is weeks of re-standardizing.
3. The conversations you’ve had
Cursor saves chat history per-project. Windsurf does the same. These histories aren’t portable. If you’ve had 50 useful conversations with Cursor about your codebase and want to reference one when explaining something to a teammate, switching tools loses all of it.
This sounds minor and feels major. The chat history is a kind of project knowledge — informal documentation of decisions, context, why-we-did-it-this-way. Most teams don’t realize how much of this they’ve accumulated until they consider switching.
4. The model behavior you’ve calibrated to
Each AI editor has subtly different prompting expectations. Cursor’s Composer responds best to one kind of brief. Windsurf’s Cascade responds best to another. Aider expects yet a different communication style.
The team I work with has, over months, internalized “how to talk to Cursor.” That tacit knowledge doesn’t transfer cleanly. The first month after a switch, productivity drops because you’re relearning how to phrase things effectively. Eventually you adapt. But the cost is real.
5. The network effects of team standardization
If your team is on Cursor, you share .cursor/rules/ files, you swap tips about prompts, you onboard new hires by pointing them at Cursor docs. Switching one person off Cursor isn’t a personal decision — it’s stepping out of the team’s tooling consensus.
This is the strongest lock-in for organizations and the one that most rationalizes “we’ll just stay on what works.” Even if a competitor is meaningfully better, the cost of the team migration usually outweighs the per-developer benefit.
What this means in practice
The lock-in isn’t fatal. People switch tools all the time. But the calculus is different from “is the new tool better?” — it’s “is the new tool better by enough margin to overcome the switching cost?”
For a solo developer evaluating tools, the cost is real but manageable: a week or two of slower work, some lost configuration, some retraining muscle memory. If the new tool is meaningfully better for your work, it’s worth it.
For a team of 20 evaluating a switch, the cost is much larger: standardizing new conventions, re-training onboarding, lost institutional chat history, weeks of mixed adoption with people on different tools. Unless the new tool is dramatically better, the math usually doesn’t work.
The case for portable habits
The hedge against this is to build habits that aren’t tool-specific.
- Write conventions as plain markdown documents in your repo, even if you also have tool-specific rules files. The markdown survives any tool change.
- Don’t rely on chat history as documentation. If something is worth remembering, write it into the codebase or a doc.
- Learn the underlying skills, not the tool’s shortcuts. The discipline of writing a good Composer brief is the same discipline as writing a good Cascade brief or a good Aider prompt. Get good at the discipline; the tool-specific syntax follows.
- Pay attention to which features you’ve adapted to. When something becomes muscle memory, ask: “Could I do this elsewhere?” The answer being “no” is a signal of accumulating lock-in.
This is the same advice that applies to any vendor relationship. The specific failure mode for AI tools is that the lock-in is mostly invisible until you try to leave.
The honest assessment
I’m currently on Cursor as my primary, Aider as my secondary. I’ve been on this combination for about eight months. If a meaningfully better tool launched tomorrow, switching would cost me real time — probably 2-3 weeks of degraded productivity before the new tool felt natural.
That’s not enormous. It’s not nothing either. The decision to switch would have to clear that bar.
For my friend deciding whether to try Cursor: my advice was “try it, you’ll know in two weeks if it’s better, but realize that two weeks in, you’re already partly locked in.” This isn’t a reason not to try. It’s a reason to make the decision deliberately.
The lock-in itself is downstream. The decision to incur it is upstream. Most people are making that decision without naming it.