The kitchen-rebuild analogy
Strapping a sous-vide onto an existing kitchen works — sort of. But a kitchen designed around sous-vide flows differently: the cooler is bigger, the bench layout is different, the timing is choreographed for it. Same outputs, less friction.
Old IDEs added AI as a panel on the side. Cursor is the rebuilt kitchen: the AI lives in the centre of the editor, not bolted on. Tab completes. Composer edits across files. Chat reads the whole repo. The unit isn't the line or the panel — it's the working session.
What Cursor does differently
- Tab to accept — inline AI suggestions stretch across multiple lines and into the next edit you'll likely make. Press Tab to chain them.
- Composer — describe a multi-file change in natural language; Cursor edits the files, shows you the diff, and you accept block by block.
- Repo-aware chat —
@codebase,@file,@docsreferences pull context. The model sees real code, not what you remember to paste. - Apply / Reject patches — review every diff before it lands. The friction is calibrated for "trust but verify."
Why repo-awareness matters
Most "AI in your editor" tools see only the current file. Real bugs span boundaries — a call site, a definition, a test. Cursor's repo index lets the model jump:
- "Where is
processInvoiceactually called?" - "Does this type have a test?"
- "Is there a similar handler I should mirror?"
That single capability is what turns it from autocomplete to "AI that can refactor with you."
Cursor vs vanilla VS Code + Copilot
| Capability | VS Code + Copilot | Cursor |
|---|---|---|
| Inline completion | ✅ | ✅ (longer ranges, smarter chains) |
| Multi-file edits | Copilot Edits | Composer (deeper) |
| Repo-aware chat | Limited | Native, with @ references |
| Custom rules / docs as context | Manual | First-class (.cursor/rules) |
| Switch models | Single (Copilot) | Multiple (Claude, GPT, Gemini) |
The gap narrows every release. The directional difference: Cursor leans more into the AI flow; Copilot keeps the editor mostly conventional.
Patterns that work in Cursor
.cursor/rulesfiles — repo-specific instructions ("never use Lodash; prefer native"). Read on every chat.- Composer for refactors — describe the goal, walk the diff. Save manual file-jumping.
- Reference docs explicitly —
@docs/styleguide.mdbeats hoping the model remembers. - Use Apply / Reject discipline — never blanket-accept a Composer run on important code.
Where the editor approach hits limits
- Real terminal work — running long jobs, reading server logs, infra commands. Cursor can shell out, but a CLI agent (Claude Code) is more native.
- Spec-driven autonomous tasks — when you'd rather hand off "build feature X" and walk away. Editors keep you in the loop; that's a feature and a constraint.
- Heavy repo navigation — sometimes a CLI grep + file read is just faster than the chat round-trip.
The right framing
Cursor is not "VS Code with a chatbot." It's the bet that the IDE is the right surface for AI-assisted coding — that staying in the file, the diff, and the keyboard beats popping out to an external agent. For 80% of daily work, that bet pays off.
For the other 20% — agentic, terminal-driven, multi-step — pair it with a CLI agent. They co-exist beautifully.
In one line
Cursor is what happens when you redesign the editor around AI instead of adding AI to the editor — and it has set the bar for "AI-native" coding tools.