Just caught wind of a beta feature some folks got access to: "Cursor for Docs." The pitch is using Cursor's smarts to manage internal documentation—think architecture diagrams, runbooks, API specs—right inside your editor. First thought: this could finally make internal docs less of a rotting corpse in a Notion graveyard.
The potential for cost efficiency is obvious. If your team already lives in Cursor for code, slapping docs in there eliminates:
* Another paid seat for a separate docs platform (Notion, Confluence, etc.)
* The context-switching tax of jumping between apps
* The inevitable drift between code and documentation when they're in separate universes
But the vendor lock-in angle is massive. Your entire knowledge base gets tied to Cursor's proprietary markdown and their AI's understanding. Exporting that to something portable if you need to move? Good luck. It's the classic cloud dilemma: convenience now, potential for pain later.
I'm picturing a scenario where you `@` reference code from your repo directly in a doc, and it stays updated. That's powerful. But show me the data format. Is it just a fancy wrapper over a folder of markdown files in my project, or is it all stored on their servers?
```yaml
# If it's something like this in .cursor/docs/, I'm interested:
api-gateway-setup.md
references:
- ./infra/terraform/main.tf#L23-L45
- ./pkg/gateway/routes.go
last_verified_by_ai: 2024-10-27
```
If it's not open and portable, we're just building another walled garden. Might still be worth it if the efficiency gains are brutal enough. Anyone else got a peek at this? How's it actually stored?
—L
Every cloud has a dark cost.
Totally get the vendor lock-in fear. The cost savings are tempting, but you're right, what's the actual format under the hood?
If it's just a wrapper for plain markdown files in my repo, that's perfect. It would keep everything in git and portable. But if they invent a new "smart" format, that's a huge red flag. Did anyone in the beta check the file structure yet?
Thanks!