Teaching Approach

If you can't build something from first principles, you don't actually understand it. This principle—often associated with Richard Feynman, who could make quantum electrodynamics comprehensible to undergraduates not because he simplified it, but because he understood it completely—is direct and unforgiving: "What I cannot create, I do not understand."

This wasn't modesty—it was meant literally. If you can't reconstruct the argument, derive the equation, implement the algorithm, you're carrying someone else's conclusion around. That's fine for trivia. It's useless for innovation.

We take this seriously. Every course ends with working systems you built: a RAG pipeline querying your own documents, an evaluation harness testing your models, a Bayesian simulation running your assumptions. These aren't assignments to be graded and discarded. They're tools you own, understand, and can modify when your needs change.

The test isn't whether you can explain what embeddings are. It's whether you can build a retrieval system, diagnose why it's failing, and fix it. If you can't create it, you don't understand it. And if you don't understand it, you can't innovate with it.

The most durable learning happens through concrete problems that matter. This is a principle often associated with Alcuin of York—head of Charlemagne's court school in the late 8th century, remembered for bringing classical learning to medieval Europe—whose real contribution was pedagogical: he taught through problems, not lectures.

The fox-chicken-grain puzzle is attributed to him—a farmer needs to ferry a fox, a chicken, and a sack of grain across a river, but the boat only holds one at a time. Leave the fox with the chicken, and the chicken gets eaten. Leave the chicken with the grain, and the grain gets eaten. The puzzle forces you to think through constraints, sequencing, and consequences.

This wasn't recreational mathematics. Alcuin used problems like this to teach logic, resource management, and strategic thinking to people running an empire. The principles transferred. We do the same: you learn retrieval systems by building one that answers questions from your own documents. You learn evaluation by designing tests for failure modes you've actually encountered. The domain is yours. The principles travel.

When learning is grounded in problems that matter to you, the capability sticks. When it's generic, it evaporates.

Technical skill develops through a specific progression: observation, practice, teaching. This structure—often associated with William Halsted, who pioneered the surgical residency system at Johns Hopkins in the late 1800s—was as much a pedagogical innovation as a medical one. See one, do one, teach one.

It sounds simple. Watch an expert perform a procedure. Perform it yourself under supervision. Then teach it to someone else. The final step is what matters—you don't truly understand something until you can explain it to another person and defend the choices you made.

We structure every teaching unit this way. You observe a working system. You build your own version. Then you present it to peers and justify your design decisions. That presentation isn't assessment theatre—it's where understanding crystallizes. When you can explain why you chose one retrieval strategy over another, or why your evaluation harness tests for specific failure modes, you've moved past following instructions.

By the time you leave, you've taught someone else what you learned. That's when you know it's yours.