Sign in to continue learning
Building Coding Agents with Tool Execution
Intermediate
Topics
Agents
In this lesson, you will learn what a coding agent is, how it reasons through tasks and how it uses tools like code execution and file system to complete them. Let's dive in. This is an example of a coding agent that we will build in this course. Here, the agent turns your request into a working application. To achieve that, it writes code files, executes them, and instantly serves a web app. all on its own in the cloud. An AI agent can simply be defined as an LLM calling Tools in a Loop with Context. Tools can be code that the agent runs or external services that it can call. For example, working with files, searching the web, or visualizing data insights. The context is any input for the LLM. It can be System Instructions, Tools Definitions, User Message, or more. The LLM, based on the context, decides if and which tool to call. The agent calls and runs the tool. appends the results to the context and repeats the loop until the task is completed. An AI agent might just reason for a while, browse its resources and return an answer. You can ask the agents to do tasks like booking flight for you or doing research on a subject and writing a summary on it. But then, there are agents like Gemini CLI, Claude Code or Cursor. These are coding agents that write and run code and related tasks like generating a long script, debugging it, or editing dozens of files in a project. That requires code execution in a controlled environment to iterate on the code over and over. Coding agents also need filesystem access. And because coding is complex, most tasks need long-running sessions to install dependencies, compile, run tests, patch errors, and retry. Finally, these agents need stronger security. Untrusted code must be handled such that experiments don't break your machine or malicious actors don't gain access to your system. Like any other agent, your coding agent will have an LLM at its core. The question is, how do we pick the right one? First, the model should support function calling. That means that the LLM is provided with a set of tools and it can decide when and how to use them. Second, the context size matters. Research shows that around 30k tokens of context is the first point where agents can reliably handle real-world tasks. It corresponds to about 40 to 50 pages of text, which is like a medium-sized GitHub repo. This is needed because working with larger projects like Django or PyTorch will require a model to read and edit many files, easily using tens of thousands of tokens. Third, for the right decision, we can evaluate the LLMs, ideally with coding specific benchmarks. One of the most widely used is SWE-bench. It tests whether a model can take a real GitHub issue, generate a patch and pass the repo's unit tests. Here is the leaderboard from October 2025. But remember that this is just one possible metric. You can evaluate models depending on your use case. Context is everything the LLM sees. For coding agents, context can be the system prompt, the external input like a PDF or a database search result, the user prompts, tools, and tool execution results. and other things like current branch commit, file summaries, previous patch notes, dependency versions, or short-term memory facts from earlier runs. Context Engineering is the art of keeping the context small while providing the most relevant information to the model to complete the current task. We need to manage context length because especially for coding agents, it can grow very quickly. Every edit run debug cycle adds more text to the conversation. Tool outputs can be massive, especially when they return big JSONs or logs. Then you can get repeated error stacks on top of that. The result is what we call context rot. As the token count grows, the model starts paying less attention to what matters and quality drops. We just saw how context can explode. In coding agents, one common source of tokens is raw tool outputs. The first way you can mitigate that problem is by keeping tool outputs small, consistent, and structured. For example, we have a tool called get_weather that will ping an API to get the results. If we just return the response's data, we might overwhelm the context with information that's not needed. So you can parse the output and return only the data the LLM actually needs. This doesn't apply only to JSON responses. Logs can grow huge too, so we clip them to the last few lines and drop repeated messages to keep the context small. Coding agents need to scan the file system quite often. For example, listing files based on some pattern. But if you work on a large project, a directory may contain hundreds of files. And returning all of them can really flood the context. One common strategy is to paginate the results and give the model the ability to request the next page if needed. We can also filter the listing first. For example, only Python files or only certain directories. So the model sees just what matters. Your coding agent will need specific tools to accomplish its coding tasks. At least running code and accessing the file system. To run the code, we should follow some rules. I think code generated by an LLM should be treated as untrusted. We should try to avoid running the code actions directly on the host. Ideally, we should go for a safer environment isolated from the rest of the system. We can also enforce strict limits on the CPU, memory, and execution time. So a runaway process can't bring things down. We can also block network and filesystem access unless the task explicitly needs it. And finally, we keep the model on track by pointing it to our chosen tech stack. Otherwise, it can start hallucinating library names or using tools you don't want. Coding tasks require reading, editing, and writing files. So the agent needs accessing the file system. One good practice is to have strict permissions and allowing the agent to work only inside a specific working directory. To search files, we can equip the agent with a regex based file search. To search inside a specific file, we can use fuzzy matching. That way, the agent can look for relevant content or patterns, even when there isn't an exact match to the search query. So an AI agent can be defined as an LLM using tools to perform actions in the loop and to accomplish the given task. The loop is just whatever is going on between two user messages. Most tasks need multiple rounds of reasoning, so the model calls tools again and again. Sometimes it can call the same tool repeatedly. But we need to know when to stop. There must be an exit condition. Agents are not perfect. They can fail or might spin out of control while trying to recover errors. They can require evaluation of the results, either by human in the loop or an LLM. The longer and more complex task you assign to your agent, more prone it will be to make errors. Tracking errors systematically is critical because your agent might get stuck trying to fix an error forever. To prevent it, we can keep track of errors. For example, having a maximum retry counter. We can ask the user to provide input and help with the errors. We can also help model by clustering errors together, removing the old ones while still keeping the context clear. You also need to choose the environment where coding agents operate the best. Cursor uses local execution, some agents use Docker, and some like Lovable, AInauts, Perplexity use sandboxes. When deciding about the right environment, we should think of security, like attack surface, and whether we are exposing our operating system. Then there is developer experience. We want to avoid code workarounds and make users happy. We also want our agents to have customized environments to use variety of languages, tools, and pre-installed packages. There needs to be a good maintenance tool, reduce any downtimes of the infrastructure the agent is running on, to provide reliability and good support for end users. And finally, we want the environment to start fast. And we need to do all this at scale and be ready for our agent to serve even millions of end users. In the next lesson with Francesco, you will apply all these concepts to build your first simple coding agent. All right, see you there.
