What is a coding assistant?

You open a fresh terminal in an unfamiliar codebase and ask Claude Code to add a feature. A few seconds later, it has read the relevant files, sketched a plan, edited three modules, and run the tests — all without you typing ls. That is a coding assistant doing its job. Under the hood, the mechanics are simpler than they look, and understanding them changes how you use the tool.

The gather-plan-act workflow

A coding assistant is an application that uses a language model to complete development tasks. The shape of almost every task it handles is the same three-step pattern — call it the gather-plan-act workflow.

Gather: the assistant reads the files and signals it needs to understand the task. That might mean opening package.json, grepping for a symbol, or scanning the directory tree.

Plan: it forms an approach. Which files will change? In what order? What could break?

Act: it executes — editing files, running commands, staging commits. Then it checks its work and loops back to gather if something is off.

This is not a novelty. It is the same loop you run in your own head when you land in a new repo. The interesting part is how the language model actually does any of it, because on its own, it cannot.

The fundamental limitation

A language model can only process text in and return text out. It cannot read files, execute commands, or touch anything outside its own input and output stream. Given a prompt, it produces a completion. That is the entire contract.

This is a problem for a coding assistant. Writing code requires opening files, running compilers, inspecting errors, and editing on disk — none of which a raw language model can do. So the question becomes: how do you bridge a text-only model to a real development environment?

Tool use — the mental model for the entire course

The answer is tool use. When you send a request to a coding assistant, the application quietly appends instructions to your prompt telling the model how to request an action. Something like: "If you need to read a file, respond with ReadFile: <path>. If you need to run a command, respond with RunCommand: <cmd>."

Here is what that looks like in practice. You ask Claude Code to summarise main.go. The model cannot open the file, so it responds with a formatted message like:

ReadFile: main.go

The coding assistant intercepts that response, recognises it as a tool request, performs the actual file read on your filesystem, and feeds the contents back into the model's context. The model now has the text of main.go and can continue — reading more files, editing them, running commands — one tool call at a time.

Every capability a coding assistant has works this way. Reading, editing, grepping, running tests, fetching from the network — all of it is text-in, text-out at the model layer, with the application running the actual operations and returning the results.

If you remember one thing from this lesson, remember this: everything Claude Code does is tool use, and the quality of those tool calls is the difference between a coding assistant that helps and one that gets in the way.

Why Claude's tool use matters

Not all models are equally good at tool use. Claude is particularly strong here — better at picking the right tool for a task, at chaining tools to solve multi-step problems, and at figuring out unfamiliar tools it has not been trained on. That strength compounds into three concrete advantages.

Complexity: stronger tool use means Claude can handle tasks with more moving parts — multi-file refactors, end-to-end debugging, cross-cutting changes — without losing the thread.

Extensibility: adding new tools is cheap. Because Claude is good at using tools it has not seen before, you (or the MCP ecosystem) can bolt on new capabilities without retraining anything. You will see this in practice later in the course.

Security: Claude Code works by searching your codebase on demand through tool calls, not by pre-indexing your source into a remote database. Your code stays on your machine, and you see every tool call it makes.

Back to the workflow

The gather-plan-act loop is the shape of the work. Tool use is the mechanism that lets a text-only model do any of it at all. Everything else in this course — context management, plan mode, hooks, MCP servers, the SDK — is a way of shaping which tools Claude reaches for and what information it has when it does.