TL;DR
The fastest way to learn complex topics with Claude Code is to have it build a small interactive simulation of the mechanism instead of just explaining it: write a spec, run a fact-check gate before anything renders, build the simulation, then ship it free on GitHub Pages. The gate is the step people skip — an LLM states a wrong constant as confidently as a right one, and a wrong number you built yourself is harder to unlearn than one you skimmed.
What is simulation-first learning?
A complex mechanism you can manipulate teaches you faster than the same mechanism described in prose, because building it forces you to specify every state, transition, and threshold the prose was allowed to leave vague.
The idea surfaced recently in a developer's write-up of the technique, who used it to build low-poly, game-like simulations of chip manufacturing and rocket engines with an AI coding agent, then deployed them as free static sites. The write-up doesn't cite a study — it's one engineer's account of what worked for them — but the mechanism it describes is worth taking seriously on its own logic, not on the strength of the anecdote.
Why reading doesn't stick
Prose lets you nod along without ever committing to specifics. You can read "TCP backs off exponentially after a loss" ten times without ever being forced to say what the multiplier is, when it resets, or what happens if two losses happen inside one round trip. None of that ambiguity survives contact with a simulation: to render the mechanism, the agent needs the exact threshold, the exact trigger, the exact edge case — and so do you, because you're the one reviewing its plan.
That review step is the actual learning event. Not the animation. The animation is just the artifact that proves your specification was complete and correct.
The 4-Step Loop to Learn Complex Topics With Claude Code
- Write the spec. In plan mode (or an equivalent read-only planning step), describe the mechanism you want modeled: the states, the transitions between them, the numbers that govern the transitions. Keep it to the level of detail you'd want in a design doc, not a Wikipedia summary.
- Run the fact-check gate. Before anything gets built, ask the agent to restate every constant and rule back to you and to flag anything it's unsure of. This is the step that catches a wrong exponent before it becomes a diagram you trust.
- Build the simulation. Turn the reviewed spec into an interactive page — a canvas animation, a small game-like scene, whatever renders the state machine as something you can step through or nudge.
- Ship it. Push it to a public repo and turn on GitHub Pages so it survives past your current terminal session. A simulation stuck on your laptop doesn't get revisited; a URL does.
Step 2 is the one people skip, because it feels like friction between you and the fun part. It's also the only step in the loop that isn't optional — everything downstream inherits whatever it gets wrong.
A spec for step 1 doesn't need to be long. For the worked example below, it's four lines: name the states (slow start, congestion avoidance, loss recovery), name the variable each state changes (cwnd), name the trigger that moves between states (ssthresh crossing, a detected loss), and name the one number you're least sure of so the fact-check step knows where to focus. That last line is the one people forget, and it's the highest-leverage one — it tells the agent exactly where to spend its verification effort instead of skimming everything equally.
Which topics are worth simulating?
Not every topic compresses into something you can watch move. The ones that do share a property: they're state machines or numeric processes with a small number of variables driving the behavior. The ones that don't are the ones where the hard part is judgment, not mechanism.
| Fits well | Doesn't fit |
|---|---|
| TCP congestion control | Contract law doctrine |
| Consensus protocols (Raft, Paxos) | Historical causation debates |
| CPU pipeline hazards | Ethical frameworks |
| Physics (orbital mechanics, gas laws) | Style and taste judgments |
| Compiler passes (parsing, register allocation) | Open philosophical questions |
If you can't name the three or four variables that drive the whole mechanism, that's a sign the topic is judgment-heavy, not mechanism-heavy — and no amount of animation fixes that.
Worked example: simulating TCP congestion control
Take one from the "fits well" column. TCP's congestion window (cwnd) doesn't ramp up linearly — it starts in slow start, roughly doubling every round trip, until it crosses a threshold (ssthresh), then switches to congestion avoidance, growing by about one segment per round trip. On a packet loss, ssthresh is set to half the current window and cwnd drops back down, per the additive-increase, multiplicative-decrease behavior in RFC 5681.
Written as prose, that's three rules and two numbers. Specified for a simulation, you have to nail down all of it before anything renders: the exact growth rate in each phase, the exact trigger for switching phases, the exact drop factor on loss. That's the fact-check gate doing its job — a wrong "cwnd resets to zero on loss" instead of "cwnd resets to ssthresh" is a plausible-sounding error an ungated build would happily animate.
The resulting simulation is small: a chart of cwnd over time with a slider for round-trip time and a button to inject a loss event. But building it means you now know, precisely, what triggers the phase change and what the recovery curve looks like — which is the part a paragraph about "exponential backoff" never actually pins down.
Where does this method break?
The failure mode isn't the simulation being wrong — it's skipping the gate that would have caught it. A convincing animation is more persuasive than a paragraph, which means an unverified simulation is worse than no simulation: you leave with false confidence instead of appropriate uncertainty. The second-most-common failure is scope creep — turning a 20-minute model of one mechanism into a multi-day game with levels and a scoring system, at which point you've built a side project, not learned the topic. Keep the first pass small enough to finish in one sitting; add polish only if you're coming back to the same topic later.
What this isn't
This is one technique for a specific kind of topic, not a general study method, and the source idea behind it is a single developer's account, not a benchmarked result. It also doesn't replace spec-first thinking or writing agent instructions carefully in general — if anything it's the same discipline applied to a learning goal instead of a production feature. The habits that make a CLAUDE.md useful — being precise about what the agent needs to know and cutting everything it doesn't — are the same habits that make the spec in step 1 tight enough to be worth building.
If you're evaluating this alongside other ways to spend a learning hour, it sits closest to the deliberate-practice end of the developer productivity toolkit: higher setup cost than reading, lower cost than a full course, and it only pays off on topics with an actual mechanism to model.
FAQ
Does building a simulation with an LLM actually help you learn a complex topic?
There's no controlled study behind this, only a strong anecdotal pattern: building forces you to specify every state and transition, which is a form of active retrieval that passive reading skips entirely. If a mechanism is spatial or state-based, mapping it to objects you can move gives you a second, non-verbal handle on the same fact — which is why it sticks better than notes for those topics specifically, not universally.
What kinds of topics work well for this method?
Anything with an explicit state machine or a numeric curve: network protocols, scheduling algorithms, physics, compiler passes, consensus protocols. Topics that are mostly judgment calls — law, ethics, historical causation — don't compress into an animation, because the hard part isn't the mechanism, it's weighing competing interpretations.
Why does the fact-check step matter before building the simulation?
An LLM can state a wrong constant — the wrong initial window size, the wrong backoff factor — with exactly the same confidence as a correct one. Once that number is animated, it looks authoritative, and a wrong mental model you built yourself is stickier and harder to unlearn than a wrong line you skimmed.
Do I need to know how to code to use this technique?
No. The point of using an agentic coding tool like Claude Code is that you describe the mechanism in plan mode and review the plan in plain English before anything gets built. You still need to be able to read the plan critically enough to catch an error — that review step is where you learn, not the typing.
How is this different from just asking an LLM to explain a topic?
An explanation is consumed passively and forgotten at roughly the rate of any other reading. Specifying a simulation forces you to answer questions an explanation glosses over — what triggers this transition, what's the exact threshold, what happens at the boundary — because the agent needs those answers to build something that runs.
Is this the same as spaced repetition or flashcards?
No, and it isn't a replacement for one. Flashcards test recall of a fact you already have; this method is how you get a correct, structured mental model into your head in the first place. The two combine well — turn the simulation's edge cases into your flashcard deck afterward.
Sources
- How I use LLMs to learn complex topics — the developer write-up that surfaced this technique.
- RFC 5681, TCP Congestion Control — the slow-start and congestion-avoidance rules behind the worked example.
- GitHub Pages: Creating a GitHub Pages site — free static hosting for the shipped simulation.
Originally published at umesh-malik.com
Keep reading on umesh-malik.com:
Top comments (0)