The smolagents course: keep the code-agent idea, leave the demo at home

DeepLearning.AI’s course on code agents is built around a bold claim: agents should write their own code rather than call tools one at a time.

Yet the smolagents documentation itself states plainly that, by default, CodeAgent runs LLM-generated code inside your own environment. An FDE taking this course needs to grasp both halves: why code agents are powerful, and where the code they write will actually run.

The full title is Building Code Agents with Hugging Face smolagents, a short intermediate course produced by DeepLearning.AI with Hugging Face.

If you are bringing agents into a customer’s systems, or applying for an applied-AI FDE role, this is a quick way to learn an approach to agent design quite different from familiar JSON tool-calling. You will also learn which parts of that approach are not yet safe to deploy.

Learning from the people who built the library

The instructors are Thomas Wolf, co-founder and CSO of Hugging Face, and Aymeric Roucher, project lead at Hugging Face. You learn the library from the people who made it. That is a strength, and also a reason to keep some distance when they argue for their own design choices.

The course launched in April 2025 and has been revised since; the current version runs 54 minutes, moving from the concept of code agents, through safe code execution and agent evaluation, to building a deep-research agent.

You need only basic Python and some familiarity with LLMs. The course is free during the platform’s beta, though graded assignments require a PRO account, so check the terms before recommending it to colleagues.

Idea one: bundle many steps into one snippet of code

A tool-calling agent works step by step: call a tool, get the result, then decide the next step. A code agent bundles all those calls into a single snippet of code. smolagents offers both: CodeAgent writes its actions as code, while ToolCallingAgent follows the JSON style.

Picture a retail customer that needs an agent to find which of its 5 branches saw the steepest 12-month sales decline. The JSON approach issues 5 calls like these, each a round trip to the model, before it even gets to the comparison:

{"tool": "get_sales", "args": {"branch": "B1", "months": 12}}
{"tool": "get_sales", "args": {"branch": "B2", "months": 12}}
{"tool": "get_sales", "args": {"branch": "B3", "months": 12}}
{"tool": "get_sales", "args": {"branch": "B4", "months": 12}}
{"tool": "get_sales", "args": {"branch": "B5", "months": 12}}

A code agent can do the whole job in one pass: loop over the 5 branches, hold the results in Python variables, compute the percentage change and return the answer.

changes = {}
for b in ["B1", "B2", "B3", "B4", "B5"]:
    s = get_sales(branch=b, months=12)
    changes[b] = (s[-1] - s[0]) / s[0] * 100
worst = min(changes, key=changes.get)
print(worst)

Hugging Face argues that code beats JSON on three counts: composability, better object management and generality. It also notes that programming languages were designed precisely to describe what computers should do.

It is a persuasive design position, but not settled truth. Run both kinds of agent on a real customer task and let the numbers decide.

Idea two: code written by a model is untrusted code

The Secure Code Execution lesson is the part most worth the time for an FDE. Once an agent writes and runs code, any text it reads, from emails and web pages to internal documents, may carry a prompt injection, and the smolagents documentation names exactly this risk.

If the default configuration runs code directly on the customer’s server, a malicious command can go straight into their systems.

The documentation is also candid that a local Python sandbox is not enough. Truly robust isolation means running remotely, for example with E2B or Docker. CodeAgent also supports sandboxes such as Modal and Blaxel.

On a customer site, the first thing to do is ask the security team which containers or sandbox services they permit. That answer shapes the architecture before you even choose a model.

Idea three: multi-agent is easy in a notebook, hard in a sandbox

The final lesson builds a deep-research agent and discusses multi-agent systems. It makes for an appealing demo, but this is where the documentation deserves a careful read. The simple sandbox approach, which sends individual snippets to an isolated environment, does not support multi-agent setups built with managed agents. To make them work, you must put the entire agent system inside the sandbox.

So if a customer wants a multi-agent “research assistant”, the deployment architecture will look very different from the notebook version. Keep the design and evaluation lessons, and plan the infrastructure again from scratch.

The Monitoring and Evaluating lesson is the bridge: if you cannot measure an agent, you cannot prove to a customer that adding a second one helps.

Who should take it, and in what order?

The course suits engineers who are already comfortable calling LLM APIs and want to understand agents at the architectural level. Watch the introduction, then spend real time on Secure Code Execution, and only then move on to evaluation and deep research.

Afterwards, read the official smolagents documentation on secure code execution, which is where the limitations are spelled out most clearly.

For your career, the advice is not to stop at proving you can build an agent. What hiring managers should see is that you know how to take an agent into production safely.

A small repo comparing CodeAgent with ToolCallingAgent on the same task, running in Docker and with a table of evaluation results, will be more convincing than a certificate.

On your CV, write about how you isolated and measured agents, rather than simply saying you “built agents”.

A 54-minute course is enough to change how you think about agents. What earns trust on a customer site is knowing where the code an agent writes will run.