Today is different — no lecture. First half: a guest speaker who's building with GenAI in production. Second half: your time to work on final projects with instructor support. Every team will give a 5-minute progress demo and get feedback.
Quick logistics. Assignment 5 should already be submitted. Today's progress demo is informal — show what you have, get feedback. Next week is the real deal: full presentations, final deliverables, everything due. Let's make sure everyone knows what's expected.
Introduce the speaker. Brief bio, what SZNS does, why their experience is relevant to what we've been learning. Let the speaker take it from here.
Prompt students to think about questions before the talk starts. These questions map directly to course concepts: production challenges (Week 4-5), reliability (Week 5), evaluation (Week 6), model selection (Week 2). Encourage students to connect what they hear to their own projects.
The demo should be honest, not polished. Show what actually works. Show what doesn't. The point is to get feedback while there's still time to act on it. I want to see real code running, not mockups. If something is broken, show the broken thing — the class might be able to help debug it. Each team gets 5 minutes with 2-3 minutes for feedback from the class and me.
Good feedback is specific and actionable. Not "looks good" — instead "the RAG retrieval seems solid but I'm not sure how you'll evaluate hallucination." Encourage students to give honest, constructive feedback. This is a collaborative session, not a competition.
These are the four most common issues I see at this point. Scope creep: you got ambitious and now you're spread thin — cut features, not quality. Evaluation gap: your system works on the demo case but you haven't tested it broadly — write test cases today. Demo anxiety: APIs are unpredictable — record a backup video. Governance afterthought: remember it's 15% of your grade — even a paragraph on risks and mitigations helps.
Walk through the checklist. Emphasize: record a backup video even if you plan to demo live. Commit history matters — if you dump everything in one commit the night before, we'll notice. The write-up should be honest about limitations and failures. Peer review is confidential — be honest about contributions.
This is a suggested structure, not required. The demo should be the centerpiece — 4 minutes of the 12. Don't spend too long on motivation or background. We know the context. Show us what you built, how well it works, and what you learned. The governance section is short but important — show you've thought about it.
Review the rubric one more time. Technical implementation is the largest bucket but evaluation rigor is a close second at 20%. An impressive demo with no systematic evaluation will score lower than a simpler system with thorough testing. Governance is 15% — don't skip it. And remember: honest documentation of failures and limitations is valued. We'd rather see "we tried X, it didn't work because Y, so we pivoted to Z" than a polished surface hiding fundamental issues.