The curriculum with no textbook: teaching a field that reinvents itself every quarter

Every time someone asks to see the Moonlabs Academy syllabus, we have the same slightly awkward conversation. There is no syllabus in the sense they mean. There is no textbook, no fixed reading list frozen at the start of the year, no set of slides we dust off each cohort. Not because we are disorganised, but because a fixed syllabus for AI engineering is a contradiction in terms. Anything we could print would be out of date before the students who received it graduated.

Consider the timescale. The Academy runs twelve weeks. In this field, twelve weeks is long enough for the best tool for a job in week one to be superseded by week twelve. We have watched a model release halfway through a cohort change the right answer to a question we taught in week three. A printed curriculum in that environment is not a foundation. It is a museum exhibit, accurate as of the day it was laminated and slowly lying to you thereafter. So we do not have one, and the absence is deliberate. This is what we run instead.

We rewrite it every cohort

The first principle is that the curriculum is torn up and rebuilt for every intake. Not revised. Rebuilt.

Between cohorts we sit down and ask what actually changed. Which tools we reached for in our own companies that we were not using three months ago. Which techniques stopped being worth teaching because the models now do them unprompted. Which problem that was hard last quarter became trivial, and which new problem appeared to replace it. The curriculum for the next twelve weeks is assembled from that answer, from the current state of the work, not from the last version of the course.

This is expensive and we do it anyway, because the alternative is teaching last year's craft to people who will practise it next year. A course that is convenient to run is almost always a course that has stopped tracking reality. We would rather do the uncomfortable work of rebuilding every quarter than hand a student a skill with a sell-by date already printed on it.

We teach how to learn a tool, not the tool

If the specific tools churn every few months, then teaching a specific tool as though it were permanent is malpractice. So the durable thing we teach is one level up: how to pick up an unfamiliar tool fast and judge whether it is any good.

A student who has only learned this quarter's framework knows one thing that will expire. A student who has learned how to evaluate a new framework, how to read its documentation, build a small thing with it, find where it breaks, and decide in an afternoon whether it earns a place in their stack, has learned something that never expires. The tools underneath that skill can change every month and the skill only gets more valuable. We drill it deliberately. We hand students a tool none of us have used, on purpose, and watch them work out whether it is good, because that is the actual condition of the next decade of their careers.

The specific tools still get taught, because you cannot ship without them. But they are taught as this quarter's instances of a permanent skill, not as the thing itself. The framework is scaffolding. The judgment is the building.

The curriculum is downstream of real companies

The reason our course stays current without us having to force it is that it is not really a course we invented. It is a live readout of the work we are doing anyway.

Because we run actual companies while we teach, the problems that show up in the Academy are the problems that showed up in our own week. When something new breaks in production on a Tuesday, it tends to be in front of the students by Thursday, because it is on our minds that week and still unsolved. That is a very different thing from a lecturer teaching a case study from a textbook written by someone who left industry a decade ago. The curriculum is current because it is downstream of operators who are still operating, and it would take active effort to make it stale.

This is also why we teach ourselves rather than hiring faculty. A hired instructor teaches the version of the field they learned. Operators teach the version of the field they are living in this week. In a discipline moving this fast, that gap is the whole difference between a graduate who is ready and a graduate who is already behind.

We teach the layer that does not move

None of this means everything is in flux. Underneath the churning tools there is a layer that barely moves at all, and it is the layer we spend the most care on, precisely because it survives.

The tools change. The fundamentals do not. How to break a vague problem into a shippable slice. How to tell whether a system actually works rather than whether it looks like it works. How to reason about cost, latency and failure. How to know which of a thousand plausible answers from a model is the right one, and how to build the checks that catch the wrong ones. Taste, judgment, the discipline of evaluation. These are the same in this cohort as they were in the first, and they will be the same in five years when every specific tool we currently teach has been replaced. A student who leaves with the durable layer and a proven ability to pick up whatever tool arrives next is equipped for a career. A student who leaves with only the tools is equipped for about a quarter.

We are explicit with students about which is which. When we teach a tool, we tell them it is temporary and roughly how long we expect it to last. When we teach a fundamental, we tell them to hold onto it, because it is the part of the twelve weeks that will still be paying them in a decade.

Why the model is now a teacher too

There is one more shift a modern curriculum has to reckon with honestly, and most courses pretend it is not happening. The models are better at teaching the mechanical layer than we are.

If a student wants to learn the syntax of a language or the shape of an API, the current tools will teach it faster, more patiently and more interactively than any human standing at a whiteboard. Pretending otherwise, and spending precious contact hours doing a worse job of something a model does for free, would be a strange use of a twelve-week programme. So we do not compete with the model on the thing the model is good at. We hand that part to it deliberately, and we spend our human hours on the things it cannot yet do: judgment, taste, the commercial and investment context, the messy reality of shipping something a person will pay for. The curriculum divides the work honestly between the machine and the operators, and it puts the humans where the humans still matter.

Why this is the only honest way now

A traditional institution cannot run a curriculum like this, and it is worth being clear about why. Their cycle is measured in years: validate the syllabus, print the materials, train the faculty, accredit the course. By the time that machinery has turned once, the field has moved several times. The very thing that makes a traditional qualification feel solid, its fixity, is what makes it stale in a domain like this one.

We went the other way on purpose. No textbook, no frozen syllabus, a curriculum rebuilt every cohort from the live state of the work, taught by people still doing that work, anchored to the fundamentals that do not move and honest about the tools that do. It is more work to run and it is the only version we would trust to put a graduate in front of the next five years rather than the last one. When someone asks to see the syllabus, the truest answer is that the syllabus is whatever the work demanded this quarter, and that is exactly the point.

Louis O'Connell-Bristow and James Freestone are the co-founders of Moonlabs, the operator-led AI incubator and academy, and previously built the home.co.uk, Homemove and homedata.co.uk stack. The Academy runs twelve students over twelve weeks across three pillars: Coding, Commercials and Investment. Site: moonlab.ventures.