What Is Claude Code, and What Can It Actually Do?

Introduction

Most AI coding tools finish your sentences. You type a function signature, they suggest the body, and you accept or reject it. Useful, but the model never leaves the file you are staring at.

Claude Code works differently. It is an agentic coding tool from Anthropic that runs where your code already lives, reads across the whole project, makes changes in more than one file, runs your tests, and reacts to what the tests say. You describe an outcome in plain language and it plans the steps, executes them, and checks its own work.

This post covers what it genuinely does today, how you extend it, and how it decides what it is allowed to touch. Claude Code ships changes frequently, so for anything version specific, treat the official documentation at code.claude.com as the source of truth rather than this post.

1. The Difference Between Autocomplete and an Agent

The distinction worth understanding is the loop.

An autocomplete tool is a single turn. It sees your current file, predicts the next chunk, and stops. You are still the one holding the plan in your head, deciding which file to open next, and running the tests yourself.

An agent runs many turns with feedback. Claude Code can search the codebase to find the code it needs, edit several files so a change actually hangs together, run the test suite, read the failure, and try again. The important part is not that it writes code. It is that something objective checks the work and the result feeds back into the next step. A failing test is a fact the model cannot talk itself out of.

That is why agents behave better on tasks where a real signal exists, such as a failing test, a type error, or a linter complaint, and less well on tasks where correctness is a matter of taste.

2. Where It Runs

Claude Code is available on several surfaces, and they share the same underlying engine and configuration:

• Terminal CLI, the primary surface, on macOS, Linux, Windows, and WSL.
• Desktop app on macOS and Windows, which adds visual diff review and parallel sessions.
• Web, at claude.ai/code, for sessions that keep running after you disconnect.
• IDE extensions for VS Code and for JetBrains IDEs such as IntelliJ IDEA, PyCharm, and WebStorm.

Your project context and settings follow you across these, because they live in files in your repository rather than in the tool.

3. Getting Started

Installation is a single command:

It is also available through Homebrew and WinGet if you prefer a package manager.

Then point it at a project and start:

You log in on first run. From there you talk to it in plain language.

4. What It Can Actually Do

Four capabilities carry most of the value.

It finds code without being told where to look. This is the one people underestimate. You do not paste files into a chat window. Claude Code searches the repository by filename pattern and by content, reads what it finds, and refines the search based on what it learns. You can say "the login redirect is broken" without knowing which file is at fault.

It edits across files. A real change is rarely one file. Renaming a concept touches the model, the API route, the component, and the tests. Claude Code makes those edits together.

It runs commands. Tests, builds, linters, scripts, and any CLI tool. This is what closes the loop and separates it from a tool that only suggests text.

It handles Git and GitHub. Branching, staging, commit messages, pull requests, and history, all conversationally.

It can also search the web and fetch pages, which matters more than it sounds. A model with a training cutoff can look up a current error message or a library's present API rather than guessing from memory.

5. CLAUDE.md, the File That Does the Most Work

If you adopt one thing, adopt this.

CLAUDE.md is a plain markdown file you write and Claude Code loads at the start of every session. It is where you record the things a new team member would need to be told and would otherwise ask you about:

• The commands that build, test, and run the project.
• Conventions the codebase follows.
• Architecture decisions that are not obvious from the code.
• Anything you find yourself repeating.

It lives at ./CLAUDE.md or ./.claude/CLAUDE.md in the project, which means you can commit it and the whole team gets the same context. A user level file at ~/.claude/CLAUDE.md applies across all your projects, and ./CLAUDE.local.md holds personal notes you do not want to commit.

The practical effect is that you stop re-explaining your project every session. Most complaints about an agent "not understanding the codebase" are really a missing CLAUDE.md.

6. The Extension Surfaces

Beyond project context, there are four ways to shape how it works.

Skills package a repeatable workflow or a body of reference knowledge into a markdown file, invoked as /name. A deploy procedure, a review checklist, a style guide. Their descriptions load at session start and the full content loads only when used, so a large library of them does not flood the context window.

Subagents are separate Claude Code instances with their own context that go away, do a job, and return a summary. Two reasons to use them: keeping a long research task from bloating your main conversation, and running independent work in parallel.

Hooks are commands that fire automatically at points in the lifecycle, such as before or after a file edit or a tool call. They are configured in your settings files. This is how you enforce something rather than request it. A formatter that runs after every edit is a hook. Asking nicely in CLAUDE.md is a request the model may forget. A hook is a guarantee, because the tool itself runs it rather than the model choosing to.

MCP servers connect Claude Code to systems outside your codebase through the Model Context Protocol, which is a standard interface for exposing tools to a model. Issue trackers, databases, design tools, and similar. The point of the standard is that a connector written once works with any client that speaks the protocol, instead of every tool needing bespoke glue.

Settings live in JSON files that merge from broad to specific: user level at ~/.claude/settings.json, project level at .claude/settings.json, and personal project level at .claude/settings.local.json, with the more specific winning.

7. The Permission Model

This is the part worth understanding before you let an agent run commands on your machine.

Claude Code asks before it acts, and how much it asks is controlled by a permission mode. In the default mode, read-only actions go ahead and anything that edits a file or runs a command prompts you. Plan mode is stricter still: it explores and proposes but does not change anything, which is useful when you want a plan before any edits happen. Other modes trade prompts for autonomy in varying degrees, up to a mode intended only for isolated containers where nothing is checked at all.

Two details matter in practice:

• You can pre-approve or block specific tools and commands with allow and deny rules in settings, so npm test can run freely while something destructive never does.
• Sensitive paths such as .git and .claude are protected and are not auto-approved.

There is also a checkpoint system. Files are snapshotted before Claude changes them, so you can rewind, and that is independent of Git.

The mental model I would recommend: treat an agent's proposed action the way you would treat a pull request from someone competent but unfamiliar with your production environment. Most of it is fine. You still read it.

8. What It Is Not

An honest tour needs this section.

It is not a replacement for understanding your own codebase. It is fastest when you can tell whether its answer is right, and most dangerous when you cannot.

It is not deterministic. The same prompt can produce different work. That is why the objective checks matter and why a test suite is worth more to an agent than a longer prompt.

It does not remove the need for review. It can produce code that passes tests for the wrong reason, and it will occasionally be confidently wrong about a library it has not looked up.

And it is not free. Usage is metered, so a long autonomous run over a large codebase costs more than a targeted question.

Conclusion

The useful way to think about Claude Code is not "AI that writes code for me". It is a tool that can act in your environment and check the result, which makes it good at the work that has a clear success signal: fixing a failing test, tracking a bug across files, doing a mechanical migration, wiring up a change that touches six files.

If you try it, start with a CLAUDE.md and a task that has a test attached. That combination shows you what the loop is actually good at faster than anything else.

Since the tool changes quickly, check the documentation at code.claude.com for current behaviour rather than trusting any blog post, including this one.

---

Written for developers evaluating agentic coding tools. More on how these systems behave in practice to follow.