What does this solve?
Classic autocompletion tells you the name of the method. Then the person writes the body himself, installs error handling himself, and changes the calling code himself. The model writes all this in its entirety in a separate window, but its answer must be transferred by hand and checked against the current state of the file.
Cursor removes the window in the middle. The padding does not predict the next word, but the next edit - including multi-line and elsewhere in the file. The selected piece is rewritten according to the description right on the spot, with changes highlighted. The agent edits several files at once and displays the result in the usual diff form, which is accepted or rejected in pieces.
The second closed pain is context. Models in the chat have to explain in words how the project works. Here an index is collected for the project, and the necessary files, library documentation and repository rules are pulled into the request without manual copying.
How it works
Base
Cursor is built as a fork of VS Code. From here immediately familiar keyboard shortcuts, a file tree, a built-in terminal, a debugger, settings in JSON and support for extensions. Transferring settings and layouts from VS Code is done by importing the first time you launch it. The model part is built into the application itself, and not attached by an extension, so it reaches the diff viewer, terminal and edit history.
Tab: next edit prediction
Basic mode of daily operation. The cursor is in the code, the editor offers continuation in gray text, Tab accepts. Difference from old autocompletes - a coherent edit is predicted: a variable in the declaration is renamed, the editor suggests picking it up below; changed one field in the structure, the editor leads through the remaining places in the same file. Accepting a hint often jumps the cursor to the next place that needs to be changed.
The add-on model is separate and optimized for speed: the latency here is more important than the depth of reasoning.
Online editing
A piece of code is selected, the inline mode is called, a description is written - “put it in a separate function”, “add processing of an empty response”. The edit is applied on the spot with green-red highlighting, accepted or rejected. The same mode works in the terminal: the description in words turns into a command, which is visible in its entirety before launching.
Chat and explicit context
Chat panel next to the code. Context is added by explicit @-links: a specific file, folder, piece of code, library documentation, web page, changes to git. An explicit link is stronger than automatic selection: when the answer is missed, the first check is what exactly is included in the context, this is visible in the list above the answer.
Agent
Mode where the model works itself: searches for files, edits them, runs commands in the terminal with confirmation, reads the output, fixes what has fallen and moves on. Everything done is put into diff by files. The state is saved by checkpoints, to which you can roll back the entire edit session - the only convenient way to undo dozens of changes scattered throughout the project.
Codebase index
When opening a project, files are cut into pieces, vector representations are considered for the pieces, the search is carried out by meaning, and not just by substring. Due to this, the question “where is the phone validated here” finds the right place, even if the word “phone” does not appear in the code.
What to exclude from the index and from the context is specified by the file .cursorignore at the root - syntax like .gitignore. Everything that should not go outside is put there: configs with secrets, dumps, downloads of client data. The settings have an increased privacy mode that limits the storage of code on the service side; for a closed loop, its condition is checked before starting work, and not after.
Rules
Permanent instructions for the model live in the repository, in the folder .cursor/rules. The rule can be always active, connected by file mask (for example, only for tests or only for migrations), called upon the request of the model or manually. Inside are the project conventions: which layer is responsible for what, what is prohibited to use, what to name, where to put a new file.
The rules are committed along with the code, so the entire team gets the same helper behavior. Early format - one file .cursorrules is fundamentally still supported, but it is more convenient to keep the new rules separate by topic.
Models and external tools
Model selectable from a list in the interface, including a longer think mode for complex tasks. There is support MCP: connection of external systems - tracker, database, documentation - is described by the config in the project, after which the agent calls them as normal tools.
Useful scripts
- Mechanical editing throughout the entire file under dictation: changing the style of error handling, moving repetitions into a function, parsing a long method into parts.
- First dive into someone else's project: questions to the index instead of manually traversing the file tree.
- Framework of the new feature: the agent creates files according to the structure adopted in the project, because the structure is described in the rules.
- Tests on existing code, running directly in the editor's terminal and fixing those that failed.
- Analysis of the error directly from the terminal: the command output is sent to the chat as a link, without copying it to the browser.
- Editing the layout, when the result is visible in the next browser window - the “change, look” cycle is shorter than in the terminal agent.
Limitations
The code goes to the side. Indexation and queries send the contents of files to the service servers. For projects under NDA and for regulated industries, this is a separate approval, and not a tick in the settings. .cursorignore must be filled out before the project is first opened, otherwise the secrets will be gone before anyone remembers about the exceptions.
The fork lags behind the upstream. VS Code updates arrive with a delay. Some Microsoft extensions are not available or are installed using workarounds - their license is tied to the official build. This hits stacks where the main tools are from Microsoft.
Tab teaches you to agree. The hint comes faster than critical reading can turn on. After a week, the habit of taking it without looking forms on its own. It is especially dangerous at boundary conditions: the suggested check looks correct, but checks the wrong field.
The review is getting heavier. The agent touches a dozen files in one go. Such a diff is less readable than your own, and responsibility for it remains with the author of the commit.
Monoturnip. On a large repository, indexing takes a long time and noticeably eats up machine resources. Without neat .cursorignore Assemblies, dependencies and unloads end up in the index, and the quality of the search decreases as a result.
Tariff limits. The subscription includes the volume of requests; beyond this, work becomes limited or requires additional payment. It won’t be possible to plan a budget by feeling - the cost depends on how long the tasks and large files go into the model.
Changing an editor is a team decision. Half a command in VS Code, half in Cursor means two sets of configs, two sets of extensions, and arguments about formatting.
How to check the result
See the list of sources above the answer. If the file you need is not there, the answer is based on a guess; The correct reaction is to add the file with an explicit link and ask again.
Check the indexing status in the project settings. A newly opened monorep responds poorly simply because the index has not yet been compiled.
Check exceptions by doing: open a file that should be hidden and make sure that no additions are received for it, and the chat does not quote it. Presence of a line in .cursorignore does not guarantee anything without such verification.
Accept agent edits in pieces, rather than using the “accept all” button. The “accept all” button exists for a file generated from scratch, not for editing a live module.
Test the rules with an experiment. A task is set that obviously violates the rule, and it is seen whether the model refuses. A rule that does not affect behavior is in the wrong folder or is formulated as a wish.
Measure not the number of accepted tips, but the number of returns from the review and the time until the green pipeline. The first metric always grows, the second shows real benefits.
Before committing, look at the diff in a separate git window, and not in the editor panel: there you can see what has accumulated over the entire session, including edits that have already been forgotten.
Rule: before accepting an edit, they check the list of files included in the context - an answer without the required file is always a guess.