⏱️ Lectura: 11 min
Laurentiu Raducu couldn’t find a tutorial that explained chip manufacturing in a memorable way, so he decided to try a different approach to learning with LLMs: he asked Claude Code to turn it into a video game. The result is called ChipTycoon: a low-poly simulation, in the style of Rollercoaster Tycoon, where a cart travels through every stage of a semiconductor factory, from sand to the finished chip in a data center.
📑 En este artículo
Raducu, who researches the bottlenecks that could slow down the construction of data centers for AI, documented on his blog the complete workflow he used for learning with LLMs without relying on superficial summaries. He also applied it to rocket engines, Formula 1 engines, and the inner workings of language models themselves.
TL;DR
- Laurentiu Raducu created ChipTycoon, a site that simulates chip manufacturing from start to finish.
- He used Claude Code and OpenCode in plan mode to build the topic’s knowledge base.
- He asked the model to review that base’s accuracy before generating visual content.
- The simulation is a low-poly animation in the style of Rollercoaster Tycoon, navigable by the user.
- The project is published for free on GitHub Pages, with no hosting cost.
- He has already applied the same technique to rocket engines, Formula 1 engines, LLMs, and EUV machines.
- He proposes adding his image-to-3D-object conversion skill to improve realism.
- He suggests adding questions and challenges inside the simulation to reinforce retention.
Introduction: Learning with LLMs Beyond the Summary
Learning with LLMs usually means one thing: asking a chatbot to summarize a topic and getting a bulleted list back. Raducu, who closely follows AI infrastructure bottlenecks, noticed that this format didn’t help him retain concepts with many sequential steps, like a semiconductor production line. Instead of pushing for more summaries, he changed the goal: he asked the model to build something he could walk through visually, not just read.
The idea came up while he was researching what could slow down the expansion of the data centers that power today’s AI models. Manufacturing a modern chip involves dozens of steps (silicon purification, lithography, etching, doping, packaging) that are rarely explained with as clear a mental image as a subway map. What was missing was a way to map each technical concept to a concrete visual object.
What Happened
Raducu published on his blog the four-step workflow he used to build ChipTycoon with Claude Code and OpenCode, both operated in plan mode, the mode in which the agent plans first before writing any code. First, he asked the model to build the knowledge base for the chosen topic. Second, he asked the same model to review that base for errors or excessive simplifications before moving forward. Third, he asked it to translate that verified knowledge into a navigable low-poly animation, with controls designed for both large and small screens. Fourth, he pushed the result to a new repository and enabled GitHub Pages to publish it at no hosting cost.
The result, as the author himself describes it, is an accurate, hallucination-free animation, in contrast to what he got from reading scattered materials online or digesting bulleted lists generated by a language model. The user follows a cart that changes shape and content as it moves through each manufacturing stage, offering a constant visual reference of the product’s progress along the line.
Context and Background
ChipTycoon isn’t an isolated experiment. Raducu had already applied the same technique to other dense technical topics: how rocket engines are built, how Formula 1 engines work, how an extreme ultraviolet (EUV) lithography machine is assembled and, in a reflexive twist, how the very language models he used to build everything else actually work.
The pattern repeats in every project: first build the knowledge base with the agent in plan mode, then audit it with the same model, and only at the end convert that verified knowledge into a visual experience. It’s a variation on the principle of mapping abstract concepts to concrete objects, something management simulators have exploited for more than two decades, though they had never been used systematically as a personal study method backed by an LLM.
What’s different here isn’t the low-poly format itself (any design studio could produce an animation like that), but that the entire pipeline, from research to the simulation’s code, runs through an AI agent without the author manually writing either the educational content or the graphics engine.
Technical Details and Performance
The complete workflow has four clearly distinct stages, and each one depends on the previous one having been resolved correctly.
flowchart TD
A["Prompt in plan mode"] --> B["Claude Code builds the knowledge base"]
B --> C["The same model reviews accuracy"]
C --> D["The low-poly simulation is generated"]
D --> E["Push to a new repo"]
E --> F[("GitHub Pages")]The first stage happens in plan mode: the agent doesn’t write code yet, it just organizes what needs to be explained and in what order. In the second stage, Raducu explicitly asks the model to review its own work, a step that acts as a verification layer before that knowledge gets translated into visual assets. Without this review, any error from the first stage carries straight through to the final simulation.
⚠️ Heads up: skipping the review step is the most common way to end up with a simulation that’s visually polished but technically wrong. The model that generated the content is also the best auditor available for that same session, but only if you explicitly ask it to be.
The third stage converts the verified knowledge into low-poly 3D objects and the logic that moves the cart between stages. The level of detail is deliberately low: low-poly isn’t aiming for photorealism, it’s aiming for each process step to have a recognizable silhouette distinct from the last one. The fourth stage is the simplest in technical terms: a git push to a new repository and enabling GitHub Pages.
Compared to other study formats, Raducu’s method occupies a particular niche:
| Method | When to use it | Advantage | Limitation |
|---|---|---|---|
| Reading documentation or papers | When you need exhaustive precision and citable references | Information verified by experts | Slow and easy to abandon halfway through |
| Asking an LLM for a text summary | For a quick first approach to a new topic | Saves search time | The bulleted-list format doesn’t help retain complex concepts |
| Interactive low-poly simulation | For processes with sequential steps, like a production line or a pipeline | Maps each concept to a visual object you can walk through | Requires upfront build work and a verification stage |
| Simulation with challenges and questions | When the goal is long-term retention | Forces active recall of what was learned | More development time than a passive simulation |
How to Get Started
Reproducing this workflow with your own topic doesn’t require exotic tools: a code agent with plan mode support and a minimal web project are enough.
First, install the CLI for the agent you’re going to use. With Claude Code, the install command is the same on Windows, macOS, and Linux because it runs on Node.js: on Windows open it from PowerShell or Git Bash, on macOS and Linux from any POSIX terminal.
npm install -g @anthropic-ai/claude-code
claudeThat last command opens the interactive session. Inside, activate plan mode and ask the agent to build the knowledge base for your topic, for example: “explain step by step how a fusion reactor works, from the fuel to the electricity delivered to the grid.” Then explicitly ask it to review that base for errors before moving forward.
With the knowledge verified, the next step is scaffolding the simulation. A minimal project with Vite and three.js is enough for a low-poly prototype:
npm create vite@latest mi-simulacion -- --template vanilla
cd mi-simulacion
npm install three
npm run devWith the project running locally, a simple example of the logic that moves the cart between stages might look like this:
const etapas = ['arena', 'oblea', 'litografia', 'grabado', 'empaquetado', 'datacenter'];
let etapaActual = 0;
function avanzarCarrito(carrito) {
etapaActual = (etapaActual + 1) % etapas.length;
carrito.position.x += 2;
carrito.userData.etapa = etapas[etapaActual];
console.log(`Cart now at: ${etapas[etapaActual]}`);
}That function is just the skeleton: in practice, it’s the agent that generates the low-poly geometry for each stage and the camera logic. Once the prototype works locally, the last step is publishing it.
💡 Tip: create the repository on GitHub before asking the agent to start generating code, so you can directly ask it to make incremental commits per stage instead of one giant commit at the end.
To publish, push the project to a new repository and enable GitHub Pages from Settings, Pages, Deploy from a branch, pointing to the build folder. To confirm the deploy is live, you can check the HTTP response of the published site:
curl -I https://tu-usuario.github.io/mi-simulacion/A HTTP/2 200 response confirms that GitHub Pages is already serving the site. If it returns 404, wait a few minutes: the first Pages deploy can take a while to propagate.
Impact and Analysis
Raducu’s case matters less for ChipTycoon itself than for the workflow it documents: separating research, verification, and content generation into three distinct steps within the same agent session. It’s a replicable pattern for anyone who wants to try learning with LLMs without getting stuck at the superficial summary level that a generic chat usually produces.
The author himself acknowledges the most honest limitation: low-poly, being deliberately simple, demands a fair amount of imagination to visualize fine details, like what exactly happens to a silicon crystal as it comes out of a growth furnace. For processes where visual detail matters, like distinguishing textures or materials, a low-poly simulation can fall short compared to one rendered with higher fidelity.
Raducu himself proposes a path for improvement: running the low-poly objects through an image-to-3D conversion model to achieve more realistic representations of the result at each stage, without abandoning the navigable simulation structure.
What’s Next
The clearest extension the author suggests is adding challenges and questions inside the simulation: asking the user to answer something about the previous step before letting them move on to the next one. That layer of active recall, answering instead of just watching, is one of the mechanisms with the strongest evidence for consolidating long-term memory, and it fits naturally into a format that’s already interactive.
Raducu also published links to his other projects using the same technique: rocket engines, Formula 1 engines, EUV machines, and the inner workings of LLMs, all hosted with the same public-repo-plus-GitHub-Pages setup. Nothing suggests the author plans to turn this into a product or business: for now it’s a personal study practice he decided to document and share.
📖 Summary on Telegram: View summary
Try it yourself: open a Claude Code session in plan mode right now and ask it to build the knowledge base for a topic you want to master before generating anything visual.
Frequently Asked Questions
What is ChipTycoon?
It’s an educational website created by Laurentiu Raducu that simulates, with a low-poly animation in the style of Rollercoaster Tycoon, the complete chip manufacturing process: from silica sand to the chip installed in a data center.
Do I need to know about semiconductor manufacturing to understand it?
No. The project’s stated goal is precisely that someone with no prior knowledge can follow the process step by step through the cart’s visual journey, without relying on prior technical jargon.
Which AI agent did the author use to build it?
Raducu documented having used Claude Code and OpenCode in plan mode to build the knowledge base before generating the simulation.
Does this method work for any technical topic?
It works best with processes that have clear sequential steps, like a production line, a network protocol, or a data pipeline. For topics without a step-based structure, the simulation format may not add as much value compared to a well-organized text.
How does he avoid the simulation having model errors?
By asking the same agent to explicitly review the knowledge base before generating the visual part. That audit step is what the author identifies as key to reducing hallucinations in the final result.
What other topics has he covered with this technique?
Rocket engines, Formula 1 engines, EUV lithography machines, and the inner workings of language models, all published as independent sites using the same approach.
References
- How I use LLMs to learn complex topics: Laurentiu Raducu’s original post with the complete workflow and links to each project.
- GitHub Pages Documentation: official guide for publishing a static site directly from a repository.
- Claude Code Documentation: official documentation for the agent used to build the knowledge base and the simulation’s code.
- Three.js: the WebGL 3D rendering library commonly used for this kind of low-poly simulation in the browser.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de EqualStock en Unsplash
0 Comments