Cursor

Cursor is a commercial, AI-first development environment: a code editor, a terminal agent and cloud agents in one product. Its documentation describes a coding agent that reads a codebase, plans, builds, looks for bugs and reviews changes.

The category moved from autocomplete to agent workflows, so it is worth being clear about where a human still steps in.

How it is built

An agent rests on three components: instructions (the system prompt and the rules), tools (file editing, codebase search, terminal execution) and the model chosen for the task. Agent carries complex tasks through, Plan mode drafts a plan before any code, Ask mode is read-only, and Debug mode narrows bugs down with instrumentation. A Project starts a coordinator agent that delegates to subagents.

Where a task starts in the terminal, we reach for Codex or Claude Code; Cursor is our tool for work inside the editor.

Rules and context

Recurring expectations belong in rules, because a model keeps nothing between completions. Project rules live in .cursor/rules as .mdc files under version control and activate in four ways: always, from their description, by file pattern (globs) or by an explicit @ mention. AGENTS.md is a simpler alternative, user rules are global, team rules cover every repository, and the team rule wins a conflict.

A rule is a prompt, not an enforcement layer: the docs suggest short rules that point at examples instead of copying them, and say AI guidance should not be your only security control. Checkpoints give a local, file-level undo; they do not replace Git.

Tools, integrations and review

External capabilities arrive through the MCP standard over stdio, SSE or Streamable HTTP, configured in mcp.json or from the Customize page. MCP tools ask for approval by default, and run modes escalate: allowlisted calls run, the rest are sandboxed where possible, and a classifier decides the remainder.

Skills, subagents with their own context window and hooks from .cursor/hooks.json extend the loop; integrations cover GitHub, GitLab, Bitbucket, Azure DevOps, Slack and Linear. Bugbot reviews every pull request update, leaves comments with fix suggestions and publishes a CI status that is neutral by default, so findings do not block a merge on their own.

Cloud agents and the CLI

Cloud agents run in isolated virtual machines with a cloned repository and installed dependencies, not on our own machine. Several can work in parallel and they return artifacts: screenshots, videos, logs. The CLI takes the same model to the terminal, print mode for scripts and CI, resumable sessions, and a & prefix that hands a message to a cloud agent.

Strengths and limits

• A version-controlled rules system that fits engineering workflows.
• Open standards for tools, file-based knowledge for skills and AGENTS.md.
• Visible checkpoints: plan, checkpoint, diff, pull request review.
• The model decides: the same request lands differently per model.
• On large codebases it pulls in relevant parts instead of the whole repository, but long conversations still accumulate noise.
• By the documentation’s own account, agents are weaker at deep system debugging, unfamiliar libraries and pixel-exact design, and can get stuck in loops.
• Generated code can look right while being wrong, so the review stays ours.
• Permissions deserve a minimal allowlist, a sandbox where available, and fail-closed hooks.

Further reading

• Rules: rule types, glob patterns and what a good rule looks like.
• Cursor Agent: how the agent is built, checkpoints and modes.
• Best practices for coding with agents: planning, context management and verification in practice.

We use Cursor as the agent that works inside the editor: larger refactors land here, wrapped in a plan and a review.