Agentic Workshop
Module 02 · 50 min

Environment, access and first program

Course by Nello Castellano

The tools change interface, but they share the same foundation: a working directory, real files, a process and credentials to protect. You will learn to read this system before asking for changes.

Lessons

What you will tackle, step by step

2.1

Four surfaces, different responsibilities

CLI, editor, web and API are not four versions of the same screen. They expose different capabilities and responsibilities. The right choice depends on where the real state is and what proof you ultimately need.

The CLI works close to files and makes commands and output visible. The editor extension adds context about the selection and project. The web is suitable for reasoning and sessions not tied to a single shell. The API enables programmatic integrations and requires explicit management of keys and costs.

There is no always better interface. Choose the one that exposes the necessary evidence: to fix a local repository you need files and tests; to discuss an architecture, a documentary context may be enough.

See it in practice · Four steps to prepare release notes

You need to understand Task Notes changes, discuss the message, review a file, and then generate drafts in a repeatable way.

  1. Start from CLI to read the Git history and produce the verifiable list of included commits. If a local draft is enough for you, you can stay here.
  2. If you want to compare two narrative structures, you can use the web by providing the list as context; Don't pretend that the chat sees the repository though.
  3. If you need to refine `RELEASE_NOTES.md` next to edited files, the editor makes it easier to check references and names. You don't have to use the web either.
  4. Introduce API only when the procedure is truly recurring and deserves a script. For this first draft you don't need it yet: don't add automation before you have repeatable work.

Result: You can solve the task with just one surface or combine several. The choice depends on the evidence you need, not on the idea that the path must cross them all.

2.2

Read the terminal without fear

In the terminal you don't have to guess a secret formula. Read the sequence: where you are, which command you ran, what output you received, and the process's exit status.

The prompt indicates that the shell is waiting for a command. The command runs in the current folder, produces output, and ends with a success or error status. These three elements explain most of the early problems.

Before installing everything again, check where you are, what files you see and what version is found. An orderly diagnosis changes one variable at a time and repeats the check that previously failed.

  1. Check the current folder.
  2. List the files.
  3. Check command and version.
  4. Run minimal case.
  5. Read the first useful error.
See it in practice · From “command not found” to first output

In the Task Notes folder you run `python app.py`, but the shell replies `command not found: python`.

  1. Do not touch `app.py`: the error indicates that the shell did not find the program called `python`, so the file was not executed.
  2. Check `command -v python3` to see which program would be started, then `python3 --version`; you now know both the path and the runtime version.
  3. Check `pwd` and `ls` to make sure `app.py` is in the current folder, then run `python3 app.py`.
  4. Note command and successful output as baseline. If the program now fails with a traceback, that is a new level of the problem and should be read separately.

Result: You have fixed the most external cause without reinstalling packages or changing code. The baseline distinguishes the working environment from application problems.

2.3

Credentials and environment variables

An API key allows a program to act and consume resources on your behalf. Treat it like an operational password: it should not become part of your code, Git history, or a shared screenshot.

An API key is a secret, not a preference. It should not be placed in code, shared prompts, or commits. The shell can provide it to the process via an environment variable; a secret manager is best suited in shared environments.

A local file with secrets should be excluded from version control. Before showing logs or screenshots, verify that they do not contain full tokens. If a key is exposed, deleting it from the file is not enough: it must be revoked and replaced.

See it in practice · Move a key out of the script

In `client.py` you find `api_key = "<TEST_KEY>"`. The repository is local, but may be shared later.

  1. Stop using the key and check if the file has already been committed or sent elsewhere; this information determines whether immediate revocation is needed.
  2. Change the code to read `os.environ["ANTHROPIC_API_KEY"]` and produce a clear error when the variable is missing, without printing the value.
  3. Configure the secret in your local environment or chosen secrets manager, and add only a sample file with an empty value.
  4. Search the repository and check relevant diffs and logs to ensure that no full tokens remain in shareable artifacts.

Result: The program still receives the credential, but the secret no longer lives in the source. If it was already exposed, the rotation also closes the previous credential.

2.4

The first execution–error–correction cycle

The first error is not a failure: it is the first reliable observation about the system. If you keep the command and change one cause at a time, the error-correction cycle becomes readable even without great programming experience.

A small program allows you to separate the environment from the application problem. Create it, run it without an agent, observe the output and only then ask for a change. This way you will know if the error belongs to the configuration or to the code.

When a traceback appears, read from below: the error type and message indicate the symptom, the lines above reconstruct the path. Fix one cause at a time and rerun the same command.

See it in practice · A field missing in the first script

The script prints `task["priority"]`, but the created task only contains `title` and `completed`. Python ends with `KeyError: 'priority'`.

  1. Read the last line of the traceback: `KeyError` means that the dictionary — a record made up of key-value pairs — does not have the requested key. Python has started: there is no need to reinstall it.
  2. Go back to the first line of your file indicated in the traceback and compare the reading `task["priority"]` with the object actually created.
  3. Decide the expected behavior: for old tasks the priority must be `normal`; you then use `task.get("priority", "normal")` and add an explicit case.
  4. Rerun exactly the same command and then a second case with priority present, checking both compatibility and the new value.

Result: The program does more than just avoid the error: it has defined behavior for old and new data, supported by two observable cases.

Guided example

First script Task Notes

Let's start with a standalone file that creates a single task.

def create_task(title):
    return {"title": title, "completed": False}

print(create_task("Try the parser"))