Last week you built an interface: a streaming REPL that talks. This week you cross the line that separates a toy from a tool.
The mechanism is function calling — you describe tools to the model, it responds with structured requests to use them, you run them and feed the results back, and you loop until it is done. That loop, plus six well-designed tools, plus a permission gate, is a coding agent.
A tool is a contract, not a function. The model never sees your code — it sees a name, a description that says when to use the tool, and a schema of arguments. Ninety percent of "the model uses tools badly" is actually "my tool descriptions are vague."
The result is the teacher. When a tool fails, you do not crash — you return the error to the model as data, and a good model reads it and fixes its next call.
The walkthrough
Each part adds one capability to the same growing codebase, and each is a runnable checkpoint.
- 01Read & WriteThe two simplest tools, and the path-safety rules that keep them inside the project.
- 02EditExact-match replacement — why it beats "rewrite the file" for reliability and cost.
- 03Glob & GrepFast, exact, free search. The right first move before anything semantic.
- 04BashThe most powerful and most dangerous tool, and how to scope it.
- 05The permission systemAllow, deny, ask — and remembering the answer for the rest of the session.
- 06Fix a real bugEnd-to-end milestone: the agent finds, fixes and verifies an actual bug in a real repo.
After this week you can
- Write tool descriptions a model uses correctly the first time
- Design tool errors that let the model self-correct
- Build a permission system you would actually trust