Cursor Developer-Surface Mastery

A DX Engineer is the person developers expect to know every corner of the product cold. If a candidate fumbles the difference between ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. and a Cloud Agent, the room concludes they don't actually live in the tool they'd be paid to teach.

Your job is to teach what developers can build with Cursor's API, SDK, Plugins, Automations, CLI and coding agents. You cannot teach a surface you can't place. Before any interview, you should be able to draw the whole map from memory and say, for any teaching scenario, which surface you'd reach for and why.

Group the surface into three layers. The editor is where most developers meet Cursor, the headless layer is where it runs without a human watching and the programmable layer is where you call the same harness from your own code.

Compile 2026 adds three adjacent surfaces a DX Engineer should be able to place without overclaiming: Origin as source hosting and review infrastructure, larger from-scratch model training as roadmap context and Cursor Mobile as away-from-desk agent supervision. They do not replace the core three-layer product map; they explain where the map is expanding.

Three layers of the developer surfacethe whole map

Extensibility cuts across all three

Every layer can be extended with the same primitives, which is what makes the system coherent rather than a pile of features.

The mapping itself is a DX skill. When a developer asks how to do something, picking the right surface is half the answer.

Cursor 3 ('Glass'): the agent window is the default surfaceoutput to outcome

The framing that dates a candidate fastest: a year ago Cursor's core was three things - Tab, indexing and chat. The current product is an end-to-end SDLC control plane, and the most-recent top-level surface is Cursor 3Cursor's agent-forward interface (also called the agent window or Glass), built to run and supervise many agents at once rather than edit one file. (called Glass, or the agent's window), shipped roughly a month before the 2026 workshops. It is one abstraction level above the editor: it shows every workspace across local and cloud environments, multiple repos and archived/active agents, and it was redesigned ground-up to manage many parallel agents rather than to edit one file. You can still toggle back to the classic editor view (file tree left, code center, terminal bottom, agent pane right). The design rationale is the line worth memorizing: as models improved, attention shifted from the model's output (the exact code) to its outcome.

The single most common support question a DX Engineer fields is some version of "why isn't my rule firing?" Answering it cold, with the precedence and scoping in your head, is a fast credibility test.

Context configuration is how a developer teaches the agent their stack, conventions and constraints. Modern rules live in .cursor/rules/*.mdc: markdown bodies with a YAML frontmatter that controls when each rule applies. Version-controlled, file-scoped and conditional, they replace the older single-file approach.

The .mdc frontmatter that controls firingwhere rules go right or wrong

---
description: Conventions for files under src/api
globs:
  - "src/api/**/*.ts"
alwaysApply: false
---

# API conventions

- All handlers return a typed Result, never throw across the boundary.
- Validate input with the zod schema colocated next to the handler.
- Log with the request id from context, not a fresh one.

Cursor also reads fallback files so a repo can stay portable across tools. The legacy .cursorrules file still works and AGENTS.md is the cross-IDE standard rule file Cursor reads when present.

The 2026 config stack

Rules are one of several context inputs that stack and can conflict. A power user knows the order and can debug a clash.

1. 1Custom instructions. Your personal, account-level preferences that ride along on every project.
2. 2Skills (SKILL.md). Packaged how-to the agent pulls in when a task matches.
3. 3MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers. External tools and data sources the agent can call mid-task.
4. 4Rules / .cursorrules. Project conventions, scoped by globs or applied always.
5. 5AGENTS.md. The portable fallback rule file read across IDEs.

Reading about the SDK is worth nothing in a work-trial. You need one small automation you actually shipped, so you can speak from the friction of having built it.

The Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud., announced in April 2026, exposes the same runtime, harness and models that power Cursor, callable from TypeScript. You write code that drives an agent instead of clicking around an editor. Agents created this way get the full harness: codebase indexing, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers, skills, hooks and subagents.

SDK vs. CLI: when to teach eachtwo doors to the same harness

The CLI agent respects mcp.json and the .cursor/rules system, so editor and CLI behavior stay consistent. A developer's local conventions follow them into the terminal and into CI without re-specifying anything.

Ship one automation before the loop

The canonical DX use case is wiring a coding agent into CI/CDContinuous Integration / Continuous Delivery. The automated pipeline that builds, tests and ships code so changes reach production safely and often. or a script, then turning it into a reference automation with a write-up. Here is a minimal, honest path to one.

1. 1Pick a chore you actually do. Generating a changelog from merged PRs, triaging a failing test or drafting docs from a diff. Small and real beats clever and fake.
2. 2Wire the agent in. Call the SDK from a script or invoke the CLI agent in a CI job, pointing it at your repo so it indexes and reads your rules.
3. 3Constrain it. Give it a tight task, the relevant rules and any MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers it needs. Verify the output before trusting it on the next run.
4. 4Write it up. Show the trigger, the prompt, the harness config, one failure you hit and the fix. The write-up is the artifact a DX Engineer is hired to produce.

- name: Draft changelog from merged PRs
  run: |
    cursor-agent run \
      --prompt "Summarize the PRs merged since the last tag into a CHANGELOG entry. Follow .cursor/rules/changelog.mdc." \
      --output CHANGELOG_DRAFT.md
  # Reads mcp.json + .cursor/rules from the repo automatically.

The three invocation patterns and the runtime-agnostic interfacethe part candidates skip

The SDK is a single, runtime-agnostic interface: one set of code targets local, Cursor Cloud and self-hosted-cloud runtimes - you pass the runtime you want and the rest is identical. There are three core concepts (the agent object, the prompt interface and message/stream handling) and three invocation patterns worth naming explicitly because they map to different jobs.

It has full model neutrality (specify any model per agent), supports subagents (passed into agent.create) for context and token reuse, and lets you inject MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers, skills and hooks at runtime. It is TypeScript-first today, with Python on the roadmap; the fastest start is the built-in /sdk skill, which scaffolds working code, plus the SDK cookbook repo. A REST API exists as an alternative.

Anyone can describe MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. from the docs. A DX Engineer has set one up, watched it break and can name the pitfall a developer will hit on their first try.

The Model Context Protocol lets agents reach external tools and data beyond the codebase: a database, an issue tracker, internal APIs, a docs source. The CLI auto-detects and respects mcp.json, so a server configured once is available to the agent without per-run setup.

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@some/linear-mcp-server"],
      "env": { "LINEAR_API_KEY": "${LINEAR_API_KEY}" }
    }
  }
}

