Cursor's agent edits first and asks for review afterwards

A living page, not a launch date

Cursor is an AI-assisted code editor. Its own documentation and changelog change often enough that neither is a fixed record, so what follows describes those pages as they read on 16 September 2026, not a single launch date. The changelog's recent entries describe a 'Projects' feature, added in September 2026, built around a 'coordinator agent' that, in the vendor's words, 'plans the work, delegates it to agents that implement it, and brings the finished work back to you to check'. Even as Cursor adds autonomous machinery, its own description keeps a human checking step in the sentence.

How the editor finds and edits code

The documentation on codebase indexing describes a custom search tool, 'Instant Grep', run 'automatically, no configuration needed'. File paths are said to be encrypted before reaching Cursor's servers, with code content 'never stored in plaintext' — the vendor's framing of trading repository context against sending code to a third party. The documentation on Tab describes an older, narrower feature: completions based on 'your recent edits, surrounding code, and linter errors', accepted with a keypress or dismissed by typing on. Tab suggests; a person still presses the key.

What Agent mode is documented to do

The documentation on Agent states it can 'complete complex coding tasks independently, run terminal commands, and edit code', using tools to search, read and edit files, run terminal commands, and browse or test in a browser — reach over a machine, not just a text file. No approval step sits inside that loop: changes and commands execute, and the safeguard offered is a 'checkpoint', created automatically before a significant change, letting a person inspect what happened afterwards and restore an earlier state. That is recovery, not a gate — review happens after the fact, at a point the developer chooses, not before each action.

Where the review still happens

Separate documentation on reviewing changes describes diffs a person can inspect and checks a person can run before merging work into a shared codebase — the point where a team's existing safeguards, tests and code review, still apply regardless of who or what wrote the change. That merge gate, run by ordinary engineering process rather than by Cursor, is where approval actually sits. Checkpoints handle an agent going wrong locally; they say nothing about a change that only looks wrong once it meets a codebase or production data. Because these are living documents, features named here may not have existed in an earlier version of the product, so a claim tied to one changelog entry should not describe the tool generally.

• Which actions does the agent take without pausing, and which does it queue for confirmation?
• What does a checkpoint restore, and does that cover anything outside the editor, such as a database?
• Does the team's existing review and test process still run on agent-written changes before production?

None of this makes an editor with an agent built in unusually risky. It means the point of human judgement has moved: away from typing each line, towards deciding what to check once the agent has already acted.