AI coding harnesses: how they work, and how the leading ones actually differ

What a coding harness actually does, where the leading agents (Claude Code, Cursor, Cline, Aider, Devin, others) differ, and how to pick between them.

Two engineers can be using the same Claude Opus 4.7 and have completely different experiences. One sits in a terminal approving each tool call before it fires. The other clicks “run” on an autonomous agent and goes to lunch while it ships a PR. The model is identical. The product they’re using is not.

The model is the engine. The harness — the scaffolding around it that handles tool calls, file edits, memory, permission gating, context management, and the loop that keeps the whole thing running until the task is done — is everything else. And the harness is what you’re actually using.

Most of the discourse about AI coding lives at the model level: “I tried Opus 4.7 and it’s great” or “GPT-5.4 is finally usable for this.” That framing leaks. The model produces tokens. The harness decides what those tokens can do, what files they can touch, when they fire off subagents, what they remember from yesterday, and what gets blocked at the prompt boundary. Same model, three harnesses, three completely different products.

This primer is a field guide to the harness layer: what every coding harness does under the hood, the dimensions where the leading harnesses actually differ in 2026, and the places they’re more alike than the marketing suggests. By the end you should be able to read an announcement about a new agent and place it on the map — instead of squinting at the demo gif trying to figure out whether it’s “like Cursor” or “like Devin.”

This is the anchor orientation primer for the Coding Agents track. If you’re new to the category and want one overview before diving into specific tools, read this first.

What a harness actually is

A harness is the scaffolding that turns a language model from a function call into an agent.

The model itself does exactly one thing: given a context, predict the next tokens, optionally with structured tool-call requests sprinkled in. That’s it. Everything else — reading files, running shells, opening browsers, remembering yesterday’s session, spawning a subagent, refusing to delete the database — is the harness.

The bare minimum a coding harness has to do:

Assemble a system prompt. Who is the agent, what tools does it have, what’s the project context, what’s the conversation so far. Every harness has its own opinionated version.
Mediate tool use. When the model says “I want to run git push --force,” the harness decides whether to ask the user, run it, or refuse.
Stream and parse output. Take the model’s token stream, interleave it with tool calls and tool results, and present something coherent.
Manage the context window. Add what’s needed, drop what’s not, compact when the budget runs out.
Loop until done. Coding tasks are multi-turn. The harness keeps calling the model with updated context until the model says it’s finished — or you stop it.

The leading harnesses all do those five things. The differences are in how they do them, and how far past the baseline each one goes.

The anatomy of a single turn

What actually happens between you hitting Enter and your file changing on disk:

You submit a prompt. “Fix the failing test in auth.spec.ts.”
The harness assembles context. System prompt + project rules (CLAUDE.md, .cursorrules, AGENTS.md, whatever the harness reads) + memory + conversation history + your new prompt. Some harnesses pre-index your repo and stuff retrieved chunks in here. Others wait for the model to ask.
The harness calls the model API. With the assembled context and a list of available tools (Read, Write, Bash, Glob, Grep, MCP servers you’ve configured).
The model streams tokens back. Mixed prose (“Let me look at the test first”) and structured tool-call requests (Read("auth.spec.ts")).
The harness intercepts each tool call. Is this allowed by the permission rules? Does it need a user prompt? Run it; collect the result.
Loop. Push the tool results back into context; call the model again. Maybe it now wants to read auth.ts. Maybe it wants to edit. Maybe it’s done and reports “tests pass.”
Stop condition. The model emits no more tool calls, hits a max-turns budget, or you interrupt it.

That loop is the heart of every coding harness shipping in 2026. The hard, interesting, product-shaped decisions are everywhere around it.

The seven dimensions where harnesses actually differ

Pick any two leading harnesses and they’ll occupy different points on each of these seven axes. Together the axes explain most of why the harnesses feel different in daily use, even when they’re calling into the same model.

1. Interface and venue

Where do you run it, and how does it sit alongside your existing tools?

CLI-native — Claude Code, Codex CLI, Aider, Goose. Lives in the terminal. Doesn’t care which editor you use. Best fit if you already keep a terminal open all day.
IDE-embedded — Cursor, Windsurf, Cline, Continue, Roo Code, Copilot’s agent mode. Lives inside the editor as a side panel, an inline diff view, or an autocomplete that happens to call tools. Best fit if you do everything in VS Code or a fork.
Autonomous / remote — Devin, OpenHands, Codex Web. Runs in its own sandbox or virtual desktop. You hand it tasks and check back later.
Hybrid desktop — Amp, Zed’s agent panel. A polished desktop app that bundles editor and agent into one product.