MCP vs. rule vs. skill: the judgment callthe teachable distinction

Developers conflate these constantly. Knowing which one fits a need is a judgment call you'll teach often, so make the distinction crisp.

Plugins package the rest for distribution

A pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. bundles subagents, skills, hooks and rules into one installable unit that works across both the IDE and the CLI. It is how a team ships a shared agent setup instead of asking everyone to hand-copy config.

• Bundle: a single pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. can carry all six primitives at once - rules, skills, sub-agents, commands, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers AND hooks - from multiple providers, so one install brings many capabilities.
• Portable: the same pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. applies in the editor and the CLI, so workflows stay identical across surfaces.
• Distributable: a team installs once and inherits the conventions, tools and procedures the author baked in; orgs can publish private team marketplaces from a manifest.
• Readable to learn: everything in a pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. except the MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server is visible, so browsing the marketplace is a great way to study well-written skills, sub-agents and hooks.

Hooks: the deterministic guardrail layerthe enterprise differentiator

Hooks are the one primitive that is not probabilistic: they are actual code that executes in the shell at lifecycle trigger points across the IDE and the CLI - roughly a dozen of them. They originated from enterprise customers' bespoke requirements (Cursor was perpetually catching up building everyone's features, so hooks let any user extend Cursor themselves), they are shareable across the team and agent types, and they also run in cloud agents.

Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. are the part of the surface that most reads as "the future of software engineering," which makes them the part an interviewer most wants to hear you reason about honestly.

Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. run in isolated cloud VMs with terminal and browser access and the June 2026 update added guided environment setup, reusable snapshots, .cursor/environment.json, /in-cloud subagents, /babysit and local/cloud handoff. They don't need your laptop open, but they still need a reviewable task and a checkable handoff.

What they enablethe longer horizon

The mechanic, the proof, and grind modesay these precisely

Three facts make the Cloud Agent story credible instead of hand-wavy. First, the mechanic: a cloud agent spins up a Cursor-managed VM with its own desktop and terminal, checks out the repo from connected source control, implements the work and opens a PR - then the VM is torn down, so the codebase doesn't persist long-term. It uses the same models and harness as the desktop (same quality), and it doesn't touch your local RAM or disk, so you can run as many as you want.

Third, grind-until-done (a.k.a. grind mode, in beta) is a toggle on long-running tasks that lets a cloud agent grind for hours - or as long as needed - on the very hardest work. The guardrail matters as much as the feature: most tasks don't need it; just toggling cloud on and asking "implement this feature" already does a very good job. Reserve grind mode for big migrations or building from scratch - real war stories include migrating Poetry to uv and a SQL v4-to-v5 upgrade, and a researcher building a Chrome-level browser across thousands of commits. Async cloud agents can run minutes, hours, days, or in some cases weeks on a long-horizon harness.

Teach the tradeoffs, not just the magic

The interesting DX conversation is where the human stays in the loop. More autonomy buys throughput and costs oversight and a credible teacher names that tension instead of selling pure automation.

The fastest way to fail a DX loop is to advocate a surface you've read about but never shipped on. This section turns that risk into a study plan.

Cursor's bar is that you're judged first as a serious engineer who is an elite power user of the product. Run an honest inventory against the surface before the loop and treat every gap as homework rather than something to bluff past.

The shipped-it checklisthave you actually built with each?

For each surface you've touched, the deeper test is whether you can explain its failure modes to a confused developer. Reach for the language fast or it's not yet yours.

Power-user yardsticks you can measure yourself againstnot vibes - numbers

"Elite power user" is fuzzy until you attach real yardsticks. Two from Cursor's own practitioners are concrete enough to self-grade against.

Both rest on dynamic context discoveryThe agent pulling only the relevant parts of files, tools and MCP servers into context as needed, instead of loading everything up front. - the agent pulls only what it deems relevant rather than loading every file and tool - which, combined with caching, is how the harness cuts agent tokens by roughly 47% even on other companies' models. Knowing why the yardsticks work is the difference between reciting them and teaching them.

The automation the JD literally asks for

The role asks you to build creative ways to automate your own work with agents and showcase them. One personal automation, shipped and written up, is the single most impactful thing you can carry into the loop.

• Pick a chore you genuinely repeat, then point an agent at it via the SDK or CLI.
• Write it up the way you'd publish it: trigger, harness config, one failure, the fix.
• Make it reproducible, so a developer reading along could run it. That reproducibility is the DX signal.