A curriculum built around a specific tool has a shelf life measured in months. We've watched departments spend a semester building coursework around a particular model or interface, only to have it deprecated, renamed, or replaced before the second cohort graduates. The fix isn't teaching less about current tools — it's changing what the tool is used to teach.

Teach the evaluation, not the interface

The skill that survives every model release is knowing whether an output is any good — and why. A course module built around "how to use Model X's chat interface" is obsolete the day the interface changes. A module built around "how to design a test set, define success criteria, and measure whether a system meets them" transfers to whatever tool a student encounters five years from now. We structure every technical unit around a durable question — how do you evaluate this, how do you debug it, how do you know it's wrong — and use whatever current tool is convenient to illustrate it, explicitly flagged as a stand-in.

Capstones anchored in real constraints

The strongest signal we've seen for whether a program prepares students well isn't which tools they used — it's whether their capstone project had to survive contact with a real constraint: a messy dataset, a stakeholder who changes requirements, a deadline that doesn't move. Faculty development programs we run start by identifying one real (anonymized, permissioned) problem from a partner organization and building the semester's projects around variations of it, rather than a synthetic textbook dataset that behaves too well.

Faculty upskilling as infrastructure, not a one-time event

A curriculum is only as current as the people teaching it. We treat faculty development as an ongoing subscription rather than a one-time workshop:

  • A short standing session each term on what's materially changed in the field — filtered for what actually affects teaching, not every headline.
  • Office hours where faculty can bring a confusing tool behavior or a student question they couldn't answer.
  • A shared repository of "this broke, here's what we learned" notes across the department, so the same surprises don't get rediscovered independently every semester.

What we tell departments before they build anything

Before writing a syllabus, we ask departments to separate their learning objectives into two lists: what should still be true about a graduate's skills in five years, and what's specific to the tools available right now. Everything on the first list gets the majority of instructional time and the capstone weight. Everything on the second list gets taught honestly as "this is what's current," with an explicit note that it will change — which, done well, becomes a lesson of its own about how to keep learning after graduation.

The goal isn't a curriculum that never mentions a specific tool. It's one that would still make sense to teach if that tool disappeared tomorrow.