Introduction
If you want to know how to build an agent, Thorsten Ball's answer is deflating in the best way: a code-editing agent is essentially a large language model (LLM) running in a loop with a handful of tools. In his April 2025 post "How to Build an Agent" — subtitled "The Emperor Has No Clothes" — Ball builds a working coding agent in Go in under 400 lines, most of which he calls boilerplate. There is no secret sauce, no proprietary orchestration layer. There is a model, a loop that keeps talking to it, and three small functions the model is allowed to call.
That claim is worth taking seriously because Ball is not an outsider. He works on Amp, the coding agent that spun out of Sourcegraph in December 2025, and he wrote the widely read book Writing an Interpreter in Go. His point is not that production agents are trivial — it is that the core is simple, and once you see it, every coding agent stops looking like magic. This post walks through that core: the loop, the three tools, and, just as importantly, what a 400-line demo leaves out.
What Thorsten Ball Actually Claims
The thesis of the post is a single sentence: "It's an LLM, a loop, and enough tokens." Ball argues that the perceived complexity of AI coding tools hides an underlying simplicity, and that building "a small and yet highly impressive agent" does not require heroic engineering.
An AI agent, in this framing, is a system that pursues a goal by deciding its own next action rather than following a fixed script. The model is the reasoning engine; the tools are its hands. What makes the thing agentic is that nobody hardcodes the sequence of steps — the model looks at the situation, decides whether it needs to read a file, list a directory, or make an edit, and the program obliges. That decide-act-observe cycle is the essence of an agentic workflow.
How Agents Work Under the Hood: The LLM-in-a-Loop
Strip away the interface and a coding agent is a conversation that does not stop after one reply. Concretely, the loop looks like this:
- Send the conversation so far to the model, along with the list of tools it may use.
- The model replies. Its reply is either plain text for the user, or a request to run a tool.
- If it is a tool request, your program runs the tool and appends the result to the conversation.
- Go back to step 1.
The critical detail is who does what. The model never touches your filesystem. It only decides. When it wants to act, it returns a structured tool_use block that names a tool and supplies arguments — for example, "call read_file with path main.go." Your code, the harness, executes that function locally and sends the output back. In Ball's words: "when the model wants to execute the tool, it tells you, you execute the tool and send the response up." The loop simply repeats until the model has nothing left to call and answers in plain text.
This division is why the demo is so short. The model already knows how to reason about code; you are not teaching it to program. You are only wiring up a channel through which it can ask for information and effect changes, then feeding the results back so it can take the next step.
The Three Tools: read_file, list_files, and edit_file
The agent Ball builds is given exactly three tools. A "tool," here, is a normal function plus a description written in plain language — the model reads that description to understand when the tool is useful and what arguments it takes.
read_file— takes a file path and returns the file's contents. This is how the agent sees code before it changes anything. Without it, the model is guessing about the state of your project.list_files— takes a path and returns the files and directories under it. This is how the agent explores an unfamiliar codebase, discovering what exists so it can decide what to read next.edit_file— takes a file path, a target string, and a replacement string, and swaps one for the other. This is how the agent acts. Notably, the same operation doubles as file creation: asking to replace an empty string in a nonexistent file creates it.
That is the entire toolbox. Read, look around, and change text. From those three primitives the model can navigate a project, find the relevant lines, and edit them — because the intelligence is in the model, not the tools. The tools just give it a way to reach the world. This is the same pattern a standard like the Model Context Protocol (MCP) later formalizes: a common interface for handing an agent a set of tools it can discover and call.
Build an Agent in 400 Lines of Go
Ball chooses Go and the Anthropic API with Claude, and the code accumulates in visible stages. A bare chat loop comes first — just send-and-receive with no tools. Adding read_file brings the total to around 190 lines and already yields something that can answer questions about your code. list_files and edit_file follow, and the finished agent lands under 400 lines, "most of which is boilerplate" for JSON handling and API plumbing.
The reception proved the point better than any argument could. Rather than a single viral moment, the post spread through developers who read it and immediately reimplemented it: there are faithful ports in Python, TypeScript, and JavaScript, several reaching a working agent in roughly 200 lines. When a tutorial is this easy to reproduce across languages, its core claim — that the hard part is not the code — is hard to dispute.
What a 400-Line Demo Leaves Out
The honest reading of this post is that it explains the core, not a product. A 400-line demo is not a production agent, and the gap between them is exactly the work Ball's essay skips:
- Safety and permissions. The demo will edit any file it decides to edit. A real tool needs sandboxing, approval prompts, and limits on what the agent can touch or run — an agent with
edit_fileand no guardrails is a liability. - Error handling. Tools fail: files are missing, edits do not match, APIs time out. Production code must catch these, report them back to the model usefully, and retry.
- Context management. Long sessions overflow the model's context window. Real agents compact history, summarize, and decide what to keep — a problem the short demo never hits.
- More tools and better UX. Running commands, searching, using version control, plus a usable interface and cost controls, are all additions on top of the core.
None of this contradicts the thesis. It sharpens it: the loop and the tools are the small, comprehensible center, and production engineering is the substantial ring built around it. For a look at that ring as a supported framework, see our write-up of building agents with the Claude Agent SDK, which provides sandboxing, context compaction, subagents, and tooling as first-class features.
What This Means for Every Coding Agent
Once the pattern is clear, the whole category becomes legible. Cursor, Claude Code, Amp, and the rest are elaborations on the same LLM-in-a-loop core — more tools, better context handling, stronger safety, and far more polish, wrapped around the identical idea Ball demonstrates in 400 lines. Even multi-agent systems, where several agents coordinate on a task, are compositions of this same primitive: each agent is still a model in a loop with tools.
That is the real value of reading the post. It converts a coding agent from something you use on faith into something you can reason about. When an agent does something surprising — good or bad — you know where to look: the tools it was given, the results it saw, and the loop that kept it going.
Conclusion
Thorsten Ball's "How to Build an Agent" makes a deliberately unglamorous case: a code-editing agent is an LLM, a loop, and three tools — read_file, list_files, and edit_file — in under 400 lines of Go. The model decides; the harness executes and feeds results back; the loop repeats. What separates that demo from a shipping product is not a smarter core but everything around it — safety, error handling, context management, more tools, and UX. Understanding the core is the fastest way to demystify every coding agent you will ever use, and to reason clearly about what they can and cannot do.
To go up a level to the model itself, see Karpathy's nanochat; for the same LLM-in-a-loop idea taken to an extreme, see the Ralph technique.