# Cursor IDE: The AI Code Editor

URL: https://developertoolkit.ai/en/cursor-ide/
Description: Start here for Cursor: which surface fits which task, how a change moves from plan to merged pull request, and how to prove it works without reading every diff.

**What this page was checked against**

  Cursor 3.x line; the current release on 2026-10-12 is Cursor 3.24 (2026-10-09, Cursor's release notes). Cursor lists four agent modes (Agent, Ask, Plan and Debug) and three run modes (Auto-review, Allowlist and Run Everything), and Cursor's help says of long-running background agents, "In Cursor, we call these Cloud Agents" (checked 2026-10-12). Feature names for Plan Mode, worktrees and Bugbot were checked against Cursor's docs on 28 August 2026. For current models and prices see the [models hub](/en/ecosystem/models/); for releases see the [Cursor changelog](/en/cursor-ide/reference/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](/en/cursor-ide/build/tab-autocomplete/), [inline edit](/en/cursor-ide/build/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](/en/cursor-ide/build/agent-chat/) |
| Plan Mode | The change is risky or unclear | You review the plan, not the code | [Agent modes](/en/cursor-ide/build/agent-modes-deep-dive/) |
| Worktrees | You want parallel attempts, each in its own Git checkout | Each attempt's own test run; you compare results | [Checkpoints and branching](/en/cursor-ide/build/checkpoints-branching/); see also the [Agents Window guide](/en/cursor-ide/build/agents-window/) |
| 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](/en/cursor-ide/automate/cloud-agents-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](/en/cursor-ide/ship/bugbot/), [PR Routing & Approval](/en/cursor-ide/ship/rollouts-and-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](/en/cursor-ide/quick-start/project-rules/), reusable procedures in [Agent Skills](/en/ecosystem/skills/), and external systems behind [MCP servers](/en/cursor-ide/quick-start/mcp-setup/), so prompts stay short.

## Run one change from plan to pull request

This is the Cursor version of the tool-independent [AI-native lifecycle](/en/method/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](/en/method/lifecycle/plan/) and [Write the spec](/en/method/lifecycle/design/)).

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:

   ```bash
   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](/en/cursor-ide/build/checkpoints-branching/). Confirm the checkout exists:

   ```bash
   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**

```text
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**

```text
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](/en/workflows/ship/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](/en/ladder/evidence-not-diffs/).

## 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: check the agent's run mode (Auto-review, Allowlist or Run Everything, under **Settings > Agents > Approvals & Execution**; Cursor's Agent security docs, checked 2026-10-12) before commands run without asking, and keep deploy, migration, and data-deleting scripts out of anything auto-approved. Run Everything is the mode where "Every tool call runs automatically."

**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](/en/cursor-ide/quick-start/), then the [developer track](/en/start/developer/). Leading a team? Read [Cursor for teams](/en/cursor-ide/team/).

- [Plan](/en/cursor-ide/plan/) — Turn an idea into an intent, a spec, and an accepted plan.
- [Build](/en/cursor-ide/build/) — Agent, inline edit, worktrees, and large-codebase work.
- [Test and debug](/en/cursor-ide/test/) — Test-first agent loops and bug hunting.
- [Review and ship](/en/cursor-ide/ship/) — Bugbot, approval rules, CI, and release.
- [Operate](/en/cursor-ide/operate/) — Security, monitoring, and token use in production.
- [Automate](/en/cursor-ide/automate/) — Cloud Agents, Automations, custom MCP servers, and the SDK.
- [Team and enterprise](/en/cursor-ide/team/) — Shared rules, privacy, and rollout across a team.
- [Reference](/en/cursor-ide/reference/) — Changelog, keyboard shortcuts, and upgrade guides.

The same lifecycle runs in [Claude Code](/en/claude-code/) and [Codex](/en/codex/); the [power-user tips](/en/start/power-user-tips/) cover all three.