Our team switched to Cursor about eight months ago. We have five developers, and every one of them now uses it as their primary IDE. That's not a common outcome — developers are notoriously attached to their tooling — so when something displaces VS Code with extensions, it's worth paying attention to.
This guide covers how we actually use Cursor day-to-day: the five workflows that changed how we write code, the .cursorrules configurations that made it actually useful for our specific stack, and the honest limitations you'll hit if you go in with unrealistic expectations.
What Cursor Actually Is
Cursor is a fork of VS Code with AI features built into the editor at a deep level — not installed as an extension, but integrated into the application itself. All your VS Code extensions, themes, keybindings, and settings import cleanly. From a day-to-day UX perspective, it looks and feels like VS Code. The difference is what happens when you start writing code.
The key distinction from GitHub Copilot: Copilot is a VS Code extension that adds AI completion. Cursor is a separate application where AI is woven into every interaction — completion, editing, chat, multi-file changes, and documentation lookup all work together in a unified context window. Cursor knows about your entire project, not just the file you have open.
Cursor vs GitHub Copilot vs Claude Code vs Windsurf
Quick positioning before we go deep:
- Cursor: Best daily driver IDE for most developers. Strong at completion, inline editing, and multi-file refactoring. $20/month.
- GitHub Copilot: Best if you're already on GitHub Enterprise and need deep GitHub integration (PR summaries, code review, Issues). $19/month. We no longer use it.
- Claude Code: Best for complex architectural decisions, large codebase analysis, and autonomous multi-step tasks. Terminal-based. $5–$40/month depending on API usage. We use this alongside Cursor.
- Windsurf: Strong competitor to Cursor, better on some autonomous tasks. We've tested it for three months and find Cursor's tab completion still better day-to-day.
Installation and Setup
Download from cursor.com. The first time you open it, it offers to import your VS Code settings, extensions, and keybindings — do this. Setup takes under two minutes.
Model selection matters: Cursor's default is Claude 3.5 Sonnet for chat and Composer, with a fast proprietary model for tab completions. You can switch chat to GPT-4o or Claude 3 Opus in Settings. Our team uses Claude 3.5 Sonnet as default — it produces better code than GPT-4o for most tasks in our experience, especially with TypeScript and React.
Enable "Codebase Indexing" in Settings. Cursor will index your project files into a local vector database. This is what enables it to answer questions about your entire codebase and give contextually accurate completions. Indexing a medium-sized project (50,000 lines) takes about 2 minutes on first run.
The 5 Core Cursor Features
1. Tab Completion: Context-Aware Multi-Line Suggestions
Tab completion in Cursor is categorically different from Copilot's. Copilot completes based on the current file and your recent edits. Cursor completes based on your entire codebase — it sees your component patterns, utility functions, type definitions, and coding conventions across all files.
In practice: start typing a new API route in your Express app, and Cursor suggests the full handler including the specific middleware imports you use, the error handling pattern you defined in other routes, and the response format consistent with your existing endpoints. It doesn't just complete the current line — it completes the entire logical unit.
The .cursorrules file makes this dramatically better. Create a .cursorrules file in your project root with project-specific instructions:
With these rules, Cursor generates code that matches your project's conventions from the first suggestion. Without them, it generates plausible but inconsistent code that requires correction.
2. Cmd+K Inline Editing: Describe the Change You Want
Select a block of code, press Cmd+K, describe what you want in plain English, and Cursor applies the change inline. A diff appears showing original vs modified code. Accept with Tab, reject with Esc, or edit further.
This is most valuable for: refactoring functions to match a new pattern ("convert this class component to a functional component with hooks"), adding error handling to existing code ("add try/catch with proper error typing"), converting between patterns ("rewrite this to use the repository pattern from our DAL"), and quick transformations ("add JSDoc comments to this function").
One workflow we use constantly: select a function, Cmd+K, type "add comprehensive TypeScript types to all parameters and return values." It takes 3 seconds and eliminates a chore that used to eat 10–15 minutes per module.
3. Chat (Cmd+L): Ask Questions About Your Codebase
The Cursor chat panel opens a conversation with access to your codebase. You can @ mention files, folders, or even external documentation. The chat can answer questions like: "Where is authentication handled in this app?" or "Why might this API call be returning 403?" or "What would I need to change to add rate limiting to all admin routes?"
This has replaced 30% of our Stack Overflow searches. Questions that used to require finding relevant documentation, reading it, understanding how it applies to our specific setup, and then implementing — Cursor handles the search + contextualization in one step.
The @docs feature is underused: you can @ mention a documentation URL and Cursor will fetch and use it in the conversation. Useful for library APIs that came out after the model's knowledge cutoff.
4. Composer (Cmd+I): Multi-File Editing in One Prompt
Composer is Cursor's most powerful feature and the one that separates it from every other coding assistant. It opens a panel where you describe a change, and Cursor plans and executes edits across multiple files simultaneously.
Real examples from our work:
- "Add a createdBy field to the Project model. Update the database schema, TypeScript types, repository layer, server action, and all affected UI components." — Composer identifies all relevant files, makes consistent changes across 8 files, presents a unified diff.
- "Create a new user settings page at /settings/notifications with a form for notification preferences, using our existing form patterns and connecting to the updateUserSettings server action." — Composer creates the page, form component, and server action from scratch following our conventions.
- "Write unit tests for all functions in src/lib/utils.ts using our Vitest setup." — Composer reads the file, generates comprehensive tests, creates the test file in the right location.
5. .cursorrules: Project-Level AI Instructions
The .cursorrules file is the most important configuration in Cursor and the one most developers set up wrong (or skip entirely). It's a plain text file that defines how the AI should behave throughout your project — like a system prompt that applies to all AI interactions.
For a React + TypeScript project, a good .cursorrules covers: framework conventions, state management patterns, styling approach, error handling patterns, test structure, and any project-specific rules the AI should follow. The more specific, the better. "Use TypeScript" is useless. "All components must export a named type for their props and use the cn() utility from @/lib/utils for className concatenation" is useful.
Advanced Workflows
Codebase-Wide Refactoring
Composer handles large refactors that would normally require an afternoon of tedious find-and-replace. One real example: we needed to rename our UserProfile type to AccountProfile across 47 files (component props, API types, database mappers, test fixtures). Command to Composer: "Rename all instances of UserProfile to AccountProfile — update type names, imports, and any string references that reference this type." Result: correct changes in 44 of 47 files. Three files had edge cases requiring manual review. Total time: 8 minutes vs. an estimated 2 hours manually.
Test Generation Workflow
Our test generation workflow: select a function or module, open Composer, prompt "Write comprehensive Vitest unit tests for this module. Cover happy paths, edge cases, and error conditions. Mock external dependencies. Follow the test structure in src/__tests__/unit/ for naming and organization conventions."
Cursor generates tests, we run them, fix any that fail (usually import paths or mock setup issues), iterate. A module that would take 90 minutes to test manually takes 20 minutes with Composer. Test coverage on our project increased from 43% to 71% in the month after we adopted this workflow.
Bug Fixing with Error Context
Copy the full error message and stack trace. Paste it into Cursor chat with a reference to the relevant file ("@src/lib/auth.ts — getting this error"). Cursor diagnoses the cause and suggests a fix with the specific code change needed. For common framework errors, this is accurate 80% of the time on the first try.
Honest Limitations
Cursor is excellent but not magic. Here's what we've found doesn't work as advertised:
- Import path hallucinations: Cursor hallucinates import paths about 15% of the time — it suggests imports from modules that don't exist or have different names. Always review generated imports before accepting.
- Composer scope creep: Composer sometimes modifies files you didn't intend to change, interpreting your request more broadly than you meant. Read the full diff carefully before accepting large Composer changes.
- Large file degradation: Files over 3,000 lines significantly degrade completion and chat quality. Cursor struggles to maintain context across very long files. This is an argument for keeping files small and well-organized — which is good practice anyway.
- Framework knowledge cutoff: Cursor's models have training cutoffs. For Next.js 16 or React 19 features that shipped after the cutoff, it sometimes suggests patterns from older versions. Use @docs to point it at current documentation.
- Non-determinism: The same prompt sometimes generates different code. For consistent results, be more specific in your prompts and use .cursorrules to constrain the output space.
Pricing Breakdown
Cursor has three tiers:
- Hobby (free): 50 completions, 50 chats per month. Good for evaluation only.
- Pro ($20/month): 500 fast premium requests (GPT-4o, Claude 3.5 Sonnet), unlimited slow requests (lower priority queue), 10 Claude Opus uses per day. This is what our individual developers use.
- Business ($40/user/month): Everything in Pro plus privacy mode (zero data retention by the model), team admin dashboard, SSO, usage analytics. Required for clients with strict data security requirements.
Our Actual Workflow
We use Cursor for roughly 80% of our development work — new feature development, routine refactoring, test writing, debugging. We use Claude Code (the CLI tool) for complex multi-file architectural decisions and situations where we want an AI to plan a large change before we review and approve. GitHub Copilot: we've stopped using it entirely. The team that was on Copilot before Cursor found the transition obvious within a week.
The honest summary: Cursor doesn't write correct code for you automatically. It writes plausible code that you need to review and understand. What it eliminates is the mechanical work — boilerplate, repetitive patterns, looking up syntax, and the first draft of anything. That mechanical work was consuming 30–40% of developer time. Recovering it means shipping more, faster, with less cognitive overhead.
For a direct comparison of Cursor against GitHub Copilot, Claude Code, and Windsurf with benchmarks from our team, see our full AI coding assistant comparison. For tool-specific pricing across all AI coding tools, see the Cursor tool page.