Zeke Lares
I lead engineering for my day job. In the hours that belong to me, I've been building something with no business case at all: an open-source attempt to look across the sprawling, fragmented literature of cancer therapy and ask a simple, stubborn question — which ideas actually deserve more attention, once you account for everything that usually gets ignored?
The honest answer to "why" is that the problem has the exact shape an engineer can't leave alone. Thousands of research literatures mature in parallel, rarely compared on the same axes. Nobody had laid them side by side on shared terms like evidence depth, resistant-state biology, tissue access, or delivery constraints. That's not a biology gap so much as a systems gap — and systems gaps are the thing I do.
Reading at a scale no human can
The first half of the project is a cross-literature analysis. I pulled together a corpus of 4,830 full-text, PubMed-indexed articles spanning 803 journals, 19 therapeutic mechanisms, and 22 cancer types from 2001 to 2026, alongside a separate archive of more than five thousand abstract-only records.
4,830 full-text papers · 803 journals · 19 mechanisms · 22 cancer types · 2001–2026 — plus 5,585 abstract-only records, mapped onto shared axes so mechanisms can finally be compared rather than admired in isolation.
No human reads 4,830 papers and holds them in their head at once. So I built tooling — with a heavy assist from modern AI — to tag and structure the evidence. And here's the part I'm proudest of as an engineer: I measured the tool against a hand-labeled gold set instead of trusting it. It scored 96% binary precision but only 55% recall and 46% exact-label accuracy. Those are not flattering numbers, and I published them anyway, because a synthesis that hides the error bars of its own instrument isn't science. It's marketing.
Simulations as a claim-testing engine
The second half is where the Rust comes in. On top of the literature landscape I built a simulation library — MIT-licensed, with Python bindings — that acts as a claim-testing engine. The point isn't to declare a winner among therapies. It's to take specific mechanistic claims and bound the conditions under which they could plausibly hold, across cell phenotypes, tissue depth, drug-penetration gradients, oxygen gradients, and combinations.
The simulations don't tell you which therapy wins. They tell you which claims survive contact with resistance, depth, and a hostile tumor microenvironment.
A few representative results, stated as exactly what they are — computational predictions, not clinical verdicts: dual inhibition of two parallel pathways produced nearly a 2× synergy in the model; a drug whose kill rate looks strong in a flat dish collapsed once simulated hypoxia or a blood-brain-barrier-like penetration gradient was introduced. The useful output isn't a ranking. It's a sharper sense of which interventions remain plausible after you stop pretending the body is a petri dish.
Why Rust, and why open
Rust because these are Monte Carlo and spatial simulations — millions of iterations where a slow inner loop means the difference between a question you can ask and one you can't. And because when you're making claims with numbers, you want a language that won't let a silent memory bug quietly corrupt your conclusions.
Open because the entire premise falls apart otherwise. All the code, the analysis pipelines, and the data are public, so anyone can replicate, disagree, and extend. I am not an oncologist, and I'm careful to say so. What I can contribute is the thing I'm actually good at: building a rigorous, inspectable system and refusing to overclaim what it shows.
// the engine's job, in one line of intent fn test_claim(claim: Hypothesis, env: TumorMicroenvironment) -> Bounds { monte_carlo(claim, env, iters: 1_000_000) // not "is it true" — "under what conditions could it hold" }
What it taught me
Engineering and science share a discipline that's easy to forget under deadline pressure: the willingness to be wrong on the record. Shipping this project in the open, error bars and all, was the most clarifying thing I've done in years. It also made me a sharper engineer at the day job — there's nothing like measuring your own tagger's recall to make you humble about every dashboard you've ever trusted.
The manuscript is finished and headed to Amazon. But the part that matters is already free, forever, on GitHub. If you can poke a hole in it, I'd genuinely like to hear it. That's the whole point.