🖥️ Lecture slides — Session 03 (Mon Oct 5)
This page is the course policy on AI use, and the practice that goes with it. Read it once now, and again before you submit anything.
The tools of 2026¶
The assistants you will use in this course are not autocomplete. An agentic AI assistant, running in your editor or terminal, can:
- read your entire repository, including notebooks, data files, and git history;
- run code, read the error messages, and revise;
- edit files across the project and propose multi-file changes;
- open branches and pull requests on GitHub.
Concretely, this means tools of the Claude Code / Copilot agent family, working in VS Code, JupyterLab, or a terminal. Given a prompt like “load the GNSS series from 1.7 and fit a linear trend to the east component”, such a tool will often produce a working notebook in one pass. That capability is why this course teaches you to work with these tools rather than pretending they do not exist — and why the graded skills have shifted toward the parts the tools cannot do for you.
An assistant is a fast, tireless, well-read collaborator with no stake in being right. It will produce plausible code for a method it has misunderstood, cite papers that do not exist, and agree with your framing when your framing is wrong. Everything below follows from that.
Course policy¶
AI use is allowed and expected. You do not need permission to use an assistant for coursework, and refusing to use one will mostly cost you time. The course assumes you have one set up by the end of week one.
Disclosure is required. For every homework and for the final project, state which AI tools you used and for what. One or two sentences is enough: “Claude Code drafted the data-loading functions and the first version of the plotting code; I wrote the feature engineering and verified all outputs against the raw files.” Substantial AI-drafted commits are disclosed in the commit message (see 1.5). Undisclosed AI use is an academic integrity issue in exactly the way undisclosed help from a person is.
You must be able to explain and defend every line you submit. “The AI wrote it” is not an explanation. If a function is in your repository, you can say what it does, why it is there, and what would break if it changed. The instructor may ask you, at any point, to walk through your code unaided — no assistant, no notes. If you cannot, the work is not yours yet, whatever the commit log says.
Verification duties¶
The assistant’s output is a draft, always. Before it becomes your work:
- Never accept numerical results without checking. Recompute a quantity a second way, test a known case, check units and orders of magnitude. An analysis that runs without errors has met a very low bar.
- Never accept citations without checking. Assistants fabricate references — plausible authors, plausible journal, no paper. Confirm every citation resolves to a real document that says what it is cited for.
- Never accept API claims without checking. Assistants confidently use functions that were renamed, deprecated, or never existed, and their training data lags current library versions (this book uses numpy 2.5 and pandas 3.0; much AI training data does not). The documentation, not the assistant, is the authority on an interface.
- Treat AI review as a first pass, not an authority. Asking an assistant to review your code or your report is genuinely useful — it catches real bugs and unclear passages. But it also praises broken designs and flags non-problems. An AI review is one reviewer’s opinion from a reviewer who has never done fieldwork and cannot be embarrassed. The final-project assignment below makes this concrete.
What you must be able to do unaided¶
The course examines you, not your assistant. Three things stay yours:
- Frame the problem. Decide what question the data can answer, what a sample is, what the target is, and what success would mean scientifically. Assistants execute framings; they do not originate good ones.
- Judge the evaluation. Decide whether the test set is honest, whether the split leaks information, whether the baseline is fair, and whether the metric measures what matters. This is where ML projects actually fail, and it is the fair-evaluation thread that runs through the whole book.
- Interpret the science. Say what the result means physically, where it should and should not be trusted, and who downstream could act on it. No current tool carries this responsibility; you do.
If you can do these three, an assistant makes you faster. If you cannot, an assistant makes you wrong at scale.
Exercise badges¶
From Chapter 2 on, exercises in this book declare their AI mode with one of two badges. These are the templates; the same wording appears wherever a badge is used.
“By hand” marks the drills that build the reflexes you need before an assistant is useful — indexing, slicing, core pandas and numpy calls — the same syntax you will later use to check an assistant’s output. Delegate these and the skill never forms; do them unaided, then compare with an assistant’s answer afterward if you want. “Assistant allowed” marks exploratory, plotting, and interpretation exercises, where the assistant is a legitimate part of the workflow; the verification and disclosure duties above still apply in full. An exercise with no badge is “Assistant allowed” by default.
Where this goes next¶
Chapter 6 turns you from a user of agents into a builder and evaluator of them: how agentic systems work, how to design their tools, and how to measure whether they actually help. The final project includes an AI-review assignment that rehearses the critical stance this page describes: you run an agentic AI review of your own repository, then write a critique of that review documenting at least one thing the AI got wrong or missed, and submit both (see the final project rubric).