What a senior design team taught me about mentoring in the AI era

I spent the last two semesters mentoring five biomedical engineering undergrads at the University of Georgia on what should have been an impossible capstone: design an extracorporeal bioartificial liver, and build a digital twin to validate it.

It worked. Not just on paper. They have a 6-module simulation that runs in real time, a hardware design that's been costed and specced, and clearance numbers that hit clinical thresholds. The kind of thing that, three or four years ago, would have been a startup's first year of work.

People keep asking me whether AI is what made the difference. The honest answer is: not really. Or at least, not the way most people think.

A quick word on why this matters

Acute liver failure kills somewhere between half and four-fifths of the people it touches. There are not enough donor organs to go around, and patients usually do not have time to wait for one. Dialysis can pull some toxins out of the blood, but it cannot do what the liver actually does — convert ammonia into urea, break down drugs through the CYP450 enzymes, synthesize the proteins the body needs to keep running.

A bioartificial liver tries to fill that gap. You route the patient's plasma through a cartridge that holds living liver cells, separated from the bloodstream by a thin membrane. The cells do the work the failing liver cannot.

The concept has been around for decades. The engineering is what stops it from being routine. Cell density, membrane area, flow rate, residence time, and a control system that can guarantee safety before any blood goes back to the patient — every one of those is its own problem.

The thing AI actually changed

Two years ago, a senior design team would have spent most of their year on literature review and cell culture protocols. Today that work compresses to a few weeks. What used to be the project is now the prerequisite.

Andrej Karpathy has been talking about something he calls autoresearch — the idea that you can run the loop of hypothesis, simulation, and iteration with an LLM as a working collaborator, not just a search engine. Claude Code does this for me daily. The team used it to generate, test, and refactor a 1,900-line simulation engine over the course of a semester.

But here is what I kept coming back to as I watched them work: none of that helps if the problem itself is shaped wrong. A vague prompt to "simulate a bioartificial liver" gives you back vague, unverifiable code. The decomposition has to happen first, in your head, before the tool is any use to you.

That is where I think mentorship has shifted. So I want to talk about three specific things I did with this team that I think are worth other mentors stealing.

One: redrawing what is possible

The team showed up with the assumption that "designing a BAL" meant cell culture, prototypes, and a long road of bench work. That is how the field has always been taught. It is also why senior design teams typically pick smaller projects.

What I told them in our first month was that they did not need a wet lab to start. They could explore the entire design space in simulation first. Build the digital twin. Run the parameter sweeps. Find the topology that actually clears toxins to safe levels. Then, and only then, does the bench work become useful — as confirmation, not exploration.

That conversation changed the scope of the project from a multi-year research program into something they could finish.

A lot of what I do in industry is exactly this. The most valuable thing I bring to a room is usually not the answer to a hard question. It is a different read on what counts as the question.

Two: changing how they read papers

Most students I meet use LLMs the way they once used Wikipedia. Type in a question, get a paragraph, paste a citation, move on.

I gave the team a different habit. Instead of asking ChatGPT or Claude to "explain hepatocyte ammonia metabolism," I had them ask: model this as a system. What are the state variables. What are the transitions. What are the boundary conditions.

That small reframe changed how they read literature. A paper on the urea cycle was no longer prose to summarize — it was a source for rate constants. A paper on membrane transport gave them boundary conditions. The LLM became a useful collaborator because the questions had structure.

The other half of this habit is verification. Every constant they pulled out of an LLM response had to triangulate against a primary source. Every assumption had to survive a stoichiometry check. The model is wrong often enough that you cannot skip this step. Knowing what to ask is half of AI fluency. Knowing what to verify is the other half.

Three: the through-line

This is the one I care about most.

The wet-lab way of thinking about a BAL treats it as one big object. A bioreactor wired to a patient. That mental model is what makes the problem feel impossible for a five-person team in two semesters.

So I kept pushing them to decompose. Not just the bioreactor, but every piece of the system, as its own state machine with its own transitions and failure modes.

• The plasma separator: 6 states.
• The pump and its safety interlocks: 12 states.
• The bioreactor: two compartments, 10 coupled differential equations, 5 high-level states.
• The mixer: 10 states.
• The return monitor that gates whether blood goes back to the patient: 11 states.
• The sampler: 5 states.

43 states across 6 modules. Once they could see the device this way, the project changed character. The simulation architecture wrote itself, because each module was already a class with a state, a transition function, and an output. Alarm logic stopped being something they would handle later and became part of every state. And the AI tools they were using suddenly became more useful, because a prompt for "generate the pump state machine with these twelve states and these transitions" is something an LLM can actually do well.

You cannot prompt your way out of a monolithic problem. But a problem already broken into 43 small ones is well within what a small team and a capable model can build together.

Closing thought

The team still had to know hepatocyte biology. They had to understand Fick's law, the urea cycle, CYP450 kinetics. None of that was outsourced. What changed was the time it took to turn that knowledge into working code.

Which means the mentor's job has shifted, at least as I see it. It used to be mostly about teaching the technique and supervising the build. Now I find myself spending more time on the framing — on whether a problem has been broken down well enough that the tools available today can actually help, and on whether the team has the verification habits to catch the model when it is wrong.

Sabrina, Ivy, Grace, Namit, and Anna built something I am genuinely proud of, and the work belongs to them. Dr. James Kastner advised. I had the easier job.

If you want to see the device, the topology, the live simulation output, and the math behind it, the full project page is here.