What 4.5 Hours of Karpathy Taught Me About Being a Better Product Manager

I've been managing digital products for over ten years now. I've shipped AI-adjacent features and I use Claude Code daily. And yet, until beginning of this year, my mental model of what actually happens inside an LLM was embarrassingly vague. It was somewhere between "very smart autocomplete" and "stochastic parrot."

That was a big problem. You can't write good requirements, challenge engineering estimates, or design sensible quality criteria for a system you fundamentally don't understand. So I started my AI upskilling sprint where most engineers tell you to start: Andrej Karpathy's two YouTube lectures — the 1-hour "Intro to Large Language Models" and the 3.5-hour "Deep Dive into LLMs like ChatGPT."

And this gave me some good insights. Especially in how to think about AI products.

1. An LLM is a compression of the internet — and that explains almost everything

Karpathy's framing: pretraining takes a huge slice of the internet and compresses it into a few hundred gigabytes of neural network weights. The model learns to predict the next token, and in doing so, it's forced to learn grammar, facts, reasoning patterns, and world knowledge — because all of that helps predict the next token.

The PM implication is bigger than it sounds. The model doesn't retrieve facts, it reconstructs them from a lossy compression. That's why hallucinations aren't a bug you file a ticket for — they're a structural property of the system. A model asked about something at the fuzzy edge of its compressed knowledge will confidently generate something plausible, because generating plausible text is literally the only thing it does.

If your product design assumes the model "knows" things, you've already made your first architectural mistake. You design for reconstruction, not retrieval: ground the model with your own data (RAG), give it tools to look things up, and build verification into the UX.

2. The three training stages map directly to product levers

The deep dive walks through the full pipeline: pretraining (learn the internet), supervised fine-tuning (learn to be a helpful assistant by imitating human-written examples), and reinforcement learning (learn to reason by being rewarded for correct outcomes).

What clicked for me: each stage is a different product lever with different cost and control characteristics. Pretraining is out of your hands unless you're a frontier lab. Fine-tuning shapes tone, format, and behavior — expensive, slow to iterate. But the cheapest, fastest lever sits on top of all of it: the prompt and the context you feed the model at runtime.

This is why "context engineering" is becoming a real discipline. As a PM, the question shifts from "which model should we use?" to "what does the model need to see, at inference time, to do this job well?" That's a product design question, and it's ours to own.

3. Tokens explain the weird failures

Why do LLMs famously fail at counting the R's in "strawberry" or comparing 9.11 vs 9.9? Because the model never sees letters or numbers — it sees tokens, chunks of text that often cut words and numbers in strange places.

This sounds like trivia, but it's a diagnostic superpower. When your AI feature fails in a bizarre, "how can it be this smart and this stupid" way, tokenization is one of the first places to look. It also has direct cost implications: you pay per token, and different languages tokenize with very different efficiency. For anyone building products across English, German, and Chinese — as I am with NearBuy — that's a real line item, not an implementation detail.

4. "Models need tokens to think"

My favorite insight from the deep dive: a model's computation per token is fixed. It cannot pause and think harder — it can only think longer, by generating more tokens. That's what reasoning models actually do: they've been trained via reinforcement learning to produce long internal chains of thought before answering.

For PMs, this reframes the cost/latency/quality triangle. Asking a model to "answer in one word" isn't a formatting preference — you're actively removing its ability to reason. Conversely, every reasoning token costs money and time. Deciding where in your product deep reasoning is worth the latency (and where a fast, shallow answer wins) is a genuine product decision, and now I understand why it's a tradeoff rather than just accepting that it is.

5. The model is a simulation of a labeler — know when to trust it

Karpathy's grounding metaphor: when you talk to ChatGPT, you're effectively talking to a statistical simulation of the human data labelers who wrote the fine-tuning examples. For everyday knowledge, that simulation is remarkably good. For anything high-stakes, recent, or precise, it needs tools, retrieval, and verification.

That single sentence is basically an AI product strategy checklist. Where in your product is "an averaged expert answer, occasionally wrong" acceptable? Where is it a lawsuit? The answer determines your architecture, your UX (how you communicate uncertainty), and your eval strategy.

What I'm doing with this

This wasn't couch learning for its own sake, or just out of interest. Well, maybe a little bit, but the main thing was mostly to get deeper into the topic with real use cases that interest me. Building an eval suite for NearBuy. Because if hallucination is structural and quality is probabilistic, then defining and measuring quality becomes the core skill of the AI era. More on that when it breaks.

If you manage a product and haven't watched these two videos: it's the highest-ROI 4.5 hours you'll spend this quarter. Free, no math required, and afterwards you'll never let "we'll just add AI to it" pass through a roadmap discussion unchallenged again.