Module 00 · 85 min

Before Claude Code: AI, LLM, agents and tools

This is the starting point for those who have never used a language model, a terminal or Git. You don't have to know how to program. Let's build the vocabulary and mental model first; you'll eventually simulate the decisions needed to give an agent a small, controlled mission.

Lessons

What you will tackle, step by step

0.1

The map: AI, machine learning, LLM and Claude Code

If you start from scratch, the first difficulty is not technical: it is understanding that very similar words indicate different things. Let's put things in order now, so later you will always know who is producing a response and who is actually acting on your files.

Artificial intelligence, or AI, is a broad name for systems that perform tasks associated with human intelligence, such as recognizing images, predicting values, or producing text. Machine learning is a family of techniques by which a system learns regularities from many examples rather than receiving a written rule for each case. Generative AI is the part that creates new content, such as text, images, audio or code.

A Large Language Model, abbreviated LLM, is a generative model trained on large amounts of text and code. Claude is a family of LLMs. Claude Code is an application that uses a Claude model and adds work instructions, controlled access to tools, and a verification cycle to work on a project. These names are not synonymous: Claude Code links the model to operational capabilities that the LLM alone does not possess.

Start from the largest set: AI.
Inside you will find machine learning and, among its uses, generative AI.
An LLM is a type of generative model specialized in language.
Claude is a family of LLMs; Claude Code links them to a work environment.

See it in practice · Same problem, four different levels

Imagine a small online store that receives customer messages and has an FAQ page to update.

A machine learning classifier assigns a label to each message, for example "return" or "payment": it recognizes a category, it does not write the response.
An LLM receives the customer's text and offers a polite response: it generates language, but has not yet read the actual FAQ or modified the site.
Claude Code, if authorized in the project folder, can search for the FAQ, show where an old rule appears and prepare a change.
A test or check in the browser finally verifies that the page shows the correct text: this evidence comes from the real system, not from how confidently the model writes.

Result: The word “AI” no longer hides a single magical object: you can indicate the system it classifies, the model it proposes, the application it orchestrates and the tool it executes.

0.2

How a response is generated: tokens, probabilities, and limits

A smooth response may seem like the result of infallible reasoning. In reality it arises from many small successive predictions. Understanding this step avoids the most common mistake: mistaking a well-written sentence for an already verified fact.

An LLM does not search for a complete answer in an archive. It receives a sequence, divides it into units called tokens and estimates which token is plausible after those already present. A token can be a short word, a part of a word, a sign or a space: it does not always coincide with a word. The response is generated one token at a time, repeating the prediction many times.

During training, the model learned statistical patterns in language and code. This lets it explain, summarize, and propose solutions, but it does not give the model awareness, intentions, or automatic access to current facts. A very confident sentence can still be wrong. Small differences in request or generation can also produce different responses.

The model is therefore useful as an engine of interpretation and proposal, not as an infallible source. For a real task you need to provide it with the correct context and compare the output with external evidence: existing files, reliable documentation, tests or direct observations.

See it in practice · The refund policy that was not in context

Ask the model: “After how many days do we refund a subscription?” without attaching the regulations of your service.

The model recognizes a typical customer-support question and associates frequent expressions such as “14 days” or “30 days”.
Produces “Refund is available within 30 days” with a clear tone, even if it didn't follow your company's rule.
You ask which document supports the number; the model cannot indicate a real source present in the context.
Provide `rimborsi.md`, where the limit is 10 days, and ask for a response that cites the section: now the data can be compared to a concrete artifact.

Result: The quality of the sentence remains useful, but the conclusion only becomes acceptable when the number is anchored in the correct source.

0.3

Prompt, context, window and memory are not the same thing

Prompt, context and memory are often used as if they were the same thing. They are not. The prompt is the request you make now; context is what the model can see now; memory is a way to store and retrieve some information over time.

The prompt is what you ask at a given time. The context is the set of information that the model can use while generating the response: the available conversation, the instructions, the provided files and the results of the tools. The context window limits how much of this information can be available at once. As the work grows, some parts may be summarized, excluded, or become less relevant.

Memory is information stored and retrieved between moments or sessions; it's not the entire context window and doesn't mean the model remembers everything. Even a saved piece of information may be incomplete or may not be retrieved. Later you will use instruction files and memory mechanisms, but you will always have to check that the important rule is really present in the current context.

Good context is not as long as possible. It contains the facts that change a decision: goal, actual state, constraints, relevant examples and success criterion. Old or conflicting information can make the response as bad as missing information.

See it in practice · Resume Task Notes the next day

