Slides

# Vibe coding for exploration

## Generate a small data checker and read what was generated

---

# Before we begin

## Update your course folder

Open a terminal in your course folder (the one containing `pyproject.toml`)
and run:

```bash
uv run scripts/update.py
```

Wait for the command to finish and read its summary before starting the weekly lab.
If it reports files to review, compare your work with the incoming copies in
`.course-updates/`.

---

# Week 2 · concepts

## Fast feedback, limited trust

- Vibe coding: describing intent and letting an LLM generate much of the code
- Coding assistant versus product model
- An assistant with access to the course folder versus a disconnected chat
- Small prompts, inspectable code changes, and reversible edits
- Asking for explanations at the student’s level
- Reading generated inputs, transformations, outputs, and dependencies
- Recognizing code that runs but answers the wrong scientific question

**Rule:** exploration may be fast; scientific acceptance must be deliberate.

---

# 8 levels of agentic engineering

## From local assistance to coordinated autonomy

<div class="levels-track" aria-label="Eight levels of agentic engineering">
  <div class="levels-node"><span class="levels-dot">1</span><span class="levels-label">Tab complete</span></div>
  <div class="levels-node"><span class="levels-dot">2</span><span class="levels-label">Agent workspace</span></div>
  <div class="levels-node"><span class="levels-dot">3</span><span class="levels-label">Context</span></div>
  <div class="levels-node"><span class="levels-dot">4</span><span class="levels-label">Compound</span></div>
  <div class="levels-node"><span class="levels-dot">5</span><span class="levels-label">Tools / skills</span></div>
  <div class="levels-node"><span class="levels-dot">6</span><span class="levels-label">Harness</span></div>
  <div class="levels-node"><span class="levels-dot">7</span><span class="levels-label">Background</span></div>
  <div class="levels-node"><span class="levels-dot">8</span><span class="levels-label">Agent teams</span></div>
</div>

<div class="levels-overview-grid">
  <div class="levels-overview-card"><strong>1–2 · Assist</strong><span>Complete local code, then inspect and edit files in the course folder.</span></div>
  <div class="levels-overview-card"><strong>3–4 · Context</strong><span>Provide relevant evidence now; preserve lessons for later runs.</span></div>
  <div class="levels-overview-card"><strong>5–6 · Capability</strong><span>Add controlled actions, then feedback that detects mistakes.</span></div>
  <div class="levels-overview-card"><strong>7–8 · Autonomy</strong><span>Run asynchronously, then coordinate multiple specialized agents.</span></div>
</div>

<p class="levels-source">Adapted from Bassim Eledath, <a href="https://www.bassimeledath.com/blog/levels-of-agentic-engineering">The 8 Levels of Agentic Engineering</a>. The levels describe engineering practice, not the quality of the final result.</p>

---

# Level 1 · Tab completion

## The model completes the code immediately in front of it

<div class="levels-track" aria-hidden="true">
  <div class="levels-node"><span class="levels-dot">1</span><span class="levels-label">Tab complete</span></div><div class="levels-node"><span class="levels-dot">2</span><span class="levels-label">Agent workspace</span></div><div class="levels-node"><span class="levels-dot">3</span><span class="levels-label">Context</span></div><div class="levels-node"><span class="levels-dot">4</span><span class="levels-label">Compound</span></div><div class="levels-node"><span class="levels-dot">5</span><span class="levels-label">Tools / skills</span></div><div class="levels-node"><span class="levels-dot">6</span><span class="levels-label">Harness</span></div><div class="levels-node"><span class="levels-dot">7</span><span class="levels-label">Background</span></div><div class="levels-node"><span class="levels-dot">8</span><span class="levels-label">Agent teams</span></div>
</div>

<p class="levels-point">Useful for a pandas expression or function body; weak when the task depends on files, provenance, or design decisions elsewhere.</p>

- The student still decomposes the task and writes the surrounding structure
- Fast and low-friction, but its effective context is local
- Suggested code inherits hidden assumptions and still needs inspection

<p class="levels-source">Adapted from Bassim Eledath, <a href="https://www.bassimeledath.com/blog/levels-of-agentic-engineering">The 8 Levels of Agentic Engineering</a>.</p>

