A year ago, the hardest question I had to answer at work was: “Why is the checkout button slow?” I was a backend developer building food-delivery and event-ticketing apps — real systems, real users, real money. But if something broke, the worst case was someone’s order got delayed. Today, the questions I help answer are very different.
A mother opens a chat window and types, “My son starts CAR-T therapy next month. Will he lose his hair?”
A clinician in another city asks, “What are the recent reported toxicities for CAR-T in pediatric leukemia?”
A researcher asks, “Show me the cytokine response data from the latest CAR-T trials.”
Three people. Three completely different needs. One disease. That is the system I am building at Cellogen Therapeutics — and it has changed how I think about engineering.
_page-0001.jpg)
From Servers to Cells
I spent the first 1.5 years of my career as a backend engineer. I worked on a US food-delivery app where I cut location-search latency from 420ms down to 180ms. I built event-ticketing platforms on Node.js, microservices on AWS, Redis caches, PostgreSQL pipelines. I was good at it. I was also, slowly, becoming restless.
The systems I built were technically beautiful, but the stakes felt small. A faster checkout. A cleaner search. Nothing that someone would remember the next day.
When I joined Cellogen Therapeutics earlier this year as an AI Engineer, the change was immediate. The code I write now sits between a patient and their treatment decision. That is not a metaphor — that is the actual job.
“The worst bug here is not a slow API. It is a wrong answer to someone who is scared.”
Why CAR-T, and Why It Is So Hard to Talk About
CAR-T therapy is one of the most powerful cancer treatments developed in the last decade. Doctors take a patient’s own immune cells, re-engineer them in a lab so they can recognize cancer, and put them back into the body. It has saved children with leukemia who had run out of every other option.
It is also extremely difficult to explain.
A patient wants to know — Will it hurt? How long is recovery? What side effects should I expect? Will I be okay?
A clinician wants to know — What is the dosing protocol? What are the contraindications? How do I manage cytokine release syndrome at the bedside?
A researcher wants to know — What are the latest trial results? What new CAR construct designs are emerging? Where are the gaps in the literature?
If you give all three the same answer, you fail all three. Most medical chatbots today do exactly that.
The System We Are Building
The CAR-T AI Agent at Cellogen has three doors — one for patients, one for clinicians, one for researchers. Same disease, same underlying knowledge base, but the system speaks to each audience in their own language. Behind those three doors is a pipeline I have been building and refining.
Layer 1 searches a curated library of biomedical literature using specialized medical embeddings. Think of it as a librarian who has actually read the papers — not just looked at the titles.
Layer 2 is a biomedical language model (BioMistral 7B) that I fine-tuned on a CAR-T-specific dataset, carefully curated from PubMedQA, MedQA-USMLE, iCliniq, and our own clinical Q&A pairs. It pulls out the precise facts and writes the answer.
Layer 3 is a safety net — six different general-purpose models behind a fallback chain, so that even when one provider is rate-limited or down, the user still gets an answer. They never see the failover. They just get help.
Fine-tuning that model was not glamorous. I spent weeks debugging a training loop that was silently failing on our new Blackwell GPU. The standard library (TRL’s SFTTrainer) was breaking in ways the documentation did not cover. I ended up writing my own training loop in PyTorch from scratch. The evaluation loss moved from 1.026 to 1.014 — a number that means nothing to most people, but to me it meant the model had finally started learning what I was teaching it.
Building an AI That Improves Itself
The piece of this project I am most excited about is something we call AutoResearch.
Fine-tuning a model is slow, repetitive work. You change one setting, wait three hours, look at the result, try another setting, wait three more hours. Over and over.
So I built an agent that does this on its own. It proposes new experiments, runs them, evaluates the results, and decides what to try next. It even handles its own crashes and retries gracefully when things go wrong in the middle of the night.
In a small way, the AI is helping me build a better AI. And the AI we are building is helping people understand a treatment that could save their life.
That chain — engineer builds tool, tool builds model, model helps patient — is the most meaningful thing I have ever worked on.
None of This Is Mine Alone
Everything I have described above sits on top of work that started long before I joined.
Within weeks of joining, team Cellogen trusted me with a hard problem, and the vision for a multi-portal medical AI — where the same knowledge can speak to a patient, a clinician, and a researcher without losing accuracy — comes from their leadership. My job has been to build the system underneath it.
The AI engineering team at Cellogen has been the kind of team I think every engineer hopes to find — researchers who patiently explain biology to me when I get lost in papers, fellow engineers who debug late into the night when a training run goes sideways, and a culture where it is okay to say “I don’t know yet” because someone next to you is going to help you find out.
None of this is mine alone. It belongs to all of us.
What I Have Learned
Good AI is invisible. The patient should not have to know about embeddings or fallback chains or LoRA adapters. They should just feel that they were heard, in a moment when most things in their life feel loud and frightening.
Good engineering is a kind of care. Every cache, every retry, every well-handled edge case is a small promise that the system will not let the user down at the worst possible moment.
I came to Cellogen looking for work that mattered. I found a team that is trying to make one of the most complicated cancer treatments in the world easier for everyone it touches — patients, doctors, scientists.
The code I write here is part of that. And that, for me, is everything.
