AI00: The AI Lab route: from the chain rule to a code model you trained and opened up

A. Prerequisites and observable goals#

Level: Track plan. Tool versions and install facts were checked on 24 September 2026 against the official sources at the end of this chapter. They change quickly; recheck them before you install anything.

B. The destination, and the route#

By the end of this track you will have trained a small open code model with reinforcement learning on one 32 GB consumer GPU, such as an RTX 5090. The reward will come from a judge you wrote, the same judge you use for your own competitive-programming practice. Then you will look inside the trained model with sparse autoencoders and report what changed. Every load-bearing piece of that pipeline will be code you wrote: the gradient engine, a small GPT, the checking logic in your judge, and the GRPO loss and training loop. The plumbing around it (sandboxing, downloads, rollout servers, dashboards) is provided, and tests check your work at every step. These six modules are Phase 1 of a three-phase route to frontier-level work; sections K to M map Phases 2 and 3, define mastery, and give an honest estimate of the time. This book teaches Module 1 (AI01) in full. This chapter is the map of the whole route: what each module and phase builds, the mathematics it needs, and what it costs in hours and hardware.

The hardware the labs were sized for. Module 1 runs on any computer with Python 3.14, and Module 3 needs no GPU. Modules 2, 4, 5, and 6 were sized for one 32 GB consumer GPU such as an NVIDIA RTX 5090, a consumer Blackwell card (sm_120). Module 4’s planning estimate for memory (section D) shows what a card with less memory gives up. Without a suitable GPU, rent one by the hour: section K quotes cloud GPU prices and says what one consumer GPU can and cannot do.

Six stations. Above each: the new math it teaches, inside that module, just before it is used. Below: what you build (bold), then the tools it installs (gray).

C. The six modules at a glance#

At about 8 hours a week that is roughly seven months of work; section H turns the hours into weeks at two paces. Fifteen of those hours (2G, 3F, 5D, and 6B) go to what the field’s 2025 and 2026 experience showed matters early: honest statistics from Module 2, a judge whose tests are proven before GRPO trains against it, agent tooling, and probes before SAEs. Hours are estimates for planning; record your real ones and re-plan from them.

D. Module by module#

Module 1: Autograd from scratch (AI01, taught in full in this book)#

Why first. Every later module trains something, and training is gradient descent on gradients that backpropagation computes. Build that once by hand and nothing later is magic.

• Math, taught inside the module: partial derivatives (freeze the other inputs), the gradient, the chain rule on a computation graph, why a value used twice adds its gradients, gradient descent, and finite-difference gradient checks.
• Algorithm lane: depth-first search and topological sort, your first graph algorithm, which also orders the bones of a game engine’s animation skeleton (AI01, section 2.5).
• You write: engine.py (a Value class with 13 operations and backward), gradcheck.py, nn.py (Neuron, Layer, MLP), and train.py.
• Provided in the companion code: the starter files, the tests, the step runner, and tools/viz.py, which animates backprop through your own engine.
• Code reading: micrograd’s engine.py. Tools: Python 3.14 and its standard library; nothing else to install. About 18 hours.

Module 2: A tiny GPT trained on one GPU#

• 2A Vectors and matrices, just in time. A neuron is a dot product; a layer is many neurons at once, which is a matrix product. Shapes, transposes, broadcasting, and the gradient of $Y=XW$ derived from Module 1’s scalar rules. (6 h)
• 2B Probability for language models. A distribution over the next token, sampling, softmax derived from $e^x$, log-likelihood and cross-entropy, why logarithms, the famous $p-y$ gradient, the log-sum-exp trick, and just enough expectation and variance to explain attention’s $1/\sqrt{d}$. (6 h)
• 2C PyTorch on the GPU. Install and verify the GPU build; tensors, devices, dtypes; autograd as your Module 1 engine at scale; check your MLP’s gradients against torch.autograd. (4 h)
• 2D From bigrams to an MLP language model. Train/validation splits, overfitting, learning-rate sweeps, initialization, and why saturated $\tanh$ units stop learning (Module 1’s $\tanh'$ returns). (9 h)
• 2E Attention and the transformer block. Queries, keys, values, the causal mask, multi-head attention, residual connections, LayerNorm; byte-pair tokenization (a greedy merge algorithm for the algorithm lane). Code reading: nanoGPT’s CausalSelfAttention. (12 h)
• 2F Training on the GPU. AdamW derived, warmup and cosine decay, bf16 autocast, gradient clipping, torch.compile, throughput and the $6N$ FLOPs-per-token estimate, checkpoints, sampling with temperature. Train a 10–30M parameter model on text, then on Python source. (10 h)
• 2G Honest comparisons. Seed-to-seed noise measured before any claim, at least three seeds per setting, the metric fixed in advance, and a written noise floor that every later “improvement” must clear. Agent-run experiments in 2026 killed runs before the learning-rate decay had finished and reported wins that did not survive a re-test, so this habit starts here, not in Module 5. (2 h)

You write the models and training loops; dataset downloads and a training dashboard are provided. Stretch: Muon’s Newton–Schulz step measured against your AdamW at equal steps; in 2026 open frontier models (Kimi K3) and the NanoGPT speedrun record both used Muon-family optimizers. About 49 hours.

Module 3: Competitive-programming fundamentals and your local judge#

• 3A Contest C++. A template, fast input and output, compiling with g++ and sanitizers. WSL2 Ubuntu is installed here: judges run Linux g++, and Module 4 needs Linux anyway. (3 h)
• 3B Complexity. Big-O by counting operations; logarithms and arithmetic and geometric sums, taught as needed; the budget of roughly $10^8$ simple operations per second. (4 h)
• 3C The core toolkit, in contest order: prefix sums, sorting with comparators, two pointers, binary search (including on the answer), hashing, stacks and monotonic stacks, greedy algorithms with exchange arguments, BFS and DFS, topological sort, union-find, Dijkstra, and dynamic programming (1D, 2D, knapsack, LIS). Each topic: picture, worked problem, faded problem, then solo problems, plus reading an accepted solution written by someone else. (25 h)
• 3D Stress testing. A brute force, a random generator, and a comparison loop: the habit that finds your own bugs before a judge does. (3 h)
• 3E Your judge. Problem format; verdicts (AC, WA, TLE, MLE, RE, CE); your checkers (token comparison, floating-point tolerance with absolute and relative error, special checkers for problems with many valid answers). The runner and the sandbox are provided. The judge is designed from the start to be Module 4’s reward: structured per-test results, deterministic, and parallel. (10 h)
• 3F A judge you can trust as a reward. Before GRPO trains against it, prove its tests: mutants of each reference solution that the tests must fail (the method that checked this book’s lab tests; section G), hidden tests the model never sees, and generated tests kept only when a gold solution passes them. A June 2026 audit of SWE-bench Verified, a benchmark of real GitHub issues each checked by its project’s own tests, found that 28.5% of sampled tasks accepted a wrong patch, and that models scored about 14 points higher on tasks whose tests could be gamed; a lenient judge teaches the same lesson to your model. (4 h)

The Algorithms Lane (CP00) runs beside the whole track in its own two sessions a week, from your first week. Stretch: verifier-guided test-time compute, sampling several solutions or looping generate, test, and repair against your own judge, and plotting pass rate against compute spent. About 49 hours.

Module 4: GRPO on a small open code model, with your judge as the reward#

• 4A The probability and RL bridge. Random variables, expectation, and variance; a policy as a probability distribution over tokens; the objective $J(\theta)=\mathbb{E}[\text{reward}]$; the log-derivative trick $\nabla p=p\,\nabla\log p$, which is your “derivative on top, original on bottom” rule; REINFORCE; why subtracting a baseline keeps the gradient honest; advantages, importance ratios, clipping, and KL divergence. Then GRPO itself: advantages computed from a group of answers to the same prompt. Also what Dr. GRPO and DAPO changed (length and standard-deviation normalisation, clip-higher, token-level loss, dropping all-correct and all-wrong groups). (12 h)
• 4B GRPO on your own tiny GPT, on Windows, on a toy task with a checkable reward. Watch reward rise and entropy fall in a system you wrote end to end. (8 h)
• 4C Scale up in WSL2. A small Apache-2.0 code model such as Qwen2.5-Coder-0.5B-Instruct (1.5B with LoRA if memory allows), rollouts served by vLLM, problems with tests from MIT or CC-BY datasets, and your judge in a sandbox. You write the GRPO loss and the training loop. TRL’s GRPOTrainer runs on the same batch as an independent check of your numbers. Before you swap in a newer model, check its license as well as its size: Gemma 4’s small sizes and gpt-oss-20b are also Apache-2.0, while several 2026 open frontier models (Kimi K3, Qwen3.8-Max) carry custom licenses and are far too large for one GPU anyway. (22 h)
• 4D Evaluation and failure modes. pass@$k$ and its unbiased estimator $1-\binom{n-c}{k}\big/\binom{n}{k}$, held-out problems, contamination, reward hacking (special-casing the sample tests, exploiting a lenient checker), entropy collapse, and length drift. The dashboards are provided; you write the report. (12 h)

A real bug for the field guide. On TRL’s default generation path, some GRPO runs never stopped generating, because the model’s end-of-turn token IDs were declared only in its generation config; the model then trained on everything it wrote after its turn ended. The visible symptom was completions/clipped_ratio near 1, until TRL 1.14.2 fixed it. Module 4 checks this metric on the first batch.

Planning estimate for memory. Full fine-tuning with AdamW costs about 16 bytes per parameter before activations (weights, gradients, and two optimizer moments). That is about 8 GB for 0.5B parameters, but about 24 GB for 1.5B, which is too tight beside vLLM on 32 GB, hence LoRA for the larger model. Module 4 measures this rather than trusting the estimate. About 54 hours.

Module 5: The overnight experiment loop#

Karpathy’s autoresearch (March 2026) is the pattern. An agent edits only the training script, runs a fixed 5-minute training job, keeps the change if validation bits-per-byte improves, and reverts it otherwise. That is about 100 experiments a night. You rebuild the pattern around your Module 2 GPT.

• 5A Statistics, just in time. Seed-to-seed noise, standard error, confidence intervals, and why trying 100 ideas guarantees some lucky “wins”; confirming on held-out seeds. (6 h)
• 5B The harness. Time budget, one metric, keep or revert, logging, crash and timeout handling. The agent is Claude Code running headless and may edit only the files you allow. You write the metric, the acceptance rule, and the agent’s program; the orchestration and the dashboard are provided. Set a usage budget first, because every experiment spends model usage. (10 h)
• 5C One overnight run and its analysis, including which “improvements” survive a re-test. (6 h, plus the night)
• 5D Agent engineering, small but real. Write one tool server in the Model Context Protocol, targeting the 2026-07-28 revision of the specification (every request carries its protocol version, and a server/discover call replaces the old start-up handshake); drive it from the Claude Agent SDK with permission hooks that limit what the agent may touch; and score the agent with Inspect, the UK AI Security Institute’s evaluation framework. (6 h)

About 28 hours.

Module 6: Probes, then sparse autoencoders, on your trained model#

• 6A Linear algebra, part 2. Bases, span, projections, the L1 and L2 norms (why L1 makes codes sparse: the diamond and the circle), and why high-dimensional spaces hold many nearly perpendicular directions, the superposition hypothesis. (7 h)
• 6B Probes first. A linear probe and a difference-of-means direction for one property you can label, such as “this completion special-cases the sample tests”. They are the baseline every fancier method must beat: in December 2025 Google DeepMind’s interpretability team made it a rule to start with simple methods such as probes and add complexity only when those baselines fail, and in September 2026 simple probes reportedly caught agents’ reward hacking about as well as chain-of-thought judges. (3 h)
• 6C An SAE from scratch in PyTorch. Encoder, decoder, reconstruction plus sparsity loss, TopK and ReLU variants, dead latents, and the metrics that matter (L0, unexplained variance, and loss recovered when the reconstruction is spliced back into the model). Activation caching is provided; SAELens checks your numbers. (14 h)
• 6D Reading features. Top-activating examples, effects on the output, automatic labels, ablation and steering, a comparison of features before and after GRPO, and whether an SAE feature beats your probe. The final public write-up. (16 h)

Stretch: transcoders and attribution graphs with the open circuit-tracer tool and Gemma Scope 2, which covers Gemma 3 models from 270M to 27B parameters. SAEs remain the right first build; by 2026 they are no longer the field’s destination. About 40 hours.

E. Tools: when each is installed, and what forces WSL2#

Nothing is installed before the module that needs it. These facts were checked on 24 September 2026 and rechecked on 17 October 2026. Versions move monthly, so treat every number here as a snapshot: before you install anything for a module, recheck its versions against the sources at the end of this chapter and pin the set that works in a lock file. The prose names only what you need to understand. You will keep two PyTorch environments with different versions: Windows for Modules 2, 5, and 6, and WSL2 for Module 4’s rollouts. Module 1 needs only Python, and Module 3’s judge runs in WSL2 with g++ and no PyTorch. The commands are for Windows; on a Linux PC, skip WSL2 and run its steps natively.

F. How every module runs#

• Spaced review first. Two or three quick questions drawn from your error log, ten minutes, closed book.
• Picture first, then one idea at a time. Every new concept opens with a diagram of the real mechanism and one small worked example with every step shown. Every symbol is defined the first time it appears.
• Predict, then run. Before you execute anything, the module asks what you expect. Write the prediction down; the gap between prediction and output is where learning happens.
• Worked, then faded, then solo. The first piece of each lab is shown in full and you type it. The next has blanks. After that you work from a specification and the tests.
• Hint ladders. Every lab step has three rungs: a nudge (a question), a pointer to the concept, then a skeleton. Climb one rung at a time. Attempt each step before you look anything up, and let the tests judge it: when one fails, find the first incorrect step yourself and log it before you fix it. Every practice and gate problem has a complete solution at the end of its module; open it only after your own attempt.
• Named bugs. Each module lists the mistakes beginners actually make, how to spot each one, and which test catches it.
• Code-reading drills. Every module has a passage from a real repository, pinned to a commit. You write your explanation before reading the answer.
• Mastery gates. You move on only after the module’s tests pass on your own code, a closed-book gate quiz passes, and you can teach the central idea back in a few sentences.
• Development log. Each module ends with a short log entry: what you built, one number, the bug that cost the most, and a picture. These become your public evidence.
• AI in three zones. LM’s section I applies to every lab: no AI on first attempts, gates, or timed work; concepts and hints only after a logged attempt, recorded in ai_use_log.csv; chores such as plots and downloads any time. The code you are learning to write stays yours.

G. What you write, and what the companion code provides#

The split of work is the same in every module of the route.

• Where the code lives. Labs ship in the companion code (bezhig.com/book) with starters and tests. Module 1’s lab is the ai-lab/m01_autograd folder: the files you type into, their tests, and a check.py step runner. Supporting tools, such as the backprop visualizer, are in ai-lab/tools. This edition ships Module 1’s lab; the later modules’ plumbing (sandboxing, downloads, rollout code, dashboards) is mapped in section D and follows the same layout. Copy the ai-lab folder into a repository of your own and manage it with Git; it is designed to become public evidence of your work, within the terms of the companion code’s license.
• How the tests were checked. A test suite is only as good as the bugs it catches. Module 1’s tests were run against “mutants”: deliberately broken copies of a working solution, one per common beginner bug, and every one of the 63 mutants fails at least one test. Module 3 has you prove your own judge’s tests the same way.

H. How long it takes#

The hours in section C turn into weeks at whatever pace you can sustain. The table uses two: about 8 hours a week with this track on its own, and about 4 hours a week when it shares your week with other tracks or a course.

So Phase 1 takes about seven months at 8 hours a week and a little over a year at 4. If you follow several of this book’s tracks, plan them together on one weekly budget, as “Plan your path” in Part I does. The hours are estimates: record your real hours in each module’s development-log entry and re-plan from them.

I. How this track fits the rest of the book#

• Frontier engineering (Part X). This track is the hands-on spine of F00’s “AI systems” pillar. Module 2 covers what F11 (Python and PyTorch) and F12 (transformers) planned; Modules 4 and 6 begin F15’s RL infrastructure and F16’s interpretability. Phase 2 (section K) then takes over the rest: Module 8 is F14 (GPU kernels), Module 9 is F13 (inference engineering) and flagship Project 1, and Modules 10–12 finish F15 and F16. Module 9 depends only on Module 2, so you can pull it forward if you want your strongest portfolio piece sooner.
• Earlier chapters. W04 develops forward-mode differentiation with dual numbers, and G13 develops backpropagation with matrices; both assume linear algebra you will meet in Module 2. A01–A04 are the full linear-algebra and probability courses; this track teaches the slices it needs and points to those chapters for depth.
• The algorithms lane. Module 1 starts it with topological sort, Module 2 adds byte-pair encoding, and Module 3 makes it a habit. The Algorithms Lane (CP00) is the main home for algorithms, and F17 extends it. Module 3’s toolkit section 3C overlaps the lane. If you have finished the lane through CP13 before Module 3 starts, shrink 3C to the two topics the lane does not teach, union-find and Dijkstra, plus a short review; otherwise keep 3C, and the lane’s later modules become a deeper second pass.

J. Honest limits#

• Scale. A 0.5B to 1.5B model trained on one GPU will not rival frontier models. The point is to understand and control every stage, and to measure honestly.
• Safety of model-written code. Code generated during RL is untrusted. It runs only inside the sandbox, never directly on your own system.
• Reward hacking is expected, not rare. A model rewarded by tests learns to exploit weak tests. Your judge’s hidden tests and your evaluation discipline are part of the result.
• Versions go stale. Every install command here carries its check date; recheck it against the sources at the end of this chapter before you run it.

K. Beyond Module 6: the road to the frontier#

Modules 1–6 are Phase 1. They make you a credible research-engineer candidate with real, public evidence, which is rarer among applicants than it should be. They do not, on their own, put you at the frontier. Engineers at frontier labs are largely judged on three things: systems that work at scale (training runs, inference engines, RL pipelines, kernels), numbers other people can trust, and results nobody had before. Phase 2 builds the first two at depth; Phase 3 produces the third.

The bars show the shape of the route in months from the start: lighter while you are also studying calculus, heaviest where Phases 2 and 3 overlap, about 15 hours a week on average. At a steady 20 hours a week the whole route takes about two years, some eight months less than drawn. Phase 3 starts before Phase 2 ends because a research bet needs months to mature.

Phase 2: frontier depth (Modules 7–12, about 600 hours)#

What one 32 GB consumer GPU can and cannot do. Modules 7, 9, 11, and 12 run on one such GPU; a 124M GPT reaches GPT-2-small quality on one GPU in hours to about a day, not weeks. Module 8’s Triton and classic CUDA kernels run locally, but kernels that use datacenter-only hardware features need rented GPUs or GPU MODE’s hosted machines (A100, H100, B200, L4, T4): FlashAttention-3 is Hopper-only, FlashAttention-4 names the H100 and B200 but not consumer sm_120 cards, and most 2026 NVFP4 and MXFP8 kernels in vLLM target sm_100. Every Blackwell claim you read should say which of the two architectures it means. Module 10 needs real multi-GPU bandwidth: on-demand H100s cost about $2 to $4.30 per GPU-hour (September 2026), so a 10-hour session on an 8-GPU node is roughly $160 to $345. Budget for it deliberately.

Phase 3: an original contribution (about 500 hours, overlapping)#

Pick one or two bets. Each one ends in a public repository with tests, a technical write-up, a 60-second video with numbers on screen, and the channels in F00, section G.

• A. Systems. An inference engine or kernel that beats a named baseline on a named workload, with benchmarks anyone can rerun, plus merged pull requests to vLLM, SGLang, llama.cpp, PyTorch, or Triton. If you have already built real-time or networked software in C++, this is probably where that experience compounds fastest.
• B. Training efficiency. A measured improvement over a public baseline. The NanoGPT speedrun’s 8$\times$H100 record fell from 1.126 minutes in August 2026 to 39.9 seconds on 28 September 2026, a record its author credits to a sampled-softmax loss, hashed n-gram embeddings, a new optimizer, full-stack FP8, and CUDA graphs. The run has no single-GPU track, so a carefully documented single-GPU baseline of your own is itself a contribution. Then test your best idea on rented hardware against the real record.
• C. RL for code. A reproducible study built on your judge: which reward-hacking behaviors appear during GRPO, how to detect them, and what preventing them costs in pass@$k$.
• D. Interpretability. What reinforcement learning changes inside a code model, measured with sparse autoencoders and transcoders, with the features released for others to inspect.

The spines that run through every phase#

• Mathematics (about 600 hours): Calculus II and III, in this book or a course; linear algebra to the SVD and matrix calculus (A01–A02, then deeper); probability and statistics (A03–A04); optimization and information theory (entropy, KL divergence, cross-entropy). Each module still teaches its slice just in time; the full chapters and courses give the whole picture.
• Algorithms (about 300 hours): the Algorithms Lane (CP00) from your first week, then F17’s practice, two sessions a week.
• Reading the frontier: two or three new papers a week, one reproduced in code each month, each recorded in the development log you keep (section F).

L. Mastery, defined so you can grind toward it#

“Absolute mastery” needs a definition you can measure yourself against. Use this ladder for every topic.

Phase 1 aims at levels 1 to 4, Phase 2 at 4 to 5, and Phase 3 at 6. In a field that changes monthly, mastery means level 6 in one or two areas, levels 4 to 5 across the rest, and the habit of staying current.

M. The honest estimate#

The whole route is about 2,200 hours: Phase 1 about 240, Phase 2 about 600, Phase 3 about 500, the mathematics about 600, and algorithms about 300. At 20 hours a week that is a little over two years; at 30 hours a week, about a year and a half. No plan can promise any particular person’s attention. What has reliably drawn frontier labs’ attention is verifiable work that beats what already exists:

• Keller Jordan’s NanoGPT speedrun records and his Muon optimizer write-up preceded his move to OpenAI (F00, section G).
• Chris Olah had no undergraduate degree; independent research and talks led to an invitation to Google Brain, then OpenAI, and he later co-founded Anthropic.
• Anthropic says about half its technical staff had no prior machine-learning experience and that some never went to college, and asks applicants to put independent research, thoughtful blog posts, or open-source contributions at the top of their resumes.

Every phase of this route ends in exactly that kind of evidence.

Sources for this chapter (checked 24 September 2026)#

Sources for sections K–M (checked 25 September 2026)#

Further sources (checked 17 October 2026)#