<aside class="notes">
Adapted from Bassim Eledath, [The 8 Levels of Agentic Engineering](https://www.bassimeledath.com/blog/levels-of-agentic-engineering).
</aside>

---

# Level 2 · Agent workspace

## Chat can inspect, edit, and run files in the course folder

<p class="levels-point">The assistant can connect a request to the data checker, its tests, and documentation. Check which files it actually uses.</p>

- Multi-file changes become possible
- Review the plan and compare code before and after each change
- Keep numbered backups of working files in a separate folder so you can restore them

**Course entry point:** week 2 uses this level, then immediately adds inspection and tests.

<p class="levels-source">Adapted from Bassim Eledath, <a href="https://www.bassimeledath.com/blog/levels-of-agentic-engineering">The 8 Levels of Agentic Engineering</a>.</p>

<aside class="notes">
Adapted from Bassim Eledath, [The 8 Levels of Agentic Engineering](https://www.bassimeledath.com/blog/levels-of-agentic-engineering).
</aside>

---

# Would you trust this calculation?

<video class="course-video" controls muted playsinline preload="metadata" width="2560" height="1440" poster="assets/videos/week-02-generated-calculation.jpg" aria-label="Demonstration: a chat gives an average from the voting CSV, adds decimal places when asked for an exact answer, then changes the number after being challenged.">
  <source src="assets/videos/week-02-generated-calculation.mp4" type="video/mp4">
  <a href="assets/videos/week-02-generated-calculation.mp4">Open the calculation demonstration video</a>.
</video>

<p class="video-demo-link"><a href="assets/videos/week-02-generated-calculation.mp4">Open video separately</a> · 50 seconds</p>

<aside class="notes">
Reused unchanged from the AI Days 2026 workshop, Exercise 03: naive data analysis.
Source: https://www.idiap.ch/~wdroz/workshop_videos/compressed/workshop_demo_03.mp4
The application supplies the voting CSV as text to the model. The recording shows
generated answers; it does not show an independently verified calculation. The
model changes its claimed average after “Are you sure?” and supplies a claimed
nonmissing row count. Neither claim is established by the recording.

Play the clip, then use the next slide for discussion. Allow 4–5 minutes for the
clip and discussion together. The player starts muted; the original file,
including its audio track, has not been edited. The visible model and interface
belong to the earlier workshop; students use this course's setup instructions.
The source data is Vasco (vascos), Swiss Popular Voting, Kaggle, MIT license;
see dataset/README.md. Its rows are national proposal records, not individual voters.
</aside>

---

# What evidence would you need?

## An independent check needs a reproducible calculation

The answer changes after “Are you sure?”

**Discuss:** what would establish which result, if either, is correct?

- Identify the column, included rows, and rule for missing values
- Compute the result in Python and report the nonmissing row count
- Inspect the code and compare the result with an independent check

Our next step is to build a CSV checker with a coding assistant, inspect its
changes, and test a deliberately altered copy of the data.

<aside class="notes">
Pause for students' suggestions before discussing the checks. More decimal places
and a confident correction do not establish correctness. For total_voters, each
record describes the eligible electorate for a proposal, not how many people
actually cast a vote. A mean across proposals is not a count of unique voters.
The Week 2 lab checks the structure of the CSV; checking the data is one step
toward a trustworthy analysis. Week 4 uses local deterministic plotting tools through PydanticAI agents. Keep today's focus on directing and verifying code.
</aside>

---

# The coding-assistant loop

## The workflow students use every week

<div class="workflow-row">
  <div class="workflow-step">Scientific<br><strong>question</strong></div>
  <div class="workflow-arrow">→</div>
  <div class="workflow-step">Written<br><strong>specification</strong></div>
  <div class="workflow-arrow">→</div>
  <div class="workflow-step">LLM-generated<br><strong>change</strong></div>
  <div class="workflow-arrow">→</div>
  <div class="workflow-step">Student<br><strong>inspection</strong></div>
  <div class="workflow-arrow">→</div>
  <div class="workflow-step">Tests +<br><strong>evidence</strong></div>
  <div class="workflow-arrow">↺</div>
</div>

**Vibe coding starts the exploration. Verification decides what survives.**

[Choose a coding assistant: free access, pricing, and a student budget](coding_assistants.html)

---

# Week 2 · lab

## Generate a small voting-data checker

**By the end of class, your checker should:**

- Validate all 22 columns, dates, nullable counts, categories, and fractions in [0, 1]
- Report historical gaps, repeated `no` values, and the empty `ballots_returned` column
- Accept the supplied snapshot and reject a deliberately altered copy
- Leave the original CSV unchanged

You direct the coding assistant, inspect its changes, and keep the evidence.
The checker runs locally without an application API key.

<aside class="notes">
Plan for 90 minutes in total, including the earlier concept slides and video:
0–20 minutes: update the course folder, concepts, the 50-second clip, and discussion
(4–5 minutes for the clip and discussion together); 20–30: locate files
and observe the unfinished starter; 30–50: specify and generate the three TODO
functions; 50–65: run the baseline and inspect the changed code; 65–85: create
the altered copy, predict, run, and discuss its rejection; 85–90: save evidence.
The separate 30-minute guided activity adds one more failure case.

Demonstrate each transition before students try it. Help with access and setup
early; students can pair on a working machine while a setup issue is resolved.
If a coding assistant has no access to local files, supply the starter and data
dictionary as context, then review and save its proposed code in the editor.
Use students' own coding-assistant access; no PPQ key is needed by this checker.
</aside>

---

# Prepare your Day 02 folder

## Keep working in the course folder from Day 01

Use the course folder you updated at the start of the session.

Starting fresh? Download and extract the [course archive (.zip)](https://www.idiap.ch/~wdroz/lifescience_course/aiforlifescience.zip).
Open the extracted folder containing `pyproject.toml` in your editor.

**Checkpoint:** locate `src/aiforlifescience/exercises/02_voting_data_checker.py`.
All commands today run from this course folder in PowerShell, zsh, or bash.

[Computer setup and command reference](setup.html)

<aside class="notes">
Check that the current public release includes Week 2 before class. If an older
download has no update script, use the fresh ZIP in a separate folder and keep
the student's earlier work. Confirm pwd/ls as needed. Do not extract the new ZIP
on top of a student's edited folder. The updater prints conflicts for review.
</aside>

---

# Open three local files

## Give the assistant the same evidence you inspect

| File in your course folder | Purpose |
| --- | --- |
| `dataset/voting.csv` | The original, unchanged snapshot |
| `dataset/README.md` | Provenance, all 22 columns, and known limitations |
| `src/aiforlifescience/exercises/02_voting_data_checker.py` | Your starter, with three TODO functions |

Read the starter's TODOs and the data dictionary together.
Blank cells are missing, `participation` is a fraction, and `no` can repeat.

In the editor, create `artifacts/week02/` and save an initial copy of the starter
there as `02_voting_data_checker_00.py` for comparison.
Continue editing the file under `exercises/`.

<aside class="notes">
These are local paths in the extracted ZIP; students do not need access to the
private GitLab repository. Show the folders in the editor's file explorer.
The numbered copy is a checkpoint for comparison and restoration, not the file
to execute: the starter's default dataset location depends on its original path.
Point out read_voting_data, validate_voting_data, and report_voting_data.
</aside>

---

# Run the unfinished starter

## A TODO has a visible consequence

In the terminal, run:

```bash
uv run python src/aiforlifescience/exercises/02_voting_data_checker.py
```

**Expected before implementation:**

```text
NotImplementedError: Read voting.csv with csv.DictReader
```

This is the starter's deliberate stopping point. It asks you to implement
the first TODO; it does not mean that the dataset is invalid.

**Find it:** which line raises this exception, and which function calls it?

---

# Ask for the complete implementation

## Turn the TODOs into an explicit request

Select the starter under `exercises/` in your coding assistant and supply the data dictionary:

> Implement all three TODO functions in the selected exercise file.
> Briefly explain your approach, then implement the TODO requirements
> using Python's standard library.
> Read `dataset/README.md` and preserve `dataset/voting.csv` unchanged.
> Do not read or copy the reference solution. Keep missing values distinct
> from zero and repeated proposal numbers distinct from duplicate rows.

Let the assistant edit the starter, then review its explanation and changes.
Save the file and compare it with your initial checkpoint.

<aside class="notes">
The repository's AGENTS.md supports direct implementation, including TODOs.
Students can ask the assistant to build, debug, and test the code, then inspect
the changes and check the results themselves.
Ask for an explanation of one function at a time after generation; do not treat
the assistant's claim that the code works as test evidence.
</aside>

---

# Check the original snapshot

## Run your saved exercise file again

```bash
uv run python src/aiforlifescience/exercises/02_voting_data_checker.py
```

**Expected:** `VALID`, **692 rows**, and successful validation of all **22 columns**.
The report should include:

```text
ballots_returned: 692/692 missing (entire column missing)
Repeated proposal numbers: 16 (16 additional rows share a number).
Exact duplicate rows beyond the first occurrence: 0.
```

Other missing-value counts should match `dataset/README.md`.
The report must state that no values were filled and no rows were removed.

<aside class="notes">
The starter's main function prints the resolved path and the number of rows;
the validator establishes that exactly the 22 required columns occur once each.
Report wording can vary, but these facts must agree. If the original is rejected,
inspect the reported column and the dictionary before changing the validator.
Do not change source data to make the program pass. The exercise file is the
one being run; running the supplied solution would not verify the student's work.
</aside>

---

# Inspect what generated code accepts

## Connect each claim to a condition in the code

- Where does the code distinguish an empty cell from a malformed number?
- What happens to `participation = 45`, `total_yes = 10.5`, or an impossible date?
- Why are fractional canton totals and repeated `no` values allowed?
- Does the code leave counts and recorded outcomes as stored?

Ask the assistant to explain unfamiliar lines, then check its explanation
against the code and data dictionary yourself.

**Evidence so far:** the original passes. We still need a case that should fail.
Structural validity alone does not establish historical accuracy.

---

# Make a controlled failure case

## Change one value in a separate copy

In the editor, create `artifacts/week02/make_bad_copy.py`.
Paste the Python code from the next slide and save it.

The helper reads `dataset/voting.csv`, changes the first proposal's
`participation` to `45`, and writes `artifacts/week02/bad.csv`.
It opens the original only for reading; rerunning it replaces only the test copy.

**Predict before running:** a fraction must be in [0, 1].
Which CSV row should the checker reject, and what should its message say?

<aside class="notes">
The CSV header is row 1, so the first proposal is row 2. The helper is deliberately
small, deterministic test preparation, not an implementation of the checker.
Explain csv.DictReader/DictWriter and the target path before running it.
Use the same source snapshot each time so there is exactly one deliberate change.
</aside>

---

# Save the helper in the editor

## Python code for `artifacts/week02/make_bad_copy.py`

```python
import csv
from pathlib import Path

source = Path("dataset/voting.csv")
target = Path("artifacts/week02/bad.csv")
with source.open(encoding="utf-8", newline="") as stream:
    reader = csv.DictReader(stream)
    columns = reader.fieldnames
    rows = list(reader)
rows[0]["participation"] = "45"
target.parent.mkdir(parents=True, exist_ok=True)
with target.open("w", encoding="utf-8", newline="") as stream:
    writer = csv.DictWriter(stream, fieldnames=columns)
    writer.writeheader()
    writer.writerows(rows)
print(target)
```

---

# Test your checker on the copy

## Run these two commands from the course folder

```bash
uv run python artifacts/week02/make_bad_copy.py
uv run python src/aiforlifescience/exercises/02_voting_data_checker.py artifacts/week02/bad.csv
```

The final argument tells the checker which CSV to read.

**Expected:** `INVALID`, followed by a row-specific error such as:

```text
row 2: participation must be a fraction from 0 to 1
```

The program should return a failing exit code, **1**.
If it prints `VALID`, inspect and fix the validation condition, then rerun
both this case and the original snapshot.

<aside class="notes">
Type each command on one line; do not copy the expected-output text as a command.
The initial NotImplementedError was an unfinished function; this INVALID result
is an implemented checker correctly rejecting bad input. Make that distinction
explicit. These commands test the student's file under exercises/. Repository
pytest checks currently load the reference solution under solutions/; a passing
pytest run alone is not evidence that the student's implementation works.
</aside>

---

# Save your Day 02 evidence

## A small checkpoint you can explain and rerun

Keep these files in `artifacts/week02/`:

- `02_voting_data_checker_00.py`: the initial starter copy
- `02_voting_data_checker_01.py`: a copy of your implemented checker
- `make_bad_copy.py` and `bad.csv`: reproducible test preparation and input
- `notes.md`: your prompt, run commands, expected and observed results,
  and one code condition you inspected

**Checkpoint:** the original passes, the altered copy fails at row 2,
and you can explain why. Continue running the checker under `exercises/`.

In your notes, distinguish the assistant's proposed code from results you
computed locally. Credit Vasco (vascos), *Swiss Popular Voting*, Kaggle, MIT;
use the full attribution from `dataset/README.md`.

---

# Week 2 · guided work

## Make one assumption testable

**30-minute guided work**

- **5 minutes:** choose one new failure: an impossible date, a malformed count,
  or a missing required title. Write the expected row-specific error first.
- **10 minutes:** adapt the helper to write a new copy from the original CSV,
  change only your chosen value, and run your exercise against it.
- **10 minutes:** inspect the relevant condition, fix any missed check, and
  rerun the original snapshot and both altered copies.
- **5 minutes:** save the helper, input, final checker checkpoint, and results
  in `artifacts/week02/`; extend `notes.md` with the finding and explanation.

If the first version catches the new failure, record that result honestly
and explain which condition caught it. If it misses it, record the before/after.

<aside class="notes">
Use separate helper/input filenames, for example make_bad_date.py and
bad_date.csv, and update the target path and one field assignment together.
Always read the original dataset/voting.csv, so previous alterations do not
accumulate. Do not classify an expected blank optional value or a repeated
proposal number as a failure. Check dataset/README.md for permitted missingness.
Save a numbered final checker copy after any fix, retaining the initial version
for comparison. The local checkpoint is the deliverable to show the instructor;
no separate online submission is required by this activity.
</aside>

---

# Week 2: course navigation

[Course overview](presentation.html)

[14-week course map](course_map.html)

[Previous: Week 1](week_01.html)

[Next: Week 3](week_03.html)