Part II: Course Project
70% of the final grade — In-class, assisted, attendance required (Track A) or individual, unassisted (Track B)
Design, build, and evaluate an AI-powered system — and produce specific, defensible findings about how it behaves. Both tracks culminate in a presentation + discussion.
Tracks
- Track A: In-class, assisted, attendance required (strongly encouraged). Team project (2–5 students). Pick one of the project directions presented in class. In-class reviews, working sessions, and design clinics throughout.
- Track B — Individual, unassisted (heavily discouraged). Individual only. Work on one of the class projects individually, deliver at the exam.
Structure
Four sprints, plus one sprint to prepare the presentation. Each sprint produces concrete output (issues, commits, a short sprint note, a one-slide per-person update). Sprint-level specifics live in the project docs.
What every project ships
- Working code with a UI
- Project-specific data artifacts (versioned, replayable)
- Findings — specific, quantified observations about the system's behavior
- Technical report
- Final presentation + discussion
Note: project output should be proportional to team size for teams of up to 3 — smaller teams are expected to ship proportionally less.
Presentation guidelines
20 min for groups of up to 3 people, 30 min for groups of 4–5. Tell a story; don't read a checklist at us. Aim for a number of slides below your number of minutes, with optional backup slides after the “The End” slide. Full guidance on what to cover — including what's agentic in your system, the API you expose (MCP or other), and how you manage memory and context — is in deliverables.md §5.
Methodology
Every project is expected to meet a baseline on a shared scaffolding (architecture, agent harness, memory/tools, logging, prompts as versioned files, resilience, cost, quality spec, smoke tests, and the behavior study). Details and minimum bars are in the universal scaffolding doc.
Grading (0–30, same rubric for both tracks)
| Dimension (0–10 each) | Focus |
|---|---|
| Engineering & System | Working system + UI, clean module boundaries, versioned prompts, structured logging, reproducibility from a fresh clone. |
| Science & Findings | Specific findings (not feature lists), quantified uncertainty, honesty about negative or surprising results, scope matched to team size and time. |
| Process & Communication | Consistent per-sprint progress, individual accountability (per-person commits, defensible in-meeting), clear report and presentation with per-member contributions. |
Project options (yes, these are the ONLY options)
IMPORTANT: if you are delivering your project after the June 2026 session, you will have access and will have seen what your classmates have built. My expectations are therefore significantly higher: you either build a completely new system based on new ideas and principles, or make a significant contribution on top. ALSO IMPORTANT: coding assistants can implement most ideas in a day, so at the exam you will have to show why what you are delivering is not a one person, one afternoon project. If you have questions, get in touch.
- Conversational Clustering — cluster a dataset by talking to a human; the oracle is the sole judge of quality.
- WhatsApp Personas — instantiate real-person personas as LLM agents and test individual and group fidelity.
Example projects
- Open Ormus — WhatsApp Personas.
- Cinepal — Conversational Clustering.
- Vibe Coders — Conversational Clustering.
Resources
- deliverables.md — deliverables and sprint rules
- universal_scaffolding.md — common scaffolding
- Old but Gold Lecture on how to give presentations
Submission
- Source code repository (GitHub)
- Report
- Presentation slides
- Exam: presentation + discussion