Claude Code, Cursor, and Aider — three answers to the same question

You can tell a lot about a coding agent from the first ten seconds of using it. Open Cursor and you are inside an IDE — files in a sidebar, a Composer panel, an inline diff view. Type claude in a terminal and you are at a prompt, with the agent ready to read, write, and execute in your current working directory. Type aider and you are in a chat session that’s tracking a git repo, ready to commit every change as a discrete patch.

Three coding agents. Three completely different user surfaces. Three completely different architectures underneath. And — once you look at them with engineering eyes — three completely different bets about what the human–agent relationship actually is.

This is not a “which one is best” piece. The “best” answer depends on what you do for a living and where you spend your day. The interesting question is what design choice did each team refuse to compromise on, and what fell out from that refusal? That question explains why they each look the way they do, and why the architectures don’t converge even after two years of competing for the same users.

The shared problem

All three are answers to the same engineering problem: take a natural- language intent (“add a phone field to the user signup, including backend validation, the React form, and a database migration”) and turn it into a coherent multi-file change in a real codebase. They all need to solve:

File context. Which files does the agent see, and how much of each?
Edit application. How does it produce a diff, and how is that diff reviewed before it touches your working copy?
Tool use. What is the agent allowed to do — shell, browser, run tests, install packages?
Autonomy boundary. Where does the agent stop and ask the human?

Where they differ is the values they assigned to each of those knobs.

Same intent, three pipelines. The accent boxes mark the load-bearing piece each team invested in.

File context: index, agent-fetch, or repo-map

The first design decision: how does the agent know which files exist and which ones matter?

Cursor runs a background indexer that embeds the repo on open and re-embeds incrementally on save. Retrieval is dense and structure-aware — by the time you hit Composer, relevant chunks are pre-staged in milliseconds. The trade-off is that the indexer must keep up with your edits and that embeddings live somewhere (locally, with anonymised remote sync depending on settings).

Claude Code takes a different bet: let the model fetch what it needs. There is no background indexer. When a turn starts, the agent has access to Read, Glob, Grep, and Bash as tools. It uses them to find what it needs, the same way you would — Glob for files, Grep for symbols, Read for content. The pattern is documented in Anthropic’s Claude Code internals post.

This is slower per single lookup but far more transparent: every file the agent reads becomes a logged tool call. There is no opaque vector store and no embedding sync. The bet is that for a frontier model, “explore the repo like a human” produces better context selection than a fixed embedding index — because the model can iterate (“oh, the real definition is over in lib/, let me check there”) instead of trusting a single dense retrieval.

Aider sits in between with the repo map. On startup, Aider parses the repo’s source tree, extracts top-level definitions (function signatures, class names, important comments) via tree-sitter, ranks files by PageRank-style centrality, and ships the resulting compressed map as part of every system prompt. The model always sees the skeleton of the entire repo, even if it’s only editing two files. When the model wants a specific file’s contents, it asks (via Aider’s “add files to chat” mechanism).

The three approaches encode three beliefs:

Tool	Belief about context
Cursor	”Pre-stage retrieval; latency must feel instant.”
Claude Code	”Let the model decide what to read; transparency beats opacity.”
Aider	”Compress the structure of the repo into the system prompt; let the model ask for details.”

None of these is wrong. They’re answers to different latency and trust budgets.

Edit application: speculative, tool-call, or search-replace

The next dimension: how does an LLM-suggested change get into your actual files?

Cursor’s Apply Model is the most engineered: the planner emits terse hints, a smaller fine-tuned model converts those hints into exact diffs using the original file as a speculative draft. Multi-file edits land near-atomically. The diff is shown inline; you accept or reject per chunk.

Claude Code uses a much simpler primitive: an Edit tool that does exact string replacement, and a Write tool for whole-file rewrites. The model emits Edit(file, old_string, new_string) calls; the harness applies them; failures (e.g. old_string not unique) return errors that the model sees and retries. There is no separate “Apply Model” — the same frontier model that planned the change emits the edit directly, just in the structured form the harness understands.

The reason Claude Code can get away with this is that the structured tool format is itself the discipline. The model isn’t being asked to output a 600-line file verbatim. It’s being asked to output a small JSON object describing exactly which substring to replace. That format constrains the model in the same way Cursor’s hint-then-apply pipeline does, just at a different abstraction layer.

Aider uses a slightly different convention: the model emits search/replace blocks inside its response, which Aider parses out and applies. If the search text doesn’t match exactly, Aider reports the mismatch back to the model and asks for a corrected block. The protocol is plain text, human-readable, and works the same on every model Aider supports.

The contrast on edit reliability:

Cursor:        big plan → small fast apply → atomic diff
Claude Code:   big plan → structured Edit/Write tool → exact match
Aider:         big plan → search/replace block in chat → exact match

All three converge on the same insight that the Composer post hammers: don’t ask the model to output the whole file verbatim. Cursor solves this by having a separate small model do it; Claude Code and Aider solve it by structuring the model’s output so it never has to.

Tool authority: what is the agent allowed to do?

