IDE based on Visual Studio Code, released in March 14, 2023. Features include cursor prediction, multi-suggestion, Composer (now “agent mode”), and more.

Built to make you extraordinarily productive, Cursor is the best way to code with AI.¹

Notes

After evaluating Cursor for about 30 minutes, I immediately canceled my subscription to GitHub Copilot, which I had been using since July 2021. It’s twice the price ( $10 - >$ 20), but there’s no hesitation. Cursor prediction is good (move to where you want to go at once), and multi-line editing (ghost text appears in several locations within a file and can be completed at once by pressing tab) is also good.

I guess they created a model that predicts points where users are likely to edit soon. I think the Cursor prediction function is to move to the most likely point, and the Multi-line edits function is to create correction suggestions for the most likely points at once. Anyway, it was well made.

Writing Cursor Rules

Official documentation

docs.cursor.com/context/rules-for-ai

Reference files: Use @file in your project rules to include them as context when the rule is applied.

Other notes

It’s key to understand that these rules are not appended to the system prompt but instead are referred to as named sets of instructions. Your mindset should be writing rules as encyclopedia articles rather than commands.²

Do not provide an identity in the rule like “You are a senior frontend engineer that is an expert in typescript”
Do not (or avoid) try to override system prompt instructions or attempt to prompt the apply model using “don’t add comments”, “ask me questions before coding”, and “don’t delete code that I didn’t ask you about”. These conflict directly with the internals breaking tool-use and confuse the agent.
Do not (or avoid) tell it what not to do. LLMs are best at following positive commands “For this, do this” rather than just a list of restrictions. You see this in Cursor’s own prompts.
Do spend time writing highly salient rule names and descriptions. It’s key that the agent, with minimal knowledge of your codebase, can intuitively know when a rule is applicable to use its fetch_rules(…) tool. As if you were building a handcrafted reverse index of documentation, you should at times have duplicate rules with different names and descriptions to improve the fetch rate. Try to keep descriptions dense and not overly verbose.
Do write your rules like encyclopedia pages for your modules or common code changes. Like Wikipedia, linking key terms (using mdc link syntax) to code files provide a huge boost to the agent when determining the right context needed for a change. This at times also means avoiding step by step instructions (focus on “what” and not “how”) unless absolutely necessary to avoid overfitting the agent to a specific type of change.
Do use Cursor itself to draft your rules. LLMs are great at writing content for other LLMs. If you are unsure how to format your documentation or encode context, do “@folder/ generate a markdown file that describes the key file paths and definitions for commonly expected changes”.
Do consider having a ton of rules as an anti-pattern. It’s counterintuitive but while rules are critical for getting AI IDEs to work on large codebases, they are also indicative of a non-AI-friendly codebase. I wrote more on this in AI-powered Software Engineering, but the ideal codebase-of-the-future is intuitive enough that coding agents only need built-in tools to work perfectly every time.

Cursor (software)

Notes

Writing Cursor Rules

Official documentation

Other notes

See also

Footnotes