CODEAI101 · chapter 3 of 7 · free to read
This is the whole chapter, not a sample of it. Nothing is shortened for the showcase and nothing here is recorded — no account, no cookie, no reading history. Every chapter of this ladder was signed by a named person before it was served; this one by Capt Anil Sharma.
For two days the AI has only talked. You typed a question, it produced words on a screen, and whatever happened next in the real world was on you — you read it, you decided, you acted. The model never touched anything. Today it gets hands.
With tools, the model's response can be call the function send_email with these arguments — and a system somewhere actually runs that function. An email actually leaves. A file actually gets written. A row in a database actually changes. The model did not type the email. It decided to call a tool with specific parameters, and the tool did the rest.
Recall Code101 Day 4: code is text in a language a machine can read, and running means the machine is following those instructions right now, one line at a time. Tool use is the moment the model's text becomes running code somewhere. The fluent imitator from Day 1 of this course now has a way to affect the world — through the tools you gave it.
THE MOMENT AN AI CAN CALL TOOLS, ITS SENTENCES BECOME ACTIONS, AND SOMEBODY HAS TO BE RESPONSIBLE FOR THE ACTIONS.
The coding assistants you have already met — Claude Code, OpenAI Codex, Cursor, Windsurf, Aider — are tool-using AIs. When one of them edits a file, it is not pretending; the file changes. When it runs a shell command, the command executes. The model inside is still only predicting the next move. The harness around it makes those moves real.
A tool, in this sense, is a function the model can decide to call, and it has three parts.
A NAME — send_email, search_web, read_file, query_database, book_calendar_slot.
A DESCRIPTION — plain English explaining what the tool does and when to use it. The model reads this to decide whether the tool fits the task in front of it.
A PARAMETER SCHEMA — the inputs it expects, with names, types, and which are required. To: a string, an email address, required. Subject: a string, required. Body: a string, required.
When a model is set up with tools, the system message you learned about yesterday carries the definition of every tool it is allowed to call. While generating its next response, it can produce ordinary text — or it can produce a structured tool call instead, a request to invoke one of those functions with the parameters filled in.
That call goes to a piece of software called a tool harness, which receives it, validates the parameters against the schema, runs the actual function, captures the result including any failure, and sends that result back to the model as another message in the conversation. The model reads the result and decides what to do next: call another tool, or answer in words.
Call tool, run tool, feed the result back, call the next tool. That loop is the engine underneath every modern agent. The model is the planner; the harness is the limbs.
THE DANCE
Ask a tool-using assistant to check the disk usage on a server and say which directory is biggest, and watch what actually happens.
It reads your message alongside the descriptions of the tools it has. It decides it needs a shell command, and emits a tool call: run_shell, with command df -h. The harness runs that on the server and captures the output. The harness sends the output back as a new message — tool result, followed by what df printed. The model reads it, now knows the disk usage, and decides it needs the biggest directory on the busiest disk. It emits a second call: run_shell again, this time du -sh on that path, sorted, tail ten. The harness runs it and feeds the result back. Only now does the model produce words for you: the biggest directory is this one, at seventy-one gigabytes, mostly backups.
You saw one reply in your chat. Underneath, two shell commands ran on a real machine, each result folded back into the model's context. It was operating in a loop, using tools to touch the world between turns.
That loop is what people mean by an agent, and Day 4 goes into it properly. For today, hold the shape of the dance.
Tool use introduces failures that pure chat does not have, and five are worth naming.
WRONG TOOL. The model decides to use delete_file when it should have used archive_file. The harness obediently runs the wrong one. Real data is gone. The model had no way to know it was wrong; it generated a plausible-looking call.
WRONG PARAMETERS. The right tool, the wrong argument — send_email to the wrong address. The email goes to the wrong person, and you cannot un-send an email.
UNINTENDED SIDE EFFECTS. The tool does exactly what it was supposed to do and something else breaks. Delete all log files older than seven days runs cleanly. The side effect: a script that was reading those logs to build a monthly report now fails silently.
LOOPS. The model cannot reach its goal and keeps trying. Every call costs compute, fees and time. Without limits, an agent can burn through thousands of calls and real money before anyone notices.
PERMISSION ESCALATION. A tool meant to do one thing turns out to be able to do more, and the model discovers it. A plugin can fetch URLs; it fetches one pointing at an internal admin endpoint that should have been protected and was not; now it has admin access.
Underneath all five is the shift that matters. In a pure-chat AI the worst case is a wrong sentence — embarrassing or misleading, but reversible by reading carefully. In a tool-using AI the worst case is a wrong action: irreversible, real, and consequential. That is why the next section exists.
The single most important decision when giving a model tools is which tools require a human to approve before they run. There are three rough tiers.
AUTO-APPROVE, SAFE BY DESIGN. Reads, searches, data fetches — anything that does not change state. Let it call these freely. They cost compute and cannot break anything.
APPROVE-AFTER, FOR LOUD WRITES. Reversible changes in low-stakes places. The tool runs, and the user is shown what was done with the option to undo it. Right for editing files in a personal project, or booking a calendar slot you can move.
APPROVE-BEFORE, THE GATE. Anything irreversible or high-stakes — sending mail, moving money, deleting data, destructive shell commands, deploying to production. The model proposes; a human reviews and approves; only then does the harness run it.
Well-designed products let you configure which tier each tool sits in. Claude Code, for instance, asks before running shell commands that match certain patterns — rm, git push — and runs the safer ones itself. Those defaults are a statement of the product's philosophy, and reading them tells you what its builders were afraid of.
The other half of supervision is observation, which you already know from Code101 Day 7. Logs: every call the model made, with its parameters and result, auditable afterwards. Monitoring: calls per minute, error rate, cost. Alerts: when something is far outside normal — a thousand calls in five minutes, or a tool that has never been used suddenly being used repeatedly. And rollback paths: for any tool that changes state, a designed way to undo, either built into the tool itself or external, like a backup you can restore from.
A serious system has all four. A toy demo has none, and now you can tell them apart in one question.
The terminal assistants named on Day 1 of Code101 — Claude Code, OpenAI Codex, Cursor, Windsurf, Cline, Aider — are all tool-using AIs, and their tools fall into a few families.
File operations: read a file, write one, edit one with a diff you approve, list a directory. Shell execution: run commands, usually with approval required for sensitive patterns and free rein for read-only ones. Search: grep across a codebase, find files by name. Web: fetch a URL, search the web, often off by default. And specialised ones: git, package managers, language servers, test runners, browser drivers.
Ask one of them to fix a failing test and the whole dance runs: read the file, read the test output, decide on a change, propose the edit, get your approval or auto-approve by setting, run the test again, and repeat until it passes. Every step is a tool call. The model is the planner; the tools are the limbs.
Chat assistants are going the same way — code execution in a sandbox, web search, image generation, reading files you upload. The line between chat and agent is dissolving, and a product without tools today is a product from last year.
The literacy does not change with the fashion. Which tools does this assistant have? What can it actually do? What needs approval before it runs? And what can I undo when it goes wrong? Ask those four of any AI that claims it can act, and you will learn more about it in a minute than a demo will tell you in an hour.
The rest of this ladder is for enrolled learners. This chapter is the whole of what is open — it is not a teaser with the ending removed.