Editor’s note: we’ve been looking for the ground truth underneath the AI-for-science hype for a while and so are excited to depart from our usual format to bring you this field report from Nelson Ndahiro on his experience working with AI agents in hands-on biological experiments. Nelson earned his PhD at Johns Hopkins, is the CTO of a startup developing saliva-based diagnostics, and was recently called “one of the most interesting young African scientists of his generation” in a profile in The East African.
If you are a scientist using AI in your daily work, we’re interested in publishing more field reports of this type.
Around January of this year, I realized that AI models, specifically in the form of coding agents like Claude Code and Codex, got quite good. They’re no longer just chatbots: they can write code, use your computer, run software, and increasingly act as an interface to all the other things sitting on your computer. It’s a big deal, but what does that actually mean for experimental scientists in the lab, that do a lot of our work outside of our computers? Is this so-called “revolution” meant only for our in-silico friends?
I don’t think so. They’ve been genuinely helpful for me. The core theme, for me, has been minimizing the cognitive burden of being a scientist at the bench. More specifically, reducing the distance and friction between a scientific question and the operational work required to answer it.
That distinction matters. We tend to think of the scientific process as something like question → experiment → result. But the actual transition between those things is full of small decisions. Specifically decisions around pipetting, reagent arithmetic, inventory management and others. None of these decisions are particularly intellectually interesting. But they are everywhere and they require real cognitive effort before we can even exercise thought on the interesting parts of research. After some time delegating some of this thinking to coding agents, I started to realize how cognitively overloaded I’d been before.
What follows is what that looks like in practice for me and my company. A primer on what it increasingly feels like to go into the lab without that particular kind of dread hanging over my head.
(In this essay I’ll use Claude, Claude Code, Codex, “agent” interchangeably, they are all shorthand for a coding-agent on your computer, not a website-based chatbot.)
Delegating pipetting decisions
One of the most tedious parts of lab work in the life sciences is routinely preparing and running well-plates to answer specific biological or chemical questions.
On the surface, the actual act of pipetting seems like the arduous task. But I’d venture to say that all the cognitive effort needed to go from experimental question to well-plate design can be just as exhausting, if not more so. Every experiment is slightly different, so even a highly optimized Excel template inherited from a senior lab-mate needs significant tailoring and human decision-making for each run. Which reagent goes in which well, which pre-allocation pool or dilution scheme to prepare, where to place conditions and how to keep track of them, how many replicates, which internal control and standard to run, how much reagent it will all consume, whether it fits on one plate or needs two? These are all decisions that drain your cognitive budget every single time an experiment runs.
In theory, if all of this is already decided, the pipetting itself is the easy, if perhaps boring, part. And by the way, having a liquid-handling robot doesn’t excuse you from any of this! Even with a nifty Eppendorf or Hamilton, the burden of all these cognitive steps still lives with you. Experimental science is fraught with these mini-decisions: individually small, but they pile up in your mind, slowing you down, killing motivation, and occasionally causing expensive mistakes.
So where can AI actually help? In practice, it’s difficult to get an AI to understand what you’re doing in the lab. Understandably so. These models don’t have an amazing grasp of the physical world, and you end up writing gigantic prompts trying to explain everything that’s going on, often with questionable results.
An alternative I’ve found much more useful is describing my lab as code.
This serves two purposes. First, it gives the AI an unambiguous definition of the pieces of my lab. Second, it defines an action space for what it can actually do with them, digitally. It sounds strange, but the idea isn’t new. People who build lab robots have needed a programmatic representation of their equipment for years. It turns out that the same representation is very useful for our new digital collaborators like Claude Code, Codex or others.
So I defined a 96-well plate as a Python object, with all the attributes and functions that matter: each well named and enumerated, the 8×12 geometry fixed, volume constrained between 0 and 200 µL, with functions like add_reagent or lookup_well giving programmatic access to the plate.
Next to that, I wrote a paragraph or two of documentation about the assay itself; say, qPCR or a binding assay, the protocol and what the assay needs and consumes. I saved both files (the script and the documentation) and pointed my coding agent, Claude Code, at them. It’s simple, but it gives a coding agent a huge boost in both understanding and, crucially, manipulating a plate in a way that’s much closer to how a human would.
Now all that’s left is to design my first experiment in English:
“I want to understand which extraction condition preserves my protein the best. I’ve already tried these two methods, and I have these three left.”
With the lab pieces and protocol in its context, out comes a proposed plate and a pipetting recipe.
“Actually, I have this fourth condition I’d like to try too.”
The plate gets edited and so does the pipetting recipe. Automatically, a second plate is generated because everything no longer fits on one. The agent can tell me exactly how much reagent and how many consumables I’ll need, and every well and microliter is accounted for. I still check the work occasionally and ultimately I’m not delegating the scientific decision of whether the experiment makes sense. I’m delegating the mechanical translation of that decision into a plate.
It was a strange feeling the first few times executing liquid allocation steps produced by an entity that wasn’t myself or a colleague. I felt like a liquid-handling robot running an experiment for Claude.
Having something like this be reliable is where the code representation framework matters. The code description of the pieces of your lab, along with their constraints, prevents the AI from making up a 97th well or adding a negative volume. This isn’t a prompt saying “NEVER ADD NEGATIVE VOLUMES.” The object itself does not allow that action to happen programmatically. The distinction between telling a model not to do something and making the action impossible is one of the things I’ve found most useful about this whole approach.
The extrapolation is that I don’t have to make pipetting decisions from scratch anymore. It’s a small thing. But I’ve found that removing this small burden has made me more motivated to jump into experiments and answer questions in the lab. I don’t know if I can go back.
Budgeting and assay cost-optimization
Combining deterministic code guardrails with the model’s highly intelligent but stochastic reasoning is powerful, and I’ve found it to be very flexible. Once an assay is specified this way, you can build on top of it.
Each reagent and consumable can be parametrized with a price, a consumption rate for a given assay, and product details, maybe the products’ website URLs as metadata. The important part is that the math behind the scenes isn’t handled in the model’s head. Scripts calculate reagent usage, volumes, and costs. Claude orchestrates them.
Now the agent has enough context and enough tools to actually be useful for lab inventory and budgeting. I can design an experiment as in the previous section and ask what it will cost. Or I can plan a month-long campaign across several setups and get the designs, usage, and budget breakdown back in a couple of minutes.
Then I tried something more ambitious:
“Can you optimize my assay to be cheaper?”
With a clear understanding of my assay, consumables, and lab, it went online, searched through countless webpages for alternate products, combined that with its own knowledge, and ran the calculations using the code I’d already built for the assay. In about fifteen minutes, it handed me a graph showing per-assay cost dropping by more than half, with explanations of the trade-offs and risks of each change. I spent much more time verifying the suggestions than the agent spent generating them. There were zero mistakes in the math or the product recommendations. I bought some of the suggestions, and they indeed worked in the lab. Now I had a >50% cheaper assay per run with what felt like very little effort. Woah. This was earlier this year with Opus 4.5; we’re now at Opus 5! (Again none of this is specific to Anthropic models, I also repeated parts of the exercise with Gemini’s coding models and got similar results.)
Overall, the model finding some cheaper reagent alternatives was a great outcome but this isn’t necessarily the generalizable lesson. It was that once the assay had been represented computationally, the agent could reason across the scientific protocol, the assay inventory, the economics, and identify the relevant product alternatives without me having to manually translate between all of those worlds. This was the kind of work I would normally postpone indefinitely. It’s impactful work, not necessarily difficult, exactly, but it’s tedious. There was always something more urgent to do.
The model did the reasoning and orchestration. The code did the bookkeeping. That clear division of labor feels increasingly important to me.
Chaining things together: lab work and presentations
What’s interesting about these workflows is that they start benefiting from context that I wouldn’t necessarily have called “technical” in the scientific sense.
Quick story here.
Startups have a habit of dropping you into do-or-die situations, often randomly. At our company, we had to scale up to run a pilot with dozens of patient samples, something we’d never done before, with only a few days of turnaround time. Suddenly budget, inventory, reagent preparation, and instrument prep all became urgent at once. Since Claude already had a programmatic and semantic understanding of our lab and our costs, I gave it a try:
“We have to scale up to X samples. I need to know the budget and how much this will consume reagent- and consumable-wise. I’m also fairly sure I have 100 µL of primer for Y, but I’m not sure how many kits of reagent Z we have left in the fridge.”
Off the agent went.
Three minutes later, a wall of text appeared in my terminal. It made a lot of sense, and it came with immediate purchasing and preparation next steps that were forgiving of exactly how little I knew about our own lab fridge.
At this point, though, something else became apparent: the output format matters too. Text isn’t the highest-bandwidth way to present data, and in my experience these models aren’t yet that good at PowerPoint. On the other hand, HTML is a much more expressive language and one that these models speak fluently1. I pointed Claude Code at our company’s branding guidelines (colors, fonts, design philosophy and all) and told it to use that framework to make a slide deck summarizing our budget and plan for tackling the pilot.
The result was a five-page deck with tables, take-home messages, a budget for the work, and warnings about what to order immediately after checking the fridge to confirm the amount of reagent Z. It was shockingly faster for me to digest than the raw text, and much easier to send to my cofounder and others.
I think presentation skill, clarity of thought, and communication are scientific skills. The underlying question of how information should be visualized still deserves real thought, because visualization carries a huge amount of the message and affects how information is interpreted. Clicking around PowerPoint’s toolbar, though, is not a scientific skill. Once I’d decided exactly what information I needed, the model already had the lab context. I could delegate the execution of turning that information into a useful artifact.
It did a better job than I could and in fifteen minutes instead of an entire half day.
Compounding tacit knowledge and machine diligence
An unexpected benefit of using coding agents in this way only became apparent after multiple uses, as data accumulated and the system became increasingly legible to the agent. It started to capture tacit knowledge.
This wasn’t something I’d designed the system to do initially. It happened because the agent was repeatedly involved in the same workflows, and I kept course-correcting, and taking notes, when something went wrong. The tireless diligence of these machines started surfacing nuances in lab-work that surprised me.
I’d given the agent a deterministic script that calculates qPCR melt-curve shape as a typical quality-check check for routinely collected data. It’s something bio-researchers, me included, don’t always do religiously unless something seems off. I mostly trust that the run went fine and move on.
Claude doesn’t cut corners like that. Running through the analysis one day, it flagged inconsistent data in a couple of wells. Melt curves take a characteristically different shape between different DNA/RNA targets, and a curve that doesn’t match historical data can be a useful heuristic that something went wrong; mis-pipetting, contamination, or something else.
It turned out to be a well I’d double-pipetted by mistake, which I had almost forgotten but the agent caught independently. By comparing the experiment I had designed previously with Claude against the historical data, it noticed the discrepancy. Lo and behold I had written that by hand in my notebook but forgot about it. I ended up recording the mis-pipetting incident in the relevant dataset, in case it became relevant in the future for the lab (or for the agent!).
Similarly, one day I noticed the agent had me loading samples into the wells along the outer edge of the plate for a run that was going to sit in the instrument for a long time. On that plate type, edge wells evaporate over long runs. It’s a known quirk of the format, not a law of physics. It’s the kind of thing you learn once, the hard way, after a run fails and you spend an afternoon figuring out why. I said as much, in plain English, the way I’d say it to a lab-mate. It redesigned the layout around the constraint without me specifying a single coordinate. Again, the edge case was captured for future use.
Here, the system starts feeling qualitatively different from a collection of AI productivity tricks. Both times, something real happened in the lab. I corrected the system, and that correction became part of the shared computational description of the experiment. Normally, that kind of knowledge lives in one person’s head, earned, after enough things go wrong. Here, all it took was updating the document the agent always looks at and pushing it to the team’s shared drive. The next time anyone on the team runs a similar assay, if they use Claude Code, it can flag the same anomaly automatically, including for people who’ve never made that particular mistake themselves and wouldn’t necessarily know to look for it. The workflow becomes:
mistake → observation → correction → encoded constraint →sync finding and enable future prevention.
Of course this sort of thing compounds over time, perhaps after enough iterations it converges to some sort of “taste”. But ultimately I think this tacit-knowledge accumulation is what we’ve always called “expertise”, which is different from raw intelligence. That feels like a very different kind of productivity gain. Beyond the fact that the machine works faster; the knowledge generated by doing the work doesn’t disappear when the work is finished, it’s shared to the whole team. There’s something very “hive-mind” about that. Pretty cool.
What exactly am I delegating?
I’ve tried to be opinionated about where I delegate my thinking to AI. As experimentalists, tedious, non-stimulating cognitive tasks get handed over to junior labmates, and perhaps sometimes we hold onto them out of habit and partly, out of a quiet pride in having gotten really good at something over years of practice.
I now ask myself a question when I work in the lab: “Is this actually a scientific skill I need to personally exercise, or is it simply a piece of operational complexity that happens to have historically landed on lab scientists?”
I’ve tried to reclaim ownership of the things I consider important scientific skills: asking clear questions, understanding results, making scientific judgments, and communicating what we’ve learned. I’m increasingly happy to let go of the rest. The lines are obviously blurry. Someone else might draw them differently. Maybe some of the things I think are “just execution” are skills that another scientist quite reasonably wants to own. That’s fine.
As people adopt AI, they’ll develop their own unique preferences and setups, all the better. A lot of this also has to do with building an instinct for what LLMs and coding agents are good and bad at, which you can only really develop by working with them yourself. So ultimately, I don’t think the future is going to be “AI does the science.” It’s going to be a marriage between the style of the scientist, the limitations and capabilities of the machine, and a computational representation of the laboratory that lets the two interact. And I suspect different scientists will draw that boundary in very different places.
Conclusion
So what? I’m aware this can read as small. Somewhere there’s a scientist optimizing a protocol that might matter to a cure for cancer, and here I am writing about well-plates, negative data, inventory, and slide decks.
But I don’t think the size of the problem should be an excuse not to think about improving the day-to-day life of wet-lab scientists. Drudgery is, quietly, one of the reasons talented people leave the bench for a desk. They didn’t stop caring about science. The friction around it just wore them down. Every hour that comes back from liquid allocation, inventory, remembering to avoid mistakes others have made, or making a slide more legible for a finding to land isn’t a minor footnote to the science. It’s freeing up capacity for more science.
And motivation isn’t a soft metric when it’s the thing standing between a scientist and their next good question. Every layer of drudgery I’ve managed to hand off has made me want to stay at the bench longer. If that keeps being true as the abstraction climbs higher, I’m genuinely optimistic about where this new way of doing science is headed.
A lot of people still don’t seem to grasp that you need to use both together. You can’t just hand everything over to AI, some things still have to be explicitly programmed.
I really like this - I’m thinking about how useful that Claude session would be for a new lab member to catch up on the work being done. To craft exact protocols that can be learned quickly. I have also found that a lot of where is a good place to start questions can be answered by a web search from Claude and then going from there. Thanks for the piece!