This week a wild build landed in r/PromptEngineering, and it’s not the usual “look what I vibe-coded” post. A 15-year-old poster from Iran who goes by Zero-AI-Native showed up with something called ZeroCancerReactor: an in-silico simulation of 70 million biological cells running on one RTX 3060 12GB, a card most people use for gaming, not computational biology. The original poster, u/ze707ro, says the whole thing came out of 15 marathon conversations with Gemini 3.1 Pro, something like 6 million tokens total, no dataset, no fine-tune, no training run at all. For context, that token count is roughly the length of a few dozen novels, all spent on architecture decisions, debugging sessions, and code review instead of prose.
The twist
Here’s the part that makes this worth a second look: the CUDA kernels, the immune-system logic, the organ models, all of it came out of a chat window, not a pipeline. This Redditor built a real C++/CUDA codebase across 73 phases of decisions and debugging, one long structured conversation at a time. The simulation models immune signaling (IL-2, T-cells, CD4/CD8), organ systems like liver, kidney, and brain, and a theoretical PID controller borrowed from how SpaceX steers Falcon 9, aimed at using cancer’s own runaway-replication trick to relengthen telomeres. That’s the kind of cross-domain mashup that usually needs a team: someone who knows immunology, someone who knows aerospace control theory, and someone who knows GPU programming well enough to make 70 million cells update in real time. Here it’s one teenager and a chat log. The creator is upfront that it’s 100% theoretical: no cure claims, no immortality claims, just a learning project. He even called out his own earlier post for sounding too AI-polished and rewrote this one by hand, which is its own small signal about where the discourse around AI-assisted work is heading. People are starting to police the tone of their own posts, not just the content.
The mini-workflow you can actually steal
Forget the cell count. The process behind it is the reusable part:
- 🧬 Lock the core struct first.
Cell.h, a 64-byte cache-aligned struct, got defined before any simulation logic, so every later phase had something stable to build on. Think of it as pouring the foundation before you frame the walls: once that struct was fixed, every organ model, every kernel, every immune-signaling function could assume the same memory layout instead of re-negotiating it phase after phase. - ⚙️ Split subsystems into named modules. Biological engine, CUDA kernel, immune network, and organs each got their own file and their own debugging thread instead of one giant blob of code. That separation is what let a single chat window stay coherent for millions of tokens; the model never had to hold the entire codebase in its head at once, just the module in front of it plus the shared interfaces.
- 📊 Log everything. 69 variables dumped to CSV every tick, so a 72,000-tick, multi-hour run is fully auditable instead of a “trust me, it works” claim. That’s the difference between a demo and a dataset. Anyone skeptical of the results doesn’t have to take the creator’s word for it; they can pull the CSV and check the immune response curve or the organ-stress numbers themselves.
- 🔁 Treat each chat as a scoped phase, not a one-shot ask. 73 phases means 73 rounds of “here’s what broke, here’s the fix,” not a single mega-prompt hoping for a miracle. Each phase closed with working, tested code before the next one opened, which is basically sprint discipline applied to a solo AI-assisted build.
Pro tip
The part worth borrowing has nothing to do with cancer biology. Long, complex AI builds hold together better as a sequence of scoped conversations anchored to one stable core file than as a single context-stuffed prompt. That’s the actual leverage here, and it transfers to any multi-week project you’re running with an LLM as a build partner, not just a 70-million-cell simulator. Whether you’re building a trading bot, a content pipeline, or a game engine, the same pattern applies: define the one struct or schema everything else depends on, split the work into named modules with clear boundaries, log every run so you can defend your results, and treat each session as a closed, testable phase instead of an open-ended brainstorm. Do that and you can run a project across weeks and dozens of sessions without the whole thing collapsing into spaghetti the moment you switch chats.
One commenter, u/Impossible_Candy9555, put it well: the CUDA kernel setup reads more coherent than what they’ve seen from CS undergrads, and the cache-line alignment in that Cell struct is a small detail that says the creator actually understood what he was building instead of just accepting whatever the model spat out. Other replies in the thread pushed back a little on the biology, pointing out that a theoretical PID controller for telomere length is a long way from anything clinically meaningful, and the original poster agreed without getting defensive about it, which is probably why the thread stayed civil instead of turning into the usual pile-on.
The full repo, including the CUDA kernels and that 69-variable telemetry dataset, is up on this teen’s GitHub, and he’s openly asking biologists and CUDA engineers to rip his codes apart in the comments. If you know your CD8 from your cache lines, go tell him where the model got it wrong 🔬
Frequently Asked Questions
Q: How accurate is this as a biological simulation?
Impressively creative for a 15-year-old, but with important caveats. The project simulates 70 million cells using Lotka-Volterra equations, but reviewers noted it functions more as a particle simulator with biological labels than true cellular dynamics. It’s a solid learning project , just don’t confuse it with validated biological modeling.
Q: How was the telomere length controller validated?
That’s still an open question. The PID controller logic is there, but there’s no mention of sensitivity analysis or phase portraits to formally test stability across different parameters. Standard practice for biological systems would involve rigorous validation work.
Q: What would actually prove this simulation works?
Start smaller: simulate a wound-healing response with a small cluster of cells responding to chemical signals, then verify the immune logic holds up before scaling back to 70 million. It’s the classic debugging move , validate the mechanism on a toy problem first.
Q: What’s the role of prompt engineering in this project?
It’s substantial. Across 15 conversations totaling ~6 million tokens, Gemini 3.1 Pro wasn’t just generating code , it was iteratively debugging, refining ideas, and working through 73 complex phases. That’s prompt engineering as collaborative problem-solving, not a shortcut to code generation.
Building an In-Silico simulation of 70 million biological cells on an RTX 3060 12 GB graphics card using prompt engineering and guidance of the Gemini 3.1 Pro model, with the ZeroMod prompt already active in all conversations.
by u/ze707ro in PromptEngineering