We are still teaching students to write code. Their future employers will hire them to direct AI teammates. Something has to give. The gap between what SE programs teach and what industry needs has always existed, but AI teammates are turning it into a canyon. We often train students to be fluent in programming languages when their careers will demand fluency in specification, delegation, and judgment; we grade them on code they write by hand while the tools on their laptops generate equivalent code in seconds. We are, in short, preparing them for a profession that, in its current form, may not exist by the time they graduate. This is not about adding an “AI tools” module to an existing curriculum; it is about whether the entire model of SE education needs rebuilding from the ground up. What does it mean to teach software engineering when the fundamental activity of the profession is shifting from code production to problem diagnosis and intent specification? Questions for the room: - If students will spend their careers directing AI teammates rather than writing code, what foundational skills should we actually be teaching? - How do we assess competence when the student’s primary output is a specification or a prompt, not a program? - Does the traditional SE curriculum (data structures, algorithms, design patterns) become more important as foundational judgment, or less important as automatable knowledge? - What does academic integrity look like when AI teammates are not just permitted but expected in professional practice? - Are we preparing students to be professionals who can diagnose problems and direct AI teammates, or are we preparing them to be displaced by AI?