How Coding Agents Work (and Their Limits)

A coding agent is a language model wrapped in a loop that lets it act, look at what happened and try again - the model supplies the reasoning, the harness supplies the hands.

A DX Engineer at Cursor teaches this for a living, so the bar is being able to draw the loop on a whiteboard cold and narrate every arrow. Most developers picture an agent as a model that magically edits files. The honest picture is plainer and more useful.

Three pieces compose every coding agent: the model that decides, the harness that gives it tools and context and the tools it calls to change the world.

The loop, step by stepprompt → applied edit

An agent run is not one model call. It is a loop that keeps calling the model, feeding back what each action produced, until the task is done or a stop condition trips.

1. 1Assemble context. The harness gathers the prompt, retrieved code, open files, rules and the running conversation into the context window.
2. 2Plan / decide. The model reads that context and emits either a message, a plan or a structured tool call.
3. 3Call a tool. The harness executes the call - runs the command, applies the edit, searches the repo - in the real environment.
4. 4Observe. The tool's result (test output, file contents, an error) is appended to the context as the next observation.
5. 5Revise or finish. The model reads the observation and either takes another action or declares the task complete.

Ground that claim in what Cursor's harness actually does. It is not a thin desktop app piping your prompt straight to a model provider - there is deep proprietary cloud infrastructure (the Cursor harnessCursor's hosted layer around each model (context selection, caching, retries) that makes the same model run better and cheaper than calling it directly.) doing optimization, context enrichment, caching and compaction around the model, with a model-specific harness tuned per frontier model. Two concrete proof points to keep on hand: independent analysis shows the same model (e.g. Claude) performs better inside the Cursor harness than in other harnesses, and 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. (since v2.4) - where the agent reads from files/tools/MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. and pulls into the window only what it deems relevant - combined with caching cuts agent tokens by roughly 47% even when running other companies' models.

The autonomy spectrum

Cursor's surfaces are not three names for the same thing. They sit at different points on how much the agent decides versus how much you steer and teaching developers to pick the right one for the task is pure DX.

The model only knows what made it into the context window - and the context window is small, expensive and curated by the harness, not by your whole repo.

This one mechanism explains the single most common developer complaint about coding agents: why didn't it use my other file? Teaching it well retires a whole category of support questions, which is direct DX value.

Why you can't just dump the repo

A serious codebase is millions of tokens. A context window is a few hundred thousand at best and every token costs latency and money. So the agent can never see everything and pretending otherwise is the root of the confusion.

Index, then retrievehow the slice gets chosen

Cursor builds an index of your codebase so it can find relevant code fast, then retrieves a curated slice into the context at request time. Two distinct stages and conflating them is a common teaching mistake.

1. 1Index (ahead of time). The codebase is chunked and embedded so semantically related code can be looked up quickly. This happens in the background, not on every keystroke.
2. 2Retrieve (per request). When you ask for something, the harness searches the index plus signals like open files and recent edits to assemble the most relevant snippets.
3. 3Assemble. The retrieved slice, your prompt, the active file and any rules are packed into the context window the model actually reads.
4. 4Generate. The model reasons over only that slice - anything not retrieved is invisible to it, full stop.

What indexing actually stores (the privacy answer)

Be precise about the mechanic, because it doubles as the most-cited security reassurance. On first open Cursor chunks the repo into functions/pieces and generates vector embeddings; the embeddings are hashed and stored, but the raw code is held only ephemerally and then deleted - the long-term store is just the vector DB. At prompt time, semantic search pulls the most relevant chunks into context. A .cursorignore file specifies files Cursor should never index or view, the control surface for sensitive code.

How rules and AGENTS.md shape the slice

Retrieval is automatic, but you are not powerless over it. Cursor gives developers explicit levers to bias what lands in context and a DX Engineer should be able to teach when to reach for each.

Tool calling is what lets a text model touch reality - run a command, edit a file, query a database, hit an API - by emitting a structured request the harness executes and feeds back.

Without tools, a model can only describe a fix. With tools, it can apply the fix, run the tests, read the failure and try again. This is the mechanism behind every agent demo a DX Engineer will ever ship.

How a tool call actually works

The model doesn't run anything itself. It emits a structured call against a tool the harness advertised and the harness runs it and returns the result.

{
  "name": "run_terminal",
  "description": "Run a shell command in the project root and return stdout/stderr.",
  "input_schema": {
    "type": "object",
    "properties": {
      "command": { "type": "string", "description": "The exact command to run." }
    },
    "required": ["command"]
  }
}

// The model emits a call:
//   run_terminal({ command: "npm test" })
// The harness executes it, captures output and appends the result
// to the context as the next observation the model reads.

The model's reach into the world is exactly the set of tools the harness defines. Built-in tools cover files, search and the terminal. MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. is how you extend that set beyond Cursor's defaults.

