What Is Claude Code?

An agentic coding tool, not a chat box. How Claude Code differs from a code-completion assistant and from a raw chat model.

Concept Foundational
6 min read
foundations conversation-loop overview

Summary#

Claude Code is an agentic command-line tool built on top of the Claude family of models. You launch it in a directory, state intent, and Claude reads your files, plans, calls tools (Read, Edit, Write, Bash, Grep, Glob, WebFetch, Task, and more), and emits text — in a loop, with you in the seat next to it. It is shipped by Anthropic as a CLI, with companion extensions for VS Code and JetBrains and a programmatic interface in the Claude Agent SDK.

What it is not: a code-completion plugin (it doesn’t suggest the next token as you type), a chat box that quotes code at you (it actually edits files), or a fully autonomous agent (it asks for confirmation on risky actions by default).

Why it matters#

The shift from “AI suggests, human types” to “AI edits, human reviews” is a different kind of tool to build around. Code-completion assistants are bounded by the line you’re on; an agentic CLI is bounded by what it can read, plan, and verify across the whole repo.

For most engineers the immediate consequences are practical:

  • Tasks that previously took hours of typing — adding a new endpoint with tests, refactoring across a dozen files, writing release notes from a diff — collapse to a conversation and a review.
  • The skill that matters most is no longer “remember the syntax” but “describe intent clearly, verify aggressively, redirect when wrong.”
  • The cost shape changes: each session costs tokens, and long unfocused sessions burn more than short focused ones. Conversation design becomes engineering hygiene.

The second-order consequence — and the one this whole workbook orbits — is that Claude Code is a tool with its own surface, conventions, and footguns. Knowing the surface (memory files, permission modes, plan mode, hooks, slash commands, sub-agents, MCP) is the difference between a frustrating week-one experience and a tool that disappears into your workflow.

How it works#

The loop#

Every Claude Code session is the same loop:

  1. You state intent. A sentence or two of what you want done, or a question about the code.
  2. Claude reads. It pulls files into context, runs Grep/Glob for orientation, possibly delegates research to a sub-agent.
  3. Claude plans. Internally, sometimes also in plan mode where it writes the plan to a file for your review.
  4. Claude acts. Calls Edit / Write / Bash to make changes. Many tools run in parallel.
  5. Claude reports and waits. Brief status text in user-facing output, then yields the floor back to you.
  6. You redirect or proceed. Approve, ask for changes, ask a question, move to the next step.

That’s it. Every advanced feature — hooks, sub-agents, skills, MCP integrations — is a way of customising or extending one of those six steps. Internalise the loop and the rest of the surface stops being a mystery and starts being obvious.

Context, not memory#

The model has no memory between sessions by default. What it has is a context window: a finite token budget that includes the system prompt, the tool definitions, your messages, the model’s previous turns, and the tool results so far. Within a session that window grows; across sessions it resets.

Claude Code patches this with three layered persistence mechanisms:

  • CLAUDE.md files at the user, project, and (optionally) subdirectory level. These are loaded into context automatically when a session starts in that directory.
  • memory/ files in the user’s Claude Code config dir. The model can read and write these to carry user-specific knowledge across sessions.
  • /loop and /schedule for explicitly scheduled work that re-enters a session at a future time with prior context.

For most engineers, the CLAUDE.md file is the highest-leverage one — it’s the project’s permanent briefing to every future Claude session.

Tools, not autonomy#

Claude Code’s agency is bounded by its tools. The built-in toolset is small and composable: file tools (Read, Edit, Write), shell (Bash), search (Grep, Glob), delegation (Task / sub-agents), web (WebFetch, WebSearch), task tracking (TodoWrite), and a handful of others. MCP integrations add tools from external systems (Slack, Gmail, Drive, BigQuery, custom servers).

There is no “do whatever you want” tool. Anything risky — running a destructive shell command, force-pushing, deleting branches — falls under the permission system, which the user controls via permission modes and allowlists.

Variants and trade-offs#

Code-completion assistants (Copilot-style) — line-level suggestions, near-zero latency, no agency. Bounded by what’s on your screen; cannot read across files, cannot run tests, cannot edit unprompted. Cheap per-call; expensive per-task.
Agentic CLIs (Claude Code, Aider, Cursor’s agent mode) — task-level execution, planning, multi-file edits, can run tests, can call shell. Bounded by tools and permission, not by cursor position. Expensive per-call; cheaper per-task.

Within agentic CLIs, the dimensions Claude Code optimises for:

  • Conversation, not one-shot. The unit is a dialogue, not a single completion. Long sessions are first-class; context-management is a feature, not a workaround.
  • Permission by default. Risky actions confirm before running. Bypass is opt-in, not opt-out.
  • Composability. Slash commands, skills, sub-agents, hooks, MCP — all stack. You shape Claude Code to your team, not the other way around.
  • First-class IDE story. VS Code and JetBrains extensions share state with the CLI; you can move a session across surfaces.

The trade-off it makes for these: it’s not the fastest at simple completions (a code-completion plugin will win on a one-line suggestion), and the per-call cost is higher than a one-shot model API. The whole point is that for the right unit of work — a feature, a refactor, a bug hunt — the per-task economics flip in its favour.

A short note on how the name maps to the product

“Claude Code” refers to a few related things: the CLI (claude in your terminal), the desktop apps that wrap it (Mac and Windows), the web version at claude.ai/code, and the IDE extensions that embed it. They all run the same conversation loop and share the same conventions — the differences are surface, not substance. Most of this workbook uses “Claude Code” to mean any of them.

When this is asked in interviews#

Not often, yet. Agentic CLIs are too new and too unevenly adopted to show up reliably on hiring loops in May 2026. Where they do show up:

  • AI-product loops — the question is usually “have you built with one?”, not “explain the architecture”. A concrete example of having shipped something with Claude Code or an equivalent tool is the expected answer.
  • Senior backend / platform loops — when the team is wiring up internal-tooling agents (CI helpers, on-call runbooks, deploy bots). The question becomes “what are the failure modes you’ve seen?” — hallucination, permission misconfiguration, infinite loops, cost overruns.
  • Developer-tooling / DX loops — directly relevant. The depth of question gets higher: how does the agent’s context window interact with codebase size, how do you evaluate an agent’s edits, how do you wire MCP servers without breaking the security boundary.

Where it doesn’t come up: most algorithms / DS&A interviews, frontend-only loops at companies that haven’t adopted agentic tooling, and any role where the team is still on a code-completion-only stack.

Search ESC

Keyboard shortcuts

Shortcuts are disabled while typing in inputs.