Teaching built out of the research.
codelab.sh is the hub for Antonio Mastropaolo's courses at William & Mary. The research asks whether a language model's claims about code can be trusted. The courses put students inside the same tools and the same failure modes: they run the models, log where two of them disagree, and learn to verify what a model says before they act on it.
Two models, one question
Each run box lets a student pick GPT or Gemini. The platform records who ran what, in which lab, with which model, and how long the prompt was — a record of how first-year students actually prompt, kept run by run.
A gate that counts
Completion is decided by a deterministic gate that counts entries and measures words. It never reads for meaning, so nothing a student writes can steer it. A lab is done when the work exists, not when it is pretty.
Break it on purpose
Lab 5 plants a paragraph in the source and asks whether the model notices. Lab 6 hardens a prompt the student actually uses, then makes them break it. Prompt injection is taught from the attacker's chair.
The classroom runs on the same failure modes the research studies.
The research asks a narrow question in many forms: when a language model makes a claim about code — that a patch is correct, that a test is useful, that a summary is faithful — can anyone tell whether it is true, and at what cost? The papers study where models are confident and wrong, how to evaluate them without flattering them, and whether one model can be trusted to judge another.
Those are not background reading for the courses. They are the exercises. In Lab 1 a first-year student asks one question of two models and writes down where they disagree — the observation that motivates a robustness study. In Lab 4 they audit a chain-of-thought transcript and mark the step that broke. In Lab 5 they run the same prompt three times and log the drift. None of it is a metaphor for the research; it is the research at the scale of one student and one afternoon.
The platform is the artifact. It records every model call, decides completion by counting rather than judging, and keeps the model out of the grading loop — because a course that teaches prompt injection cannot let a model be the gate.
AI for code
Resource-efficient foundation models for code — quantization, parameter-efficient fine-tuning, distillation — cheap enough to run at developer scale.
Understanding what models do
Neurosymbolic reasoning and feature-level explanations that move past an opaque next-token prediction.
Reliable evaluation
Causal reasoning, counterfactuals, and honest LLM-as-a-judge methods that measure what matters rather than what is easy to measure.
Automation practitioners can trust
Agents that plan, reason and execute multi-step software workflows, with end-to-end behaviour that can be measured.
Three sites, one platform.
Prompt Engineering
No programming background required — writing, argument and clear thinking are the technical skills here. Six hands-on labs, one session a week, done live on the lab page and checked the moment you submit. Bonus exercises, AI-graded, for extra credit.
- 01Hello, model75 min
- 02Rebuild it right90 min
- 03Make it answer from YOUR document90 min
- 04Find the broken step90 min
- 05The fact-checker80 min
- 06Armour a real prompt80 min
AI for Software Engineering
How recent advances in AI turn into automated practice across the software lifecycle — and how to read the evidence without overclaiming. A semester built as a research argument, ending in a position the student can defend.
- IModels, agents, and evidence — code models, SWE-bench, and what a benchmark result does not establish
- IIGeneration, change, and repair — program repair, constrained generation, test generation
- IIIAssurance, people, and trust — static analysis meets models, metrics beyond pass@k, human factors
- IVResearch practice — from observation to a defensible study, critique, and replication
codelab academy
The learning environment behind both courses. Sign in with a W&M address — a single-use link arrives in your mail, there is no password — and the console opens: the run boxes, the completion gate, your own logged runs. Staff see the roster, who has activated, and the switch for every lab and bonus.
- ·Records every model call: who, which lab, which model, prompt length, tokens in and out
- ·Saves as you type and checks as you go — the lab is submitted where it is done
- ·Decides completion with a deterministic gate; a model never grades the gate
- ·Unlocks labs in order — one left undone blocks the next
What you read sits on paper. What you operate is the panel.
Sign-in is a link, not a password. A student types a W&M address, a single-use link arrives, and the session starts when they click it. There is nothing to remember and nothing to leak; a link that is not used within a day simply expires.
The six labs open in order. Each lab is a page of run boxes and answer fields. It saves as you type and checks as you go, so the lab is submitted where it is done — in the hands-on session — and the result is on the screen before the student leaves the room. A lab left undone blocks the next.
Grading on completion is a choice, not a shortcut. A first-year student who has written five runs, three journal entries and a reflection has done the lab; the gate says so, at a threshold staff can set per lab. Bonus exercises — Lab N.1 — are the one place a model reads the work, and they are opt-in extra credit, never the gate.
Staff see a console. The roster, who has activated, which labs are open, a switch for every bonus, the model usage for the section, and every question a student has asked that still owes an answer.
The lab station on the right is an illustration of the console's layout, not a live feed. The real one is behind the sign-in.
AURA — AI for Understandable and Responsible Automation.
Antonio Mastropaolo is an assistant professor of computer science at William & Mary. He took his PhD at USI Lugano in 2024 and directs the AURA Lab, where he advises six PhD students at the intersection of AI, natural-language processing and software engineering — with an emphasis on explainability, efficiency and trustworthiness.
The teaching draws on the lab's four threads: resource-efficient foundation models for code; neurosymbolic reasoning and interpretability; reliability, causality and honest evaluation, including when a language model can be trusted to judge another; and agents for the software lifecycle. The group, the software and the published work are on the lab site.