The dirty truth: most professional developers in 2026 now use two harnesses concurrently. The most common pairing is Cursor (inline edits, refactors-in-place) plus Claude Code in a terminal (autonomous side quests, long-running tasks). The “which harness” debate often resolves to “yes, both.”

2. Context strategy

The hardest problem every harness has to solve is “what goes in the prompt?” There are two philosophies and a hybrid.

Index up front — Cursor, Continue, Amp. On project open, the harness embeds your codebase into a vector store. When you ask a question, it retrieves the relevant chunks and stuffs them into context. Pros: fast queries, can surface files the model wouldn’t have thought to look for. Cons: indexes go stale; semantic search misses things; the model rarely sees whole files.
Load on demand — Claude Code, Aider, Codex CLI. No index. The model uses grep, glob, and read tools to navigate the repo, exactly like a human would. Pros: always fresh, sees the actual file contents, no retrieval artifacts. Cons: slower per query; the model can miss something it didn’t think to look for.
Hybrid retrieval — increasingly Cursor’s agent mode, Amp, Cline’s larger workspace mode. Index for first-pass relevance, then on-demand reads for the files the model actually wants to operate on.

The trend through 2025–2026 has been toward load-on-demand for agentic (multi-turn) work. Indexes are great for “what file is this concept in?” They struggle with “the model needs to write code that’s correct given the current state of these three files.” Index hits are stale by definition; the file on disk is not.

3. Permission and autonomy model

How much friction sits between the model deciding to do something and that something actually happening?

Approve each tool call — Claude Code’s default, Cline’s default. Every Bash command and every file edit pops a confirmation. High friction, high safety. Usable because most harnesses let you whitelist categories (“yes to all reads,” “ask for writes,” “always ask for Bash”).
Allowlist mode — Claude Code’s permissions config, Cline’s auto-approve patterns. Pre-approve patterns you trust (e.g. Bash(npm run test:*)) and prompt only for unmatched calls.
Bypass dangerous — Claude Code’s --dangerously-skip-permissions, “YOLO mode” in various forks. Approve everything. Useful in disposable environments (fresh container, scratch branch) and dangerous everywhere else.
Fully autonomous — Devin, OpenHands. The agent runs in a sandbox where you don’t get tool-by-tool approvals at all. You set it loose, it works for hours, you review the final PR.
OS-level sandboxing — Codex CLI’s posture. Instead of asking the user per-tool, the harness relies on OS-level isolation (Seatbelt on macOS, Landlock on Linux) to bound what the model can damage. Trade tool-level prompts for environment-level fences.

The autonomy slider is where most of the safety story lives. The reason Claude Code shipped approve-each-tool as the default in 2025 wasn’t paternalism; it’s that an agent with sudo and no friction can do real damage in seconds. The trade is real and live; every harness picks a default and lets you turn the knob.

For the deeper version of this, see Judgment is not a security boundary.

4. Memory and persistence

What does the harness remember from yesterday, last week, last project?

Per-repo project files — CLAUDE.md, .cursorrules, AGENTS.md, .clinerules, .github/copilot-instructions.md. Version-controlled, shared with the team, lives next to the code. Lowest-friction memory mechanism; every major harness supports some form of it.
True cross-session memory — Claude Code’s auto-memory, Cursor’s user memory. Persistent facts the agent remembers across sessions and projects, stored outside the repo.
External memory via MCP — cavemem, mem0, custom Postgres servers. Externalize memory into an MCP server you can wire into multiple harnesses; cross-harness persistence in principle.
Session-only — Aider out of the box, vanilla Codex CLI. Each session starts blank. You manage context with /clear and your own conversation logs.

Project rules files are the universal substrate — almost every team standardizes on at least one (usually CLAUDE.md or .cursorrules). Cross-session memory is the newer differentiator, and the next axis of competition is portability: does my memory work when I switch from Claude Code to Cursor? Today, mostly no, except via shared MCP memory servers.

5. Tool primitives

What can the model actually do?

The 2026 baseline is unified across credible harnesses:

Read a file
Write or edit a file
Run a shell command
Glob and grep the project
Fetch a URL

Differentiation lives above the baseline:

Subagents — Claude Code’s Agent tool, OpenHands’s microagents. Fork off a sub-instance with a narrower task; receive back a summary, discard the verbose internal transcript. Context-isolation as a primitive.
Plan tracking — Claude Code’s TaskCreate/TaskList, Cursor’s agent-mode checklists, Aider’s chat-history files. Structured to-do tracking as part of a task.
Browser control — Cursor’s web search, Claude for Chrome, Browser Use, Stagehand. Open a browser; click; read pages; fill forms.
Computer use — Claude’s Computer Use models, Devin’s virtual desktop. Operate a whole desktop GUI, not just a browser.
MCP servers — Claude Code, Cursor, Cline, Codex CLI, Windsurf, Zed, Goose, Continue. Pluggable external tools via the Model Context Protocol.

MCP has been a quiet equalizer. Two years ago “which harness has the GitHub integration” determined product choice. In 2026 you wire an MCP server in and any harness that speaks the protocol gets the same capability. If you’ve never installed an MCP server, start with MCP in 20 minutes.

6. Diff strategy

How does the model actually change code?

Whole-file rewrite — Claude Code’s Write tool, Cursor’s composer in some modes. The model emits the entire new contents of the file; the harness writes it. Simple and robust; each edit ships a lot of tokens for a small change.
String-replace / surgical edit — Claude Code’s Edit tool, Cline’s diff blocks. The model emits “find this string, replace it with that string.” Fast, cheap, more brittle if the model misremembers exact whitespace.
Diff hunks — Aider’s default, Codex CLI in some modes. The model emits unified diff format — the same thing git diff produces. Pleasant to review, but the model has to line-number well, and not all models do.
Inline cursor edit — Cursor’s ⌘K, Copilot inline edits, Cline’s inline mode, Zed’s inline assistant. You highlight a region; the model rewrites just that region. Mostly an IDE thing.

Aider famously made the diff format itself the product — every edit is a diff, every diff is a commit, the git log is the history of the session. The Claude Code 2.0 cycle made surgical Edit cheap by formalizing structured string-replace, which is closer to Aider’s surgical posture without committing to unified-diff text. Most harnesses now ship two or three diff strategies and let the model pick.

7. Extensibility

Can you customize the harness itself, beyond the prompt?

Hooks — Claude Code. Shell commands the harness runs at lifecycle events (session start, before tool use, after tool use, on stop). Lets you wire in formatters, blockers, notifications, audit logs.
Skills / plugins / commands — Claude Code skills and plugins, Cursor’s command palette and rules, Cline’s custom modes. Package a prompt + tool set + scripts as a reusable thing you can install.
Custom rules files — every major harness. Project-scoped instructions injected into the system prompt.
SDKs — Anthropic’s Claude Agent SDK, OpenAI’s Agents SDK, Vercel AI SDK. Build your own harness (or extend an existing one) on top of someone else’s components.

Claude Code is the outlier on extensibility — the hook system is the deepest customization surface of any mainstream harness, and the design intent is that power users will write hooks for half their daily friction. Most other harnesses give you less surface, partly because the harness is the product — Cursor is not trying to be a kit, it’s trying to be an editor. Different bet; different shape.

For the canonical hook example end-to-end, see the audio-alert Stop hook. For more on the platform-extensibility design, see Claude Code from zero to daily driver.

The leading harnesses, in one paragraph each

For navigation, not for ranking. Each of these is a credible harness with a real user base in 2026; the choice between them is more about fit than quality.

Claude Code — Anthropic’s terminal-native coding agent. Deepest extensibility surface (hooks, skills, plugins, MCP, subagents), aggressively memory-aware, Anthropic-only (Opus 4.7 / Sonnet 4.6 / Haiku 4.5). The reference implementation for “agent as platform.” Many engineers daily-drive it in tandem with an IDE-embedded harness.

Cursor — VS Code fork from Anysphere. Started as best-in-class inline completion, now ships agent and composer modes that compete head-on with terminal agents. Indexes your repo by default. Multi-model (BYO key for Claude, GPT, Gemini, or use Cursor’s pooled inference). Best fit if “the editor is my workflow.”

Windsurf — VS Code fork (formerly Codeium, now under Cognition). Closer in spirit to Cursor than to Claude Code; emphasizes “Cascade” flows that drive multi-step agents from the editor sidebar. Less mindshare than Cursor in 2026 but a legitimate alternative, especially if your team already standardized on it.

Cline (formerly Claude Dev) — open-source VS Code extension. Brings an agent panel into stock VS Code without a fork. The right answer when you want the agent but don’t want to switch editors. Roo Code is the most prominent active fork, leaning into autonomous workflows.

Aider — diff-native CLI agent, predates the current generation by years. Git-aware to its bones — every edit is a commit, the chat log is a file, the changes are unified diffs you can read. Less feature-rich than Claude Code, but for surgical edits and clean git history it remains the cleanest tool in the category.