Cursor’s agentic surface lives inside the editor. The default tools are file edits, terminal commands (with prompts), and search. The boundary is “your repo, plus the terminal you’ve already authorised.” There is intentionally no built-in browser; the Composer agent stays close to the code.

Claude Code is the most powerful by default. It runs as a CLI in your shell, which means the shell is the tool. It can cd, git, npm, pytest, curl — anything a developer can type. With explicit permission, it can also run a headless browser, manage processes, or operate inside a Docker container. This is closer in spirit to Devin’s sandboxed shell but executed locally, which means the trust model matters more.

Anthropic addresses this with explicit permissions — bash commands require permission per pattern, sensitive paths can be blocked, and a configurable auto-approve allowlist lets users opt into fewer prompts. The design choice: maximum tool power, plus explicit trust boundaries you configure.

Aider is the most conservative. Its core tools are read, write, and git commit. It can be configured to run tests after each change (--auto-test) or lint, but its model of operation is “edit files, then propose a commit.” Browsers, package installs, multi-step shell workflows — these are out of scope by design. The constraint keeps Aider’s runs reproducible and reviewable.

Each tool’s default sits at a different point on the autonomy dial — none of them is at either extreme.

The autonomy boundary

This dial is the philosophical core. Each tool has a built-in answer to “where does the agent stop?”

Aider stops at every commit. The conversation ends each round with a proposed git commit; you read the diff and the message; you approve or amend. Aider is a pair programmer in the strict sense — every change is reviewed before it’s part of the repo.
Cursor Composer stops at every diff hunk. The model can produce a multi-file change, but you accept or reject each hunk before it becomes a file write. The autonomy is wider than Aider’s (multi-file, multi-step) but bounded by the diff review.
Claude Code stops only at “risky” tool calls (defined by the user’s permissions config) and at task completion. Within a turn, it can read, write, run tests, and iterate freely. The boundary is task-level, not change-level.

This is the same gradient you see in agentic systems generally. Aider is the conservative end of the spectrum, Claude Code is the assertive end, Cursor sits where most professional developers actually live — “trust the model with multi-file edits, but make me review them before they ship.”

Where each one wins

A useful framing: each tool wins decisively on the workflow it bet on.

Cursor wins when your work is inside a codebase, in an IDE, with incremental edits. Refactors. Adding features to existing files. Wiring up a new component across the React/server boundary. The indexer + planner + Apply Model pipeline is built for this and is hard to beat.

Claude Code wins when your work is around a codebase as much as inside it. Operational tasks: spinning up a new service, debugging a production failure that requires kubectl and psql, writing a script that reaches across five tools. The shell-native tool model is the right shape for tasks that need to touch the world.

Aider wins when you want zero magic. Open-source tooling, full local model support (it works with any OpenAI-compatible API), every change is a git commit, every interaction is in plain text. If you want to keep your full history of agentic changes in git log, this is the design that gives you that for free.

Where the architectures might converge — and where they won’t

After two years of the three tools competing, the convergences and divergences are starting to look stable.

Converging:

All three now expect a project-level configuration file (.cursorrules, CLAUDE.md, .aider.conf.yml). Durable user-edited guidance has become a first-class part of the architecture, exactly as in Devin’s Knowledge layer.
All three have moved away from “model writes the whole file” toward structured edit operations. The protocols differ but the principle doesn’t.
All three log every action in a form the user can replay. Cursor’s Composer history, Claude Code’s transcripts, Aider’s git log all serve the same role.

Not converging:

Context strategy is a deep architectural choice and won’t merge. Cursor will keep investing in its indexer; Claude Code will keep betting on agent-fetch; Aider will keep refining the repo map. Each is right for the workflow it serves.
Tool authority is a values question, not just a feature question. Anthropic’s stance on Claude Code’s permissions reflects a specific view of agent trust; Aider’s stance reflects a different one. Neither team is going to abandon their position.
Surface — IDE / terminal / git — is what determines who the user even is. The tools serve overlapping but distinct populations.

What to take away

Coding agents are architectural systems, not products with feature matrices. Compare them by where the load-bearing engineering sits, not by whose UI is prettier.
Context strategy is destiny. How an agent decides what to read shapes everything else about it. A good index is not strictly better than a good agent-fetch loop; they are different bets with different trade-offs.
The autonomy dial is a deliberate setting. Aider’s “approve every commit” is not a limitation, it’s a stance. Same for Claude Code’s task-level autonomy. Both are correct for their context.
Structured edit protocols are the universal pattern. Three teams arrived at three different formats, but the underlying insight is the same: don’t let the model output the whole file.

If you’re picking between them, pick by your workflow. If you’re designing your own coding agent — and a lot of teams are, right now — the more important question is not “which one am I copying?” but “which of these design choices match the assumptions I’m willing to defend?” The teams that picked clearly and committed are the ones that shipped products with personalities. The teams that hedged ended up with feature-rich tools nobody loves.

Further reading: Anthropic’s Claude Code engineering posts, the Cursor instant-apply post, and Aider’s repo map docs are the primary sources. For a longer view, the aider GitHub repo is the most readable open-source coding agent in production today.