<!-- SPDX-FileCopyrightText: Copyright © 2026 Idiap Research Institute <contact@idiap.ch> SPDX-FileContributor: William Droz <william.droz@idiap.ch> SPDX-License-Identifier: GPL-3.0-only --> <!-- .slide: class="course-title-slide" --> <img class="course-title-logo" src="./logo_hesso.svg" alt="HES-SO Valais-Wallis"> # AI Agents in Python ## Applied LLMs for Life Sciences **From vibe coding to reliable agentic applications** Course overview <p class="course-url"><a href="https://idiap.ch/~wdroz/lifescience_course/">idiap.ch/~wdroz/lifescience_course/</a></p> 14 teaching weeks · 28 hours · life-science students --- # The course promise ## Use LLMs twice—and know which role they are playing <div class="two-col"> <div> **LLM as coding partner** - Turn a scientific question into working Python - Explain unfamiliar code and libraries - Generate tests and fixtures - Diagnose failures from evidence - Improve the project files over time </div> <div> **LLM inside an application** - Start with a tiny browser chat in Week 1 - Return typed scientific information - Call controlled tools - Retrieve supporting evidence - Analyze data with explicit boundaries - Pause for human review </div> </div> The same model may fill both roles. The responsibilities are different. --- # Three course strands ## Independent cases prepare students for three project blocks <div class="course-grid"> <div class="course-card"> <strong>01 · Build with an LLM</strong> <p>Vibe coding, short briefs, context, and inspection of generated changes.</p> </div> <div class="course-card"> <strong>02 · Build an LLM application</strong> <p>A tiny chat in Week 1; plotting agents in Week 4, Connect Four with MCP in Week 5, then verification loops, RAG, and code actions.</p> </div> <div class="course-card"> <strong>03 · Make it scientifically reliable</strong> <p>Provenance, evaluation, audit trails, security boundaries, and human approval.</p> </div> </div> --- # Learning outcomes ## At the end of the course, students can… - Use LLM coding assistants to design, build, test, and package complete, working Python desktop applications - Inspect generated code and verify that the application meets its requirements - Decide when an LLM is appropriate—and when deterministic code is better - Build a typed PydanticAI agent with structured outputs and function tools - Compare PydanticAI Code Mode with controlled tool calling - Build a small agentic RAG assistant with keyword search and traceable evidence --- # Learning outcomes: scientific reliability ## Evidence students must be able to produce - Expose and consume a reusable capability through MCP - Design evaluation cases for scientific correctness and failure behavior - Add a human approval gate before consequential output leaves the application - Produce a reproducible, human-reviewed analysis report with Python, visualizations, and Typst --- # Twenty-eight hours ## Contact time plus guided independent work <div class="course-grid"> <div class="course-card"> <strong>14 × 90 minutes</strong> <p>21 hours in class: concepts, demonstrations, guided coding, and review.</p> </div> <div class="course-card"> <strong>14 × 30 minutes</strong> <p>7 guided hours: one small artifact or project checkpoint each week.</p> </div> <div class="course-card"> <strong>Total · 28 hours</strong> <p>Independent cases through Week 11, then one project built over three weeks.</p> </div> </div> Week numbers count teaching sessions and skip the holiday week. --- # A repeatable 90-minute class ## Concept → demonstration → lab → scientific review <div class="workflow-row"> <div class="workflow-step"><strong>15 min</strong><br>Concept</div> <div class="workflow-arrow">→</div> <div class="workflow-step"><strong>20 min</strong><br>Live demonstration</div> <div class="workflow-arrow">→</div> <div class="workflow-step"><strong>45 min</strong><br>Guided lab</div> <div class="workflow-arrow">→</div> <div class="workflow-step"><strong>10 min</strong><br>Review</div> </div> The 30-minute independent activity records one result, test, decision, or limitation. In Weeks 12–14, the lab and independent activity advance that week's project checkpoint within the same time budget. --- # One dataset, bounded tasks ## Data-analysis cases share a source; Week 5 plays Connect Four <div class="course-grid"> <div class="course-card"> <strong>Data integrity</strong> <p>Schema, historical missing values, repeated identifiers, dates, and provenance.</p> </div> <div class="course-card"> <strong>Analysis</strong> <p>Turnout, yes-vote shares, proposal kinds, distributions, and comparisons.</p> </div> <div class="course-card"> <strong>Reliable applications</strong> <p>Typed outputs, controlled tools, citations, evaluations, and human review.</p> </div> </div> Week 1 uses `agent.to_web()` for everyday questions such as Martigny's population, then asks for the year and source. The chat has no dataset, tools, or structured output; generated source claims still need checking. Independent data cases through Week 11 reuse one licensed dataset and a reliability pattern. Week 4 combines plotting tools and a bounded agent team. Week 5 uses generated Connect Four positions to challenge naive models with structured output and decision APIs, then a coding assistant connected through MCP that may create its own helpers. Week 6 uses tool evidence in a bounded correction loop. Week 7 combines keyword retrieval with an agent that searches, reads, and cites official voting explanations. Semantic search is optional for RAG. Weeks 12–14 build one bounded evaluation project in three blocks, carrying the same implementation forward each week. --- # Swiss Popular Voting · source and scope ## Public national voting records for transferable engineering practice - `dataset/voting.csv`: 692 records, 22 columns; recorded dates 1848–2024 - National proposal records with Italian, French, and German titles - Vote totals, turnout, yes/no shares, recorded outcomes, and cantonal vote totals - `participation`, `ratio_yes`, and `ratio_no` are fractions in [0, 1] - Aggregate observations support descriptive comparisons, not individual-voter claims **Attribution:** Vasco (vascos), *Swiss Popular Voting*, [Kaggle](https://www.kaggle.com/datasets/vascos/swiss-popular-voting), version 1, 24 November 2024, MIT license. [Upstream project](https://github.com/VascoSch92/swiss_popular_voting) draws on Swiss Federal Chancellery records. Preserve attribution in reports and derived data. --- # Read the data card before analyzing ## A licensed dataset still needs verification - Missing values occur in historical and recent records; never replace them silently with zero - `ballots_returned` is entirely empty; `no` repeats and is not a unique row key - `kind` is inferred from title text by the upstream extractor - `domestic_voters` has a documented extraction defect; exclude it from electorate comparisons - Some counts and ratios disagree; retain source values and report consistency warnings - Report each statistic's own nonmissing denominator and the selected date range The [data card and dictionary](https://gitlab.idiap.ch/devel/biss/workshops/aiforlifescience/-/blob/main/dataset/README.md) record the source, units, snapshot, limitations, and license. Repeated dates represent multiple proposals; row order is not a time variable, and cantonal vote totals are not canton microdata. --- # Assessment principles ## Reward evidence—not apparent autonomy <div class="course-grid"> <div class="course-card"> <strong>Correctness + provenance</strong> <p>Are calculations reproducible? Can every claim be traced to data or a source?</p> </div> <div class="course-card"> <strong>Verification + evaluation</strong> <p>Do tests cover normal cases, edge cases, and known failure modes?</p> </div> <div class="course-card"> <strong>Design + judgment</strong> <p>Are tool boundaries, human decisions, limitations, and risks explicit?</p> </div> </div> --- # Evaluation project ## Build a human-reviewed scientific report assistant <div class="workflow-row"> <div class="workflow-step">Question +<br>validated data</div> <div class="workflow-arrow">→</div> <div class="workflow-step">Python analysis +<br>X candidates</div> <div class="workflow-arrow">→</div> <div class="workflow-step human-gate"><strong>Student choice</strong><br>compare · select · order</div> <div class="workflow-arrow">→</div> <div class="workflow-step">Structured<br>report draft</div> <div class="workflow-arrow">→</div> <div class="workflow-step human-gate"><strong>Human review</strong><br>review · revise · approve</div> <div class="workflow-arrow">→</div> <div class="workflow-step">Typst source +<br>final PDF</div> </div> The model may propose analysis queries, prose and layout; submitted numbers and figures must come from reproducible Python computation. Confirm selected evidence before drafting; explicitly approve the final version before final export. Editing alone is not approval. --- # Evaluation project · three weekly blocks ## The same application grows at each checkpoint | Week | Block | Checkpoint | | --- | --- | --- | | **12** | **1 · Reproducible evidence** | Validated data, deterministic results, **X ≥ 5** purposeful figures, initial tests and provenance | | **13** | **2 · Selection and draft** | Confirmed selection, order and notes, structured LLM draft from selected evidence, Typst preview marked as a draft | | **14** | **3 · Review and export** | Human review, explicit approval tied to the exported version and enforced in Python, final Typst/PDF and reproducible package | The checkpoints replace the weekly lab deliverables within the existing hours. Earlier cases provide preparation and reusable artifacts. Week 7 RAG, Week 9 MCP queries and plots, and Weeks 10–11 evaluation and review remain independent cases before the evaluation project. --- # Evaluation project · scope ## One analysis and one story are sufficient - **Python required** for application logic and analysis; **NiceGUI recommended** - Other UI frameworks are allowed, including a separate frontend with a Python backend - Shared voting CSV, one question, result table, configurable **X ≥ 5** purposeful figures - Confirm one or more figures, their order when multiple, and notes on observations and a caveat - Structured LLM draft from selected evidence, human review, audit and reproducible Typst/PDF export Read-only agent queries and plots from their computed results, general CSV exploration, AI judging, multiple stories and advanced review are bonuses. They are not needed for full marks. The project brief (not yet released) defines the complete scope and rubric; the Rust/Dioxus teacher app is a behavior reference. --- # Engineering compass for the course ## Each block adds one kind of control | Weeks | Engineering focus | Control added | | --- | --- | --- | | **1–4** | First chat app + model limits · levels 2–4 | Intent, context, reversibility, verification | | **5–7** | Agent anatomy + harness · levels 5–6 | Raw-CSV limits, structured output, and typed tools | | **8** | Code Mode and a ready-made controlled-tool comparison | Explicit trade-off between flexibility and execution risk | | **9–11** | Two-stage RAG + MCP | Evidence-grounded answers and reusable capability boundaries | | **12–14** | Three incremental project blocks | Reproducible evidence, confirmed draft, reviewed export | The weekly cases develop the controls that students integrate during the final three project blocks. <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> --- # Course model access ## The instructor supplies PPQ keys for agents in your code - Students need no PPQ signup or payment to use their supplied key. - Copy `.env.example` to `.env` and replace only `LLM_API_KEY`. - The course endpoint is `https://api.ppq.ai`; the default model is `deepseek/deepseek-v4.1-flash`, with `openai/gpt-5.6-luna` as an alternative. - The instructor communicates each key's spending allowance and expiration date. Save and restart the app after configuration changes. Keep keys out of prompts, screenshots, and submissions. Use your own subscription or free tier for coding assistance; the course key is reserved for the agents your code runs. [Connection steps and troubleshooting](setup.html) --- # Course design decisions still to finalize ## Before teaching the course - Cohort prerequisites and preparatory material - Placement in the Life Sciences Engineering study plan and expected Python level - Institutional data policy for the supplied PPQ access - How students verify attribution and documented data caveats in derived artifacts - Human-review roles and authorization model --- # Weekly teaching decks ## One deck for each of the fourteen weeks [Open the 14-week course map](course_map.html) [Begin Week 1: First PydanticAI chat and LLM literacy](week_01.html) [Choose a coding assistant](coding_assistants.html) Read the evaluation project requirements and rubric (not yet released)