MCP: one protocol, many systemsModel Context Protocol

MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. is an open standard for exposing tools and data to an agent. Instead of every system inventing its own integration, a tool author writes one MCP server and any MCP-aware agent can call it.

Sub-agents: parallel tools with isolated contextthe file-handoff mechanic

The other way an agent acts beyond text is by spawning sub-agents (shipped in Cursor 2.5). A parent agent runs smaller agents simultaneously for parallelizable, independent subtasks - each with its own context window. The mechanic that makes this efficient: each sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. writes its findings to a file, and the parent reads the file and pulls in only what's relevant, so the parent's window fills slowly. In one demo the parent used only ~16% of its window to spin up two sub-agents and summarize. This also solves the old multi-tab collision problem, where two agents editing the same file would block each other.

The human-in-the-loop boundary

Cursor doesn't auto-apply everything silently. It asks before some actions and shows diffs you accept. Frame that as a design decision, not a weakness - because the honest version is the more persuasive one.

The fastest way to lose a developer's trust is to oversell. The fastest way to earn it is to name the failure modes plainly and then teach how to prompt around them.

Truth-seeking is a stated Cursor value and for a DX Engineer it's also a distribution strategy - developers can smell marketing and naming a real failure mode is what makes the rest of your content credible.

The failure modes you should be able to name cold

Two groups of models, two jobsmatch the model to the task

Before you can reason about which model is best, sort them by what they're for. The cleanest mental model splits the field into two groups. One group is async and high-reasoning - highly intelligent, strong at long-horizon work, more costly - the models you reach for when you're planning, auditing or running plan mode. The other group is fast synchronous executors: near-frontier intelligence at much higher speed, the implementers that do the work once a plan exists.

The practical rule: don't ask "which model is best" in the abstract, ask "best at what." Use a high-reasoning model to produce the plan, then hand the implementation to a fast executor. When you don't want to choose, Auto modeA router that reads your prompt and picks a model for you, defaulting to Composer; you steer it with cues like "quickly" or "carefully". routes the model per task. This pairs with the failure-mode work above - a wrong-tier choice (a fast executor asked to do deep planning) shows up as the over-eager or runaway behavior in the table.

Why evals are essential and genuinely hard

An eval is how you know whether a change made the agent better or just different. For coding, that's harder than it sounds, because the task is open-ended - there are many correct programs and 'correct' often means 'passes tests a human would accept,' which is expensive to define at scale.

• Open-ended tasks have no single right answer, so exact-match scoring fails and you need behavioral checks (does it compile, do the tests pass, does a grader prefer it).
• Real codebases are messy and stateful; a benchmark that runs in a clean sandbox may not predict behavior in a million-line repo.
• Good evals are expensive to build and maintain and a stale or contaminated eval quietly lies to you about progress.

CursorBench: a real eval to anchor the conversationperformance AND token efficiency

When the eval discussion gets abstract, ground it in a named, real benchmark: Cursor built its own, CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone., which tests performance and token efficiency together - reflecting the market's shift toward price and efficiency, not just raw capability. The headline efficiency metric is "tokens per $100 spent." Concrete readings to cite: on CursorBench, GPT 5.4 has the best performance and sits mid-range on token spend, while lower-effort GPT 5.3 Codex variants use far fewer tokens at slightly lower performance (Codex 5.3 is highlighted as very token-efficient and coding-specific; Opus 4.6 is well-liked but pricier).

Turn a failure into an artifact

The most useful DX move is to take a known failure mode and ship the workaround as content. A 'lost-in-the-middle' bug becomes a short post on structuring long prompts. A runaway loop becomes a guide on stop conditions and verification.

1. 1Reproduce it. Get a clean, minimal case of the failure that a reader can run.
2. 2Explain the cause. Tie it back to a real mechanism - context limits, retrieval, tool design - not vague 'AI is unreliable.'
3. 3Show the fix. Give the exact prompt, rule or tool change that works and show the before/after.
4. 4Ship it. A post or a doc that turns a papercut into a repeatable technique is content that spreads because it's useful.

The job description wants opinions, not neutrality - but credibility with developers comes from fair, specific comparisons, not from trash-talking the competition.

A DX Engineer is the public face of Cursor's take on the space, so you need a defensible map of the landscape and a real point of view about where it's heading. Developers will fact-check you, so accuracy is non-negotiable.

The landscape, briefly

Where Cursor differentiatesspecific, not slogans

Have a take on where it's going

The role rewards a distinctive, evidenced point of view. You don't need to be right about the future - you need a thesis you can defend with first-hand evidence and update when the evidence changes.

• Pick a thesis you actually believe - for example, that more work shifts to background agents reviewed as diffs or that the editor stays central because verification needs a human-readable surface.
• Ground it in something you've used and observed, not in a tweet you skimmed.
• State the conditions that would change your mind; truth-seekers hold opinions loosely and update in public.