Codex CLI — OpenAI’s Rust-based terminal agent, the GPT-5.4 counterpart to Claude Code. Notable for OS-level sandboxing (Seatbelt, Landlock) rather than tool-level approval prompts. 1M context. Different safety posture, broadly similar shape.

Continue — open-source IDE extension for VS Code and JetBrains. Closer in feel to Cline than to Cursor; the open answer to “agent inside my existing IDE.” Bring-your-own-model by default.

Goose — Block’s open-source desktop agent. CLI plus a polished desktop GUI, MCP-forward, model-agnostic. Less common in mainstream developer workflows but the right pick if you want a local-first, OSS-first agent.

Devin — Cognition’s long-horizon autonomous agent. Runs in a remote sandbox, takes ticket-shaped tasks (“implement this Linear issue”), opens PRs hours later. The product bet is that agents can finish work humans don’t want to micromanage. Different shape; not interchangeable with the others.

OpenHands (formerly OpenDevin) — open-source autonomous agent in the Devin shape. Closer to a research platform than a polished product, but the only credible open alternative for “agent runs for hours unattended.”

Amp — Sourcegraph’s coding agent, built on top of the existing Cody / Sourcegraph search and indexing stack. Strongest in monorepo-shaped workflows where the value of repo-scale indexing actually shows up.

Zed agent panel — Zed’s built-in agent surface, MCP-supporting, leaning on Zed’s speed-first IDE philosophy. The right pick if you’ve already committed to Zed and don’t want a second tool to manage.

GitHub Copilot’s agent mode / Copilot Workspace — Copilot’s slow pivot from autocomplete to agent. The pragmatic default for teams already standardized on Copilot; less feature-deep than the dedicated agent harnesses today, but the deployment story (GitHub-native, SSO, billing) is unmatched in enterprise contexts.

Where they’re all the same (more than the marketing suggests)

The bigger story in 2026 is convergence. Read a Cline release notes alongside a Claude Code release notes side by side and the feature sets are 80% overlapping. Some honest universals:

They all wrap a frontier LLM. Most can swap models; Claude Code is the holdout. From the harness’s perspective, the model is increasingly fungible.
They all face the same context-window economics. Even with 1M-token models, “stuff the whole repo into context” doesn’t scale, doesn’t cache well, and degrades quality. Every harness has had to learn the discipline of small, focused prompts.
They all degrade past somewhere between 50 and 100 turns of real work. Long-horizon stability is the hardest unsolved problem in the category. Devin claims to solve it; the honest read is that Devin pays for it by being slow and expensive.
They all hallucinate APIs at roughly similar rates. A meaningful chunk of agent-generated bugs is the model confidently calling a function that doesn’t exist. The harness can mitigate — run the type checker, run the test, feed the model docs via MCP — but cannot eliminate.
They all need the same shape of human in the loop. “Read the diff before approving the PR” is universal. Every harness vendor knows privately that their output requires real human review for anything load-bearing.
They all converge on MCP. Two years ago each harness shipped its own plugin system. In 2026 the answer to “how do I add tool X?” is overwhelmingly “wire up an MCP server.”

The honest summary: the gap between the best and the rest is real, but smaller than partisans on either side claim. A skilled engineer can be productive in any of the top five harnesses; the differences are in friction, taste, and which axes they optimize.

How to pick (for a single developer in 2026)

Opinionated, ungenerous, and entirely yours to override:

You live in the terminal and want maximum control: Claude Code. Especially if you’re an Anthropic user already; pair it with an IDE-embedded harness for inline edits.
You live in VS Code and want the agent inside it: Cursor if you’ll pay; Cline (or Roo Code) if you want open source. Continue if you also live in JetBrains.
You write small, focused commits and care about clean git history: Aider. Still the best tool in the world for “small, deliberate, reviewable diffs.”
You work in a giant monorepo: Amp, or Cursor with the indexed-search features turned all the way up. Repo-scale context matters more than agent depth in this case.
You want long autonomous runs and don’t want to babysit: Devin if you can pay; OpenHands if you’d rather self-host. Be honest with yourself about whether the task is genuinely autonomy-shaped — most are not, and “autonomous” mostly means “fewer interruptions per hour of real wall-clock work,” not “fire and forget.”
You’re on the OpenAI side of the world: Codex CLI as the terminal answer; GitHub Copilot’s agent mode inside the IDE.
You want to stay open-source-first: Cline, Continue, Goose, OpenHands. All credible. Pick whichever’s interface fits your brain.

A meta-recommendation: the right answer for most professional developers in 2026 is two harnesses concurrently — one CLI-native for autonomous and long-running work, one IDE-embedded for inline edits and refactors-in-place. Almost nobody who tries this hybrid for two weeks goes back to a single-tool setup.

Pitfalls (mostly harness-shaped, mostly mistaken for model problems)

The failure modes that look like “the model is bad” but are actually “the harness is doing the wrong thing”:

Context blowup on big tasks. The model starts strong, gets confused around turn 30, hallucinates fixes by turn 50. Cause: the conversation accumulated without /clear or subagent isolation. Fix: respect the context window. Start fresh sessions for new tasks. Use subagents (where they exist) for big side quests.

Edits to files you didn’t expect. The model “while it was in there” cleaned up an adjacent function. Cause: the harness gave it free rein and you didn’t read the plan. Fix: use plan mode where it exists on anything bigger than a commit. Always read the diff before approving.

Hallucinated APIs and flags. The model confidently calls a method that doesn’t exist or passes a flag that was removed two versions ago. Cause: the model doesn’t actually know the library version you’re on. Fix: pin versions in your rules file; wire in a docs MCP server; remind the model to verify the import before calling it.

Memory drift. What the agent “remembers” from a previous session no longer matches your code — a function name moved, a file got renamed, an architecture decision was reversed. Cause: nothing forced you to audit it. Fix: prune memory periodically. Treat the memory file like code that bit-rots.

Permission fatigue. You start clicking “Yes, allow” without reading because the prompts won’t stop. Cause: too many tools, too few allowlist entries. Fix: invest twenty minutes in a real permission allowlist. The fatigue is the safety risk; whittling it down with structured permissions is the answer.

Skills and plugins out of sync. A skill you installed last quarter calls an API that has since changed. Cause: nothing forced you to audit it. Fix: review installed skills quarterly. Delete the ones you don’t actively use.

Treating the harness as a model problem. When something goes wrong, the temptation is to swap models. Sometimes that’s right. Often the problem is upstream of the model — a missing rules file, a misconfigured permission, a memory entry pointing at a function that no longer exists. Diagnose the harness layer before you blame the engine.

Notice that none of these failure modes are actually about the model. They’re about how the harness exposes the model. The model is approximately as good today as it was last week; what changes day to day is how skillfully you (and the harness) wield it.

What’s next

Harnesses are converging in 2026, but two real frontiers remain wide open.

Long-horizon stability. Every harness today degrades past ~50–100 turns of real work. The harness vendors all know it. The fixes — better compaction, smarter context retrieval, dedicated memory layers, hierarchical planning — are all incremental. Devin and OpenHands are the only credible bets on autonomous long-horizon work, and even they cap out somewhere short of “completes the feature unattended.” The first harness that genuinely supports stable 500-turn work changes the product category.

Multi-agent orchestration. Claude Code’s subagents are the deepest production version today, but they’re still a single-orchestrator pattern. The richer multi-agent setup — multiple agents collaborating, negotiating, splitting work, escalating to a human only at decision points — is mostly research. Whoever ships it as a daily-driver-quality product owns the next real platform moment.

Cross-harness portability. MCP solved the tool layer. Memory and rules files are next. The day my CLAUDE.md, my memory, and my MCP servers all just work in Cline, Cursor, and Claude Code without translation, harness lock-in goes away — and the competition shifts from “who has the best ecosystem” to “who has the best harness.” We’re moving in that direction. Slowly.

In the meantime, the strongest thing you can do is internalize the framing this primer opened with: the harness is the product. When you next read an announcement about “the new GPT-5.x model inside [agent],” ignore the model and read what the harness changed. That’s where the actual user-visible improvement lives, almost every time.

Where to go next

Claude Code from zero to daily driver — the canonical walkthrough of the most platform-shaped harness, end to end.
MCP in 20 minutes — the tool-layer protocol that every modern harness has converged on.
Caveman Claude: the skill everyone’s talking about — a concrete look at how the skill primitive is changing harness behavior.
Judgment is not a security boundary — the deeper version of the permission/autonomy story above.
The wrong thing is locked down by default — companion piece on what the current permission defaults get wrong.

If you read one more thing after this, make it the Claude Code primer — both as a daily driver in its own right and as the most fully-developed example of every dimension this primer walked through. Once you understand one harness deeply, the others mostly become “the same shape, different opinions,” which is exactly the relationship you want to have with this whole category.