Yesterday you decided that dates are saved in the `YYYY-MM-DD` format. Today open a new conversation and ask to add sorting.

The new prompt only says “sort tasks by date”: it describes the current task, but not the agreed format.
A memory may report yesterday's decision, but you cannot assume that it has been saved, retrieved, or remained updated.
Put the rule in `README.md` or in the project instructions and ask the agent to read that file before scheduling.
The agent cites the real format, checks some existing data and proposes a consistent sorting, reporting any invalid dates.

Result: Continuity does not depend on an invisible memory: it depends on a written, legible and controllable decision in the project workspace.

0.4

Hallucinations, uncertainty and evidence

When a model invents a filename or function, it's not trying to trick you: it's filling in a gap with a plausible continuation. For you, however, the practical effect is the same as false information. We therefore need a method to recognize it before it drives a change.

A hallucination occurs when the model produces a plausible statement that is not supported by facts: it may invent a file, mention a function that does not exist, or describe a test that was never run. It's not an intentional lie; it is the effect of generating the linguistically plausible continuation without sufficient verification.

Reduce risk by asking the system to observe before concluding. If it describes a project, it must identify the actual files it read. If it proposes a change, it must show the diff. If it says the behavior works, it must run a relevant check and report the outcome. One piece of evidence does not make everything else true: it must exactly support the stated conclusion.

Separate what has been observed from what is only hypothesized.
Ask for the source or artifact that supports the conclusion.
Check that the test actually measures the promised behavior.
Keep concerns, limitations and checks not performed explicit.

See it in practice · The phantom configuration file

Task Notes shows the wrong title. Without reading the project, someone suggests changing `config.yml`.

First ask for a list of files and a search for the visible text; do not authorize any changes yet.
Search shows that `config.yml` does not exist and that the title is written in `templates/header.html`.
The agent reformulates the hypothesis, indicates the observed line and proposes to change only that text.
After editing, you check the diff — the line-by-line comparison between before and after — and open the page: the diff shows the range, the browser shows the visible result.

Result: The initial hypothesis is safely discarded, and the final conclusion is supported by two checks that measure different aspects.

0.5

From chatbot to agent: who decides and who acts

An agent is not simply a chatbot that writes more. It is a system that can observe a result, choose a step, use a tool and decide what to do next. The decisive part is the cycle, not the amount of autonomy declared.

In a chat, the typical cycle is question and answer. An agent instead receives a goal, interprets the context, chooses an action, uses a tool, observes the result and decides whether to stop or continue. We can describe it like this: agent = LLM + instructions + context + tools + feedback + permissions + stopping condition.

The model proposes the next step; the tool performs the concrete action. Reading a file, running a test or searching the web doesn't happen just because the model describes it: you need a connected, authorized capability. The result of the tool returns to the context, so the agent can correct the plan.

Autonomy does not mean absence of control. You define the objective, scope, checkpoints and when an outcome can be accepted. A reliable agent must also know when to stop: when permission is missing, something unexpected appears, or the available evidence is not strong enough.

See it in practice · Fix a button without going blind

On the Task Notes page the “Save” button does not react after entering a title.

The agent inspects the files and reproduces the symptom; it discovers an error related to the `saveTask` function in the console.
It proposes a limited patch to the button handler and shows you the plan before writing.
The tool modifies the file and the test runner checks the save flow; the result reports yet another error.
The agent does not declare success: it updates the hypothesis or stops if the second correction would go outside the agreed scope.

Result: The path remains readable even when the first attempt is not enough. Failure becomes feedback, not something to hide.

0.6

Tools, permissions and security boundaries

A permission is not a bureaucratic button you click just to continue. It is the boundary within which an error can produce real effects. Before granting it you must understand the action, its destination, and whether recovery is possible.

A tool is a bridge to an action: it can read a folder, modify a file, run a command, or contact a service. A permission defines which actions are allowed. However, authorizing a tool does not prove that the action is correct, and a person's approval does not replace verification of the result.

Grant only what is necessary. To understand a project, start with read-only access. To correct a local file, limit write access to the project folder. Publishing, deleting, or sending data externally requires an explicit checkpoint. The more extensive, irreversible or external the action, the stronger human control must be.

Before approving, read the proposed action in concrete terms: which command, which files, which destination and which effect. If you don't understand them, ask for an explanation or a simulation. Stopping is not a failure: it is the correct behavior when authority or information is not enough.

Identify the actual action behind the permission request.
Limit permission to the folder, command and time needed.
Provide separate confirmation for remote or irreversible actions.
Check the outcome with a test independent of approval.

See it in practice · Correct a guide without publishing it

You want to fix three typos in the documentation. The project also has credentials that allow the deployment of the public site.

First allow reading only of the `docs` folder and ask to indicate the three points found.
After checking, authorize writing only to the listed files; do not grant access to deployment credentials.
The agent edits the copy and shows a limited diff, without running any publishing commands.
You inspect the local preview; any deployment remains a separate action, with a specific confirmation.

Result: The mission ends with the files ready and verified, but without any unwanted external effects. The more powerful ability was not needed and was not granted.

0.7

Files, folders, the terminal, and Git: your workspace

The terminal may seem hostile because it responds with dry text, but its behavior is regular: it executes a command in a folder and returns a result. Git adds a history of changes. Together they allow you to see what happened, rather than relying on memory.

A project is a folder that contains files and, often, other folders. A path indicates where an item is located. The terminal is a text-based interface: it displays a prompt, receives a command, executes it in the current folder, and returns output plus a success or error status. You don't have to memorize many commands; you need to know where you are and read what happened.

Git records the history of a project's files. `git status` distinguishes untracked files, staged changes, and changes that are still outside the next commit. By default, `git diff` shows unstaged changes to tracked files; `git diff --staged` shows staged changes. A commit intentionally records the staged state with a message. Git is not automatically a full backup: before restoring or deleting, always check the real status.

For the first mission you only need four concepts: current folder, modified file, observable difference and performed check. The agent can type or propose commands, but the output belongs to the real process. If the command fails, that failure is information to be read, not text to be hidden.

See it in practice · The program exists, but the terminal cannot find it

You created `/projects/task-notes/app.py`, but the shell is still working in the `/projects` folder.

Run `pwd` and read `/projects`: now you know that the current folder is not the app folder.
Run `ls` and see the `task-notes` folder, not the `app.py` file; the error is consistent with what the process can see.
Enter with `cd task-notes`, repeat `ls` and then `python3 app.py`; the program produces the expected output.
Run `git status` and `git diff` to distinguish simply starting the program from any changes already present in the files.

Result: You have not reinstalled Python or changed the code. You have isolated the cause by reading folder, file and output in the correct order.

0.8

The first guided mission, from observation to test

Now let's put the pieces together into a tiny mission. The goal is not to demonstrate that the agent can do a lot; it is to demonstrate that you can keep the goal, authorization, change and evidence visible from start to finish.

In this guided simulation, a small local app called Task Notes needs to change only one label: from “My Things” to “My Tasks”. You don't have to own the app or run commands. You use the scenario to work through the decisions in order; in Module 2 you will apply the same method to a real environment.

The sequence begins with a read-only inspection. Ask where the text appears and request a one-line plan. Allow limited write access, plan to inspect the diff, and choose relevant evidence. Accept the work only if the files, the diff, and the behavior tell the same story.

In the scenario, place the mission in the Task Notes folder and identify the available files.
Formulate the read-only request: “Find where ‘My Things’ appears. Don’t change anything.”
Plan to compare the response with the cited file before authorizing changes.
Make a limited change to that label and request a short plan.
Choose the minimum permission: writing to the local project folder only.
Request as evidence a `git diff` limited to what you asked for.
Choose a test or visible-result check as your second piece of evidence.
Define the criterion: “My Tasks” appears and the rest continues to work.
Set a stop: when faced with an unexpected change, do not continue and ask for an explanation.

See it in practice · The search finds two labels: which one needs to be changed?

Task Notes already works. You only want to change the page label and you don't yet know the structure of the project.

Ask the agent, in read-only mode, to search for the exact phrase and report the file and line; it finds one occurrence in `templates/index.html` and one in `tests/test_home.py`.
You do not allow a global replacement. You ask which text actually lands on the page and discover that the second result only describes the test's expectation.
Authorize the template change and consistent updating of the test, without touching logic, data or dependencies; then you check each line of the diff.
Open the page and run the test: the new label is visible, the test expectation is updated, and normal saving of a task continues to work.

Result: The first answer wasn't enough, so you narrowed down the problem instead of guessing. You accept the mission because files, diffs, tests, and visible behavior tell the same story.

Guided example

Simulate the first complete assignment

Teaching scenario: Task Notes already works locally. You want to change just one label without touching data, logic or external services.

Goal: show “My tasks” instead of “My things”.
Context: work in the local Task Notes folder.
Observe first: find the text and identify the file, without changing anything.
Scope: after I confirm, change only the necessary label.
Do not: publish, add dependencies, or perform remote actions.
Verification: show the diff and run the available check; state what you did not verify.