Chapter 1: The tool landscape

Every AI coding tool on the market is some combination of three interaction modes, wrapped around one or more large language models, with some mechanism for feeding the model context about your code. Understanding the three modes is more durable than memorising any product's feature list.

Three interaction modes

Mode	You give	You get	Latency	Best for
Inline completion	The cursor position and surrounding code	A few lines, accepted with Tab	Sub-second	Boilerplate, finishing a pattern you have started, tests that mirror existing tests
Chat	A question or request, plus whatever files you attach	An answer, an explanation, a proposed diff you apply	Seconds	Understanding code, exploring alternatives, drafting a spec, small targeted edits
Agent	A goal and a set of permissions	A multi-step session: the tool reads files, runs commands, edits, re-runs tests, and reports back	Minutes	Well-specified tasks with a verifiable end state: "make these tests pass", "migrate these call sites", "add this endpoint"

The modes are not better or worse than each other; they are different tools for different grain sizes of work. The common mistake is using agent mode for a task that has no verifiable end state ("improve this"), or using completion for a task that needs a plan.

Choosing a mode

Three products, one map

In 2026 most teams evaluate some subset of three tools. They overlap heavily; the differences are in emphasis.

Claude Code

A terminal-first agent from Anthropic. You run it in a shell inside your repository; it reads files, runs commands, edits, and iterates. Configuration lives in a CLAUDE.md file at the repository root (and optionally in subdirectories and your home directory), which the agent reads at the start of every session. It supports Model Context Protocol (MCP) servers for connecting external tools, hooks for running commands at defined points in the session, and sub-agents for delegating parts of a task.

Emphasis: agent mode, long autonomous sessions, explicit permission model for commands and file edits. Where it is weaker: no inline completion; the editor integration is lighter than the terminal experience.

GitHub Copilot

The incumbent, integrated into VS Code, JetBrains, Neovim and the GitHub web UI. Started as inline completion and now offers chat, an agent mode in the editor, and a cloud "coding agent" that takes a GitHub issue, works on a branch and opens a pull request. Repository instructions live in .github/copilot-instructions.md; path-specific instructions in .github/instructions/*.md. Code review suggestions appear directly on pull requests.

Emphasis: breadth of integration, inline completion quality, enterprise administration (policy, audit, IP indemnity). Where it is weaker: the agent is more conservative and the context controls are less fine-grained than the dedicated tools.

Cursor

A fork of VS Code built around AI. All three modes are first-class: Tab completion that predicts multi-line edits, chat with the whole codebase indexed, and an agent mode that plans and executes across files. Rules live in .cursor/rules/*.mdc with glob-based scoping (a rule applies only when matching files are in context). Supports MCP, background agents that run in isolated environments, and a "Bugbot" that reviews pull requests.

Emphasis: the editor experience, codebase indexing, fine-grained rules. Where it is weaker: it is an editor, so teams standardised on JetBrains or Neovim need a different approach.

Honest comparison

	Claude Code	GitHub Copilot	Cursor
Inline completion	No	Yes	Yes (multi-line)
Chat	Yes (terminal)	Yes	Yes
Agent	Yes (primary)	Yes (editor + cloud)	Yes
Rules file	CLAUDE.md	copilot-instructions.md	.cursor/rules/*.mdc
MCP support	Yes	Yes	Yes
PR review	Via Actions	Native	Bugbot
Model choice	Anthropic	Several vendors	Several vendors
Runs outside an editor	Yes	Cloud agent	Background agents

Every row in this table will change. The shape will not: a rules file, three modes, MCP for tools, some form of PR review, and a choice about where the agent runs.

Running a fair evaluation

Teams waste months debating tools on the basis of demos. A two-week evaluation with the following structure produces a decision:

1. Pick five real tasks from your backlog: one bug fix, one new endpoint, one refactor across files, one test-writing task, one "explain this module" task.
2. Write the spec for each once, following Module 2. The same spec goes to every tool.
3. Same engineer, same task, each tool. Rotate so that nobody evaluates only one.
4. Measure three things: time to a mergeable diff, number of review findings, and whether the engineer would trust the tool with the task unsupervised next time.
5. Write down the rules file you needed to get good results. The tool that needed the least coaching is telling you something.

Expect the result to be "they are all fine; the workflow matters more than the tool". That is the correct result. Pick on integration, administration and price.

When to stop an agent

Agent mode is the most powerful and the most dangerous of the three. Stop the session and restate the request when:

• The agent is on its third attempt at the same failing test.
• The diff has grown past the scope you stated (file count is the quickest signal).
• The agent has started modifying tests, configuration or dependencies you did not mention.
• The agent is "exploring" - reading files unrelated to the task - for more than a minute.
• You no longer understand what it is doing.

Restarting with a tighter spec is almost always faster than steering a session that has drifted.

Summary

• Three modes - completion, chat, agent - matched to the grain size and verifiability of the task.
• Claude Code (terminal agent), Copilot (breadth and enterprise), Cursor (editor and rules) cover the same ground with different emphasis.
• Evaluate on five real tasks with a shared spec; expect the workflow, not the tool, to be the deciding factor.
• Stop an agent early and restate rather than steer a drifting session.