Session 2.3 · Eric Kercher, RNA Therapeutics Institute, UMass Chan
AI-assisted development of web apps for science.
How a wet-lab postdoc with beginner Python built a research tool his lab now runs, in five months, and how you can start next week. The tool is not the interesting part. The interesting part is that a wet-lab scientist could make it, and how he knows the code is right.
“Coding is no longer the bottleneck. Thinking is.”
For science, a sharper version: the bottleneck was never writing code. It was that nobody could afford to own the tool.
What the talk covers
Why code at all. Ask a language model the same question twice and you can get two different answers. A script gives the same answer every time. So do not ask AI for the answer; ask it for the thing that produces the answer: “Write a script that reads my data and generates a scatter plot”, not “Create a scatter plot from my data”. That turns “is this answer right?” into “is this code right?”, which you can test.
The problem. A transcript has roughly 3,000 candidate siRNAs, and a lab can synthesize and screen about 100. The lab was choosing with a basic design portal and a chain of hand-edited Excel templates, because improving them needed a programmer nobody had.
The build. One toolkit that goes from gene to siRNA in a few clicks, written with Claude, Python, Streamlit (which turns a Python script into a web app), and GitHub for save points. A little terminal, less than you would think. Cost: a $100 a month subscription, paid by the lab.
How the work goes. Start with what a user should be able to do. Ask for a plan in chunks, read it, and approve it before any code is written. Then loop: prompt, test, review, debug. Commit after each chunk that works. In Eric’s words, it feels like supervising “a very fast, very capable, occasionally overconfident rotation student.”
The honest caveat. AI-written code fails silently and plausibly, not loudly. A gene lookup for BCAM also returned BCAT2, and 26 automated tests still passed, because the tests checked his assumption rather than reality. Every failure was caught because he knew what the answer should look like.
Trust through verification. The same controls you use at the bench: a positive control (do I get a known right answer?), a negative control (do I get noise from noise?), a gold standard (can I reproduce another tool?), plus variation, integration, hold-out, and nonsense tests. His positive control: scored against a drug already in the clinic, the model ranked the real drug’s site second of 516.
Checking the literature. When AI writes prose instead of code, ask for DOIs or PMIDs and actually check one or two, and prefer tools grounded in documents or databases you trust.
What made his first prompt work
Ask the basic question first, and let it confirm or correct your intuition.Do not dive in headfirst
Describe the workflow in your own domain language.No technical vocabulary needed
Ask for a plan before any code, then work in chunks you can test one at a time.Plan first
End with “ask me questions”, and let it find the holes in your request.Make it interview you
PROMPT Read Eric’s very first prompt, as he wrote it
I want to build a application and toolkit for designing siRNAs. What is the best programming language(s) to accomplish this? List a couple options and list the pros and cons of each. The general workflow should look like this: User defines/or selects a species, gene of interest. The application should then look up all accession numbers associated with that gene and let the user select one. Then the application should download that specific gene and then compute every possible siRNA against that genetic code. The output should be a table of every siRNA and their properties. Help me plan out a work plan to be able to use Claude Code to build this application. Ask me for clarification and context whenever possible.
He did not know Python or GitHub when he wrote this. None of that stopped the first day being productive.
Two cases to think about
CASE 1 The cell counter: what would you tell her to check?
A postdoc with no coding experience builds a tool in one afternoon: drag in folders of fluorescence images, it counts cells and reports the percent GFP-positive per well, with a bar chart. 24 images, 8 wells. Control 11% positive, treatment 42%, p < 0.001. The chart is beautiful, and she wants it in Thursday’s lab meeting.
She ran the treatment folder by itself, without the controls, and treatment dropped from 42% to 29%. The tool set its brightness threshold from the brightest image in whatever folder it was given, so the answer depended on which images were in the folder, not on the biology. A variation test would have caught it.
CASE 2 The extractor: how would you verify it?
A clinical fellow asks AI to read 200 trial reports and extract drug, dose, primary outcome, and whether serious adverse events were reported. Ten minutes later he has a clean spreadsheet: 200 rows, every cell filled.
The talk leaves this one open. Which rows would you check by hand, and what would a positive and a negative control look like here? “Every cell filled” is itself a warning sign.
Take home
Ask for the script, not the answer. That is how a result becomes reproducible.Reproducibility
“Make me a plan” and “ask me questions” are the two highest-value phrases you can learn.Prompting
Work in chunks. Commit after each one.Save points
The AI writes the code. You own whether it is right.Verification
Start on Monday. Pick the smallest annoying thing you already do by hand every week. Open an AI tool, start a project, point it at a folder with a real file in it, and tell it what you want in your own words. Expect a working first version within an hour, and expect to fix it three times.
PROMPT Eric’s starter prompt
I want to build a small tool that does [X]. I'm a biologist with little coding experience. Ask me clarifying questions first, then give me a step-by-step plan in chunks I can test one at a time. Don't write any code until I approve the plan.
Then try it in 2.4 Hands-on: the wrap-up asks Claude for the script rather than only the plots, and the stretch step’s shuffled data is a negative control, noise from noise.
About the speaker
Eric Kercher is a postdoc in the Alterman Lab at the RNA Therapeutics Institute, UMass Chan, where he makes siRNAs. He is not a software engineer: some prior coding, no formal computer science training, and beginner Python when this project started. Five months before this talk he could not build a web app. His lab now runs one he built.