Nobody Told You the Boring Parts Are What Actually Matter
There’s a version of this story that gets told a lot.
Brilliant researchers invent a revolutionary new neural network architecture. The architecture is elegant, the math is beautiful, a paper gets published, the world changes.
That story is mostly wrong.
A Stanford lecture that’s been quietly circulating explains how ChatGPT, Claude, Gemini, and Llama are actually built, from scratch, across two hours. And the most striking thing about it isn’t any single technical insight. It’s the repeated, almost exasperated admission from the professor:
“In reality, what matters in practice is mostly data, evaluation, and systems. Not architecture.”
He said this after spending a decade publishing architecture papers.
I’ve been building AI systems long enough to find that confession both refreshing and deeply unsurprising - Yann Duboi
Note for all my substack active readers - This article might sound having many components which have already been talked about earlier (and to a more advanced level) than being discussed in this article (which is okay tbh because not every food is a high protein food :) ) . So, feel free to skip this one :)
The Five Things That Make an LLM
Before anything else, the lecture lays out the five components of training a large language model:
The professor’s honest admission: academia spends most of its time on architecture and training algorithms. Industry spends most of its time on the other three. Guess which approach produces models that actually work.
This isn’t cynicism. It’s a structural truth about what’s hard. Architecture is intellectually clean. Data is a disaster.
Predicting the Next Word, at Civilizational Scale
The core task of an LLM is almost insultingly simple: given everything that came before, predict the next word.
That’s it. The entire thing.
The lecture walks through this carefully. You tokenize text into chunks (not quite words, not quite characters, something in between). You pass those tokens through a transformer. You get a probability distribution over what comes next. You compare to what actually came next. You update the weights to make the right answer more likely. Repeat approximately forever on most of the internet.
What you get at the end is a model that has, in some compressed form, internalized the statistical structure of human written language. Not knowledge in the way humans have knowledge. More like: a very sophisticated sense of what kinds of sentences follow other kinds of sentences, across every topic, register, and domain that appears on the internet.
That’s the base model. It’s genuinely strange. Ask it a question and it won’t answer it. It’ll generate more questions, because that’s what comes after questions on the internet.
Tokenization: The Part Everyone Skips That Actually Matters
Here’s where I want to add something the lecture touches on but doesn’t dwell on enough.
Tokenization is the unglamorous pre-step that shapes everything downstream. The model doesn’t see text the way you do. It sees tokens, numerical IDs for chunks of text, determined by a vocabulary built before training even begins.
The most common algorithm is Byte Pair Encoding: start with individual characters, find the most common adjacent pair, merge them into a new token, repeat until you have a vocabulary of the right size. Around 50,000 to 100,000 tokens for most frontier models.
The implications are weirder than they sound:
The number 327 might be a single token. Which means the model doesn’t see it as three digits. It sees it as one atomic unit. This is why LLMs are historically terrible at arithmetic. Not because they’re bad at math, but because they never saw the individual digits as independent things that could be composed.
“Strawberry” might be one token or two (”straw” + “berry”). Either way, the model never processes it as s-t-r-a-w-b-e-r-r-y. Which is why asking a model to count letters in “strawberry” is, structurally, harder than asking it to solve a differential equation. The equation appeared in training. Character-level counting of a token that’s treated as atomic did not.
The professor puts it plainly: one of GPT-4’s major changes was how it tokenizes code. Specifically those four-space Python indents that earlier models mangled constantly. A tokenization fix. Not an architecture fix.
This is what I mean when I say the boring parts are what actually matter.
Data: “We Train on All of the Internet” Is a Lie of Omission
The lecture gets genuinely great here. The professor walks through what “training on internet data” actually involves, and it’s approximately nothing like the clean, simple phrase implies.
Start with 250 billion pages. End with roughly 15 trillion tokens, which sounds bigger but is actually the result of aggressive filtering, deduplication, and quality reweighting. The lecture estimates that roughly 15 people on a 70-person team like Meta’s Llama group work exclusively on data.
My honest take: data is where the real moats are. Architecture papers get cited. Data pipelines get kept secret. Nobody at a frontier lab is publishing their exact filtering logic, quality classifiers, or domain weighting recipes. The copyright liability alone would be career-ending.
The professor notes this directly: “There’s a copyright liability issue. They definitely don’t want to tell you that they trained on books.”
Scaling Laws: The Most Useful Boring Graph in AI
Here’s something that should be more famous than it is.
If you plot model performance (on log scale) against compute, data, or parameters (also on log scale), you get a straight line. This is the scaling law, and it is genuinely remarkable.
It means you can predict how well a model will perform before you train it, by fitting the line from smaller experiments and extrapolating. It means you can answer questions like: given $50 million of compute, what’s the optimal model size and dataset size to train on?
The Chinchilla paper’s answer: roughly 20 tokens of training data per parameter. But in practice, for production inference at scale, closer to 150 tokens per parameter, because smaller models are cheaper to serve to hundreds of millions of users.
The “bitter lesson” from this: architectural innovations change the intercept of the scaling curve, not the slope. Good data changes the slope. So researchers who spend years on novel architectures are, from an industry perspective, moving a secondary variable. The variable that actually dominates is how much compute you have and what you train it on.
Back of the envelope for Llama 3 400B: 16,000 H100 GPUs, 70 days, ~$52 million, ~4,000 tons of CO2 equivalent (about 2,000 round trips London to New York). That’s for one training run. Of one model. That will be somewhat obsolete in 18 months.
Post-Training: Where the Chatbot Gets Its Personality
Pre-training gives you a model that predicts text. Post-training turns it into something that answers questions, follows instructions, and declines to help you synthesize nerve agents.
Two steps, both important:
Supervised Fine-Tuning (SFT): Show the model examples of good conversations. Human writes a question, human writes an ideal answer, model learns to imitate. Simple. Also surprisingly powerful. Also surprisingly data-efficient: the Lima paper showed that scaling from 2,000 to 32,000 SFT examples barely moves the needle. The knowledge was already in the pre-trained weights. SFT just redirects the model’s attention toward the kind of user it should be impersonating.
RLHF / DPO: This is where it gets interesting.
The key insight of RLHF: humans are better at judging answers than generating them. You can write a mediocre novel but tell a great one from a bad one. So instead of asking humans to write ideal answers, you ask them to pick which of two model-generated answers is better. Then you train the model to generate more of the preferred type.
The practical implementation: OpenAI did this with PPO (reinforcement learning), which works in theory and is a nightmare in practice. Dozens of hyperparameters, finicky outer loops, documented implementation complexity. A Stanford paper (DPO) showed you can get the same result by just directly maximizing the probability of preferred outputs and minimizing unpreferred ones, without the RL machinery at all.
Same performance. One-tenth the engineering pain.
One side effect the lecture flags: RLHF makes models verbose. Human annotators tend to rate longer answers higher, even when shorter ones are more correct. The model learns this preference and exploits it. If you’ve ever been annoyed at ChatGPT preambling for three paragraphs before answering a yes/no question, this is why. It’s not the model being thorough. It’s the model having learned that length signals quality to annotators.
The Part Nobody Talks About: Evaluation Is Broken
Honestly, this is the section I found most validating as a practitioner.
The lecture is unsparing: evaluation of LLMs is a mess. Perplexity depends on your tokenizer, so you can’t compare across models. MMLU scores vary wildly depending on exactly how you prompt the model and which of several equally valid evaluation methods you use. Llama 65B reportedly scored 63.7% on one benchmark and 48.8% on another, for the same task.
The leading solution: Chatbot Arena, where real users blindly interact with two models and vote on which one is better. It works. It also costs a fortune to run and is skewed toward tech-savvy users who ask questions about software errors and AI tools.
The cheap alternative: ask GPT-4 to judge. It’s 50x cheaper than human labelers, and agrees with human consensus more often than individual humans do (humans agree with other humans only about 66% of the time on these tasks, including the researchers who designed the evaluation).
That last data point should make everyone slightly uncomfortable and doesn’t get nearly enough airtime.
My Honest Read
I’ve been in rooms where teams are debating whether to use RoPE or ALiBi positional encodings, whether their attention is multi-query or grouped-query, whether their activation function is SwiGLU or GeGLU.
These are real choices. They’re also, empirically, not where the leverage is.
The teams that are actually winning in production are the ones who’ve figured out their data pipeline, who’ve built honest evaluation infrastructure that doesn’t just measure what’s easy to measure, and who’ve optimized their systems so that GPU utilization is above 40% (which, per the lecture, is already something to celebrate).
The architecture debates are real but secondary. As the professor puts it: “just train it for 10 hours longer, or wait for the next generation of GPUs. These things are really secondary.”
The lesson isn’t that architecture doesn’t matter. It’s that data, evaluation, and systems compound. Better data gives you better scaling curves, not just better intercepts. Better evaluation tells you where your model is actually failing before your users tell you. Better systems mean you can run more experiments, which means faster iteration, which means better everything.
The unsexy work is the work that matters. It was true in 2019. It’s still true now. It will probably still be true when the next generation of researchers is giving Stanford lectures about whatever comes after transformers.
-Hardik
The lecture: “This 2-Hour Stanford Lecture Explains How ChatGPT & Claude Are Built” — available on YouTube at youtube.com/watch?v=WSYAW4U7ZYc. Highly recommended for anyone building on or with LLMs.
Technical Architect (Data & AI) working on forecasting, AI systems, and MLOps at scale. Writes about AI infrastructure, engineering reality and the gap between how AI is explained and how it actually works in production.