Build your own PyTorch

A framework like PyTorch feels like a place where something happens that you cannot see. You call loss.backward(), and suddenly there are gradients sitting in the weights. As long as that call stays magic, every training problem stays a matter of guesswork.

The way out is the same one we use everywhere on this platform: build it once yourself. You create a directory called meintorch/ and fill it, in eight steps, with exactly the parts that make up a deep learning framework: tensor, autograd, layers, loss, optimizer, training loop, data loader. By the end your own framework separates a dataset, which you also generated yourself, with over 90 percent accuracy. Not a single import torch along the way.

The model for this is Harvard's TinyTorch from the mlsysbook. What we take from it is the method alone, not the material: don't import it, build it.

The rule: zero magic

One single rule holds this course together, and it applies at every step.

NumPy is allowed. Array arithmetic, matrix multiplication, random numbers. NumPy takes the arithmetic on fields of numbers off your hands, and that is precisely not the point of this course.

torch, jax, tinygrad and autograd are forbidden. Those are the libraries that would take over the very parts this course is about. Importing autograd instead of writing it means skipping the one insight the course exists for.

The final proof step goes one further: the dataset does not come from a library either. The interlocking half moons your network has to prove itself on are something you generate yourself in about ten lines of NumPy. Zero magic applies to the data as well.

Every step ends with a milestone test. It is not a formality, it is the sign-off: as long as it is red, you do not move on. And because each part stands on the one before it, a red test in step 05 almost always points at a thinking error in step 02.

Forward and backward: the one duality

If you want the eight steps in a single sentence, this duality is where you end up. Every part you build can do two things.

Forward, it computes an output from its inputs. A layer multiplies by its weights, ReLU cuts off negative values, the loss turns an entire prediction vector into one single number. That is the part that is easy to write down.

Backward, the same part computes the gradients of its inputs from an incoming gradient. It passes the question "how much of this is your fault?" on to whatever came before it. That is the part you normally never see.

Autograd is nothing but the bookkeeping of the order in which the forward computations happened, so that they can be replayed in reverse. That is why autograd sits in second place on the roadmap even though you do not really use it until step 05: everything after it stands on top of it.

Two modes: coach and goal

The same route, two entirely different ways of walking it. Both build the same target repo and run against the same milestone tests. You can switch halfway through, but you should not mix them.

Coach. You write the core yourself. The course puts up the scaffold, with # TODO(du) at the decisive spots, and a test that is still red. A hint comes if you ask for it, the solution only if you explicitly say so. You set the pace. This is the mode this course was written for.

Goal. The autonomous run. An agent implements each chapter in full, writes and checks the test, verifies green and drives on. One command runs the whole route in one go. Useful as a reference solution, as a second pass, or when you want to watch an agent work through an eight-stage task with nobody interrupting.

The bridge: framework loop and agent loop

It is no accident that this course sits on a platform about agents. What you build in step 06 is a loop, and it has the same shape as the loop that makes an agent an agent.

The training loop goes: compute a prediction, measure the error, get the gradients, adjust the weights, start over. The agent loop goes: ask the model, call a tool, hand the result back, start over. In both cases the progress is not hidden in one brilliant step but in the repetition of a very simple one, with state passed along between the rounds. In both cases the real work is not in the clever part but in the plumbing around it: data in, state forward, stopping condition.

And in both cases, the thing that looks like a black box from the outside is a few dozen lines you can type yourself in an afternoon. Once you have written the training loop, the tools and loop building block reads like an old acquaintance.

What you need

The code runs on your machine, not here. The platform provides the guidance, the roadmap and the milestones.

• Python 3.10 or newer and NumPy. Nothing else.
• An empty directory called meintorch/ for your framework to grow in.
• Around two and a half hours, spread over eight sittings. The steps are cut so that each one can be finished in a single sitting.
• Optionally Claude Code. Then you also get the skill packs for both modes as slash commands.

How to do this locally in Claude Code

Each of the two modes comes as a skill pack you can download: an archive with the slash commands, the progress log PROGRESS.md and all eight milestone tests. The tests in the pack are character for character the ones in the chapters here - both modes run against the same acceptance, and the zero-magic rule holds inside the pack exactly as it does here, right down to the proof step without scikit-learn.

Unpack it, start Claude Code inside the unpacked directory, off you go. The folder .claude/commands/ is already in the right place; there is nothing to set up.