Cursor IDE: The AI Code Editor

What this page was checked against

Cursor 3.x line; feature names checked against Cursor’s docs on 28 August 2026. For current models and prices see the models hub; for releases see the Cursor changelog.

Cursor is an AI code editor built on VS Code. Its agent plans, edits across files, runs terminal commands, and prepares pull requests, on your machine or as Cloud Agents in cloud VMs. This Cursor overview routes developers and tech leads to the right guide and shows how one change reaches a merged pull request with evidence.

You asked the agent for a fix, it touched 11 files, and the pull request now waits for you to read every line. Cursor made writing the change fast; this guide is about making trusting it fast too.

Which Cursor surface fits the task?

Pick the smallest surface that can finish the job: every step up in autonomy needs a stronger check at the end.

Surface	Use it when	Prove the output with	Guide
Tab completion and inline edit	You know the change and want it typed faster	A quick read of a few lines, then the type checker	Tab completion, inline edit
Agent, local	The change spans several files and you can state the acceptance test	Tests and lint the agent runs, then CI	Agent workflows
Plan Mode	The change is risky or unclear	You review the plan, not the code	Agent modes
Worktrees	You want parallel attempts, each in its own Git checkout	Each attempt’s own test run; you compare results	Checkpoints and branching; see also the Agents Window guide
Cloud Agents and Automations	Work starts without you: from an issue, a schedule, or an event	Required CI and review on the pull request	Cloud Agents and Automations
Bugbot and PR Routing & Approval	Review should start before a human opens the diff	Bugbot’s comments plus your approval rules; a human owns the merge	Bugbot, PR Routing & Approval

Plan Mode “creates detailed implementation plans before writing any code”, and worktrees “let Agent work in isolated Git checkouts” (Cursor docs, checked 28 August 2026). Keep project conventions in Cursor’s Rules, reusable procedures in Agent Skills, and external systems behind MCP servers, so prompts stay short.

Run one change from plan to pull request

This is the Cursor version of the tool-independent AI-native lifecycle. Each stage’s artifact is stored as docs/<kind>/FEATURE.md.

Prerequisites: a Git repository with a clean working tree, Cursor signed in, the real test, lint, and type-check commands in a project rule, and an intent and a spec for the change in docs/intents/FEATURE.md and docs/specs/FEATURE.md (see Capture intent and Write the spec).

1. Switch the agent to Plan Mode and paste the planning prompt below. The prompt tells the agent not to edit any file.

2. Save the plan to docs/plans/FEATURE.md (paste it in, or tell the agent “write the accepted plan to docs/plans/FEATURE.md and nothing else”), cut anything you did not ask for, and commit it.

3. Start the implementation in a worktree so a failed attempt never touches your main checkout. Create one on a new branch in your terminal, open that folder in Cursor, and install dependencies there:

   git worktree add -b FEATURE ../FEATURE_CHECKOUT

   FEATURE_CHECKOUT is a new folder beside your repository. Cursor can also create worktrees for its agents; see checkpoints and branching. Confirm the checkout exists:

   git worktree list

4. Paste the implementation prompt below into the agent in that worktree.

5. Open the pull request. Let CI and Bugbot run before a human looks, then merge on the evidence below.

Copy-paste prompt: plan before editing

Read docs/intents/FEATURE.md and docs/specs/FEATURE.md, then inspect the code they touch.
Do not edit any file. Propose an ordered plan in milestones. For each milestone list:
the files it changes, the test that will prove it (name the test file and the behaviour
it asserts), the risk, and how to roll it back. End with open questions I must answer
before you start. Flag anything in the spec that the current code contradicts.

In both prompts, replace FEATURE with the feature’s slug.

Copy-paste prompt: implement one milestone with proof

Implement only milestone 1 of docs/plans/FEATURE.md, following the project rules.
Write or update the tests for the milestone first and show them failing.
Then implement until the project's type check, lint, and full test suite pass.
Do not delete, skip, or weaken an existing test or assertion to get to green; if one
looks wrong, stop and tell me why. Finish with: changed files, every command you ran
with its exit code, and any risk you could not test.

How do you trust a Cursor change without reading every line?

Move the checking from your eyes to gates that run on every change. The evidence bundle defines what a pull request must carry; in Cursor it comes from four sources:

• Tests written first. The agent shows a failing test before the fix, so green means the behaviour changed.
• Machine gates in CI. Type check, lint, and tests are required status checks. The agent’s run is a preview; CI is the record.
• Review before a human. Bugbot “reviews pull requests and identifies bugs, security issues, and code quality problems” (Cursor docs, checked 28 August 2026). PR Routing & Approval assigns reviewers by code ownership and can approve low-risk pull requests that meet your criteria.
• A named human sign-off. Merges to protected branches need a named approver, who reads the plan, test names, and CI result and opens the diff only where evidence is thin.

The full argument is in reading evidence instead of code.

What breaks when you start with Cursor?

The agent turns a red test green by changing the test. Recovery: reject the change, restore the test from Git, and rerun with the implementation prompt, which forbids it. Put the same ban in a project rule.

Unattended terminal commands reach something destructive. Recovery: review the agent’s Run modes settings (Cursor’s Agent security docs) before commands run without asking, and keep deploy, migration, and data-deleting scripts out of anything auto-approved.

The agent’s edits cannot be cleanly undone. Do not rely on the editor’s undo history or checkpoints alone: commit before a large agent task so Git holds a restore point you control.

Where to go next in the Cursor guide

New to Cursor? Start with the quick start, then the developer track. Leading a team? Read Cursor for teams.

Plan Turn an idea into an intent, a spec, and an accepted plan.

Build Agent, inline edit, worktrees, and large-codebase work.

Test and debug Test-first agent loops and bug hunting.

Review and ship Bugbot, approval rules, CI, and release.

Operate Security, monitoring, and token use in production.

Automate Cloud Agents, Automations, custom MCP servers, and the SDK.

Team and enterprise Shared rules, privacy, and rollout across a team.

Reference Changelog, keyboard shortcuts, and upgrade guides.

The same lifecycle runs in Claude Code and Codex; the power-user tips cover all three.