I’ve been a software engineer for 5 years. I am beyond impressed by Claude Opus 4.5.
Don’t take this as an insult to the complexity of method development, but the window of confusion in software engineering is vastly wider than in liquid handling.
Consider a typical software request: “Write me an endpoint that contacts this API, returns the data, stores half of it in SQL, the other half in Mongo, writes it to the filesystem, transforms that data to this shape, and returns it as JSON to an interface where the user can view it as an interactive chart.”
That’s six different technologies, multiple paradigms, and dozens of implicit decisions about architecture, error handling, and data flow.
Method writing isn’t like that. The domain is constrained. You’re moving liquid from A to B. The operations are finite: aspirate, dispense, mix, transfer, dilute. The parameters are physical: volumes, positions, speeds. The hardware defines the boundaries.
This is exactly the kind of problem AI should excel at. Well-defined inputs, predictable outputs, and a limited solution space. The complexity is in the details and edge cases, not in architectural ambiguity.
My question then is, are you all using AI to develop methods? If not, why?
Yeah it’s a perfect use-case of code assistants/ agents and really demonstrates the utility of programmatic interfaces like PyHamilton and PyLabRobot. When I interned at Hamilton I rewrote a lot of their NGS protocols in Python and the efficiency boost from using LLMs (Claude and Copilot in VSCode). I would estimate that a developer is ~100x more efficient with programmatic interfaces than GUIs due to this.
What I found astounding was that Copilot can accurately guess the next step in a protocol to the point where you can just tab complete through a good chunk of it. This is naturally not something that Venus can do.
Personally? not at all - I’ve never used it to program methods and when I was translating from existing Venus methods the hardest part by a lot was understanding what the Venus method was doing.
A lot of people say that they find the GUI easier than programming, but this is usually weighted by many years of experience using the GUI since there was no alternative. I’d be very surprised if anyone found Venus more intuitive than Python if they were starting from no experience on both.
Having a 3D GUI for making the deck layout is still useful though.
Software is entirely a human construct. We invented it, we defined the rules, and those rules are (mostly) deterministic and documented. If you understand the API specification, database schemas, and framework documentation, you can reason through the software problem.
Assay development or its tech transfer, by contrast, is fighting physics, chemistry, and biology - natural laws we didn’t invent and can’t change. Operations may feel finite but physical reality has infinite edge cases.
Something to consider; these LLMs have been trained on vast amount of public code repositories, Stack Overflow posts, etc. They are meant to be good at programming.
On the other hand, there is no public source code for complex processes as companies are not incentivized to make them public. (I don’t believe this is actually helping the industry but it’s just how it is). I do hope this changes.
An LLM might be able to write some simple A to B transfers but there is just so much more to these machines and the processes they are running. AI slop is an actual thing, and while you can get away with it in some applications, there is almost no room for error when running sensitive samples worth thousands of dollars.
There is also the issue of feedback loop, tools like cursor and Claude Code are able to run tests and correct them selves. There is no equivalent when running physical hardware, you still need human awareness to make sure everything is working properly.
I think there is a likelihood they’ll hit a wall fairly quickly, at which point it becomes more efficient to have a human with a deep understanding of the machine and lab processes write the program.
Edit:
Nevertheless, I 100% agree with Stefan, Python is much more intuitive than Venus!
For a lot of companies, the methods are considered IP. Of course they’re not sharing them.
However even if they did, many methods do not contain the context required to understand their implementation.
This is why so many groups have issues importing and running validated methods from vendors. There are a few threads about this exact problem in the forum. Also worth noting that this is a problem with manual assay execution of an instruction set as well. The quality of the implementation is also a huge issue. There’s a huge difference wrt academic assays vs industry assays.
There have been incredible platforms specifically aimed at abstracting the protocol writing process or making it interoperable but few have succeeded. There are many reasons for the aforementioned but perhaps one such reason is that writing the aspirate/dispense command in itself was not the bottleneck. It also imo signifies that understanding the abstractions alone is not enough.
With that said, abstractions are a must at the method level and implementation level. Programming is one such way to manage these abstractions and imo is also a must, especially at startup that require iteration and rapid development.
Sure, operations are finite (lab specific and config specific). Just like DNA has finite bases, chess has finite moves, and music has finite notes. But finite elements don’t make a limited solution space. They make an EXPONENTIAL one. The complexity isn’t in the vocabulary, it’s in how those elements combine, interact, and produce emergent behaviors that can’t be predicted from first principles.
DNA itself has 4 bases, finite operations and deterministic chemistry. Yet from this limited system we get all of life (in all of its diverse and rich forms) and emergent properties like human consciousness. It’s truly remarkable and so cool to just take a step back and think about imo.
This was my point.
Edit: also just curious but have you seen Verisflow (posted elsewhere in this forum)? https://www.verisflow.com/
Does the “no experience starting from both” include no programming experience as well? Now that would be an interesting experiment.
I’ve also heard folks say that knowing how to program makes understanding Venus easier because of its reliance on libraries, HSL and other similar concepts.
And so having no experience with programming can also hurt GUI adoption if it relies on similar principles as its programming counterpart
The best repo you’ll find with automated protocols aka methods is via Opentrons. If I were starting today, I’d start from this rich source. You’ll still encounter some of the issues listed above but it’s awesome to just have this available.
There are some solutions available but adoption seems inconsistent. They’re also mostly not about lab automation which is fine. There are new DSL’s springing up all of the time but again, adoption is inconsistent. And while DSL’s are great, they’re not explicitly about collaboration. They’re also not as impactful as FDA or ISO driven requirements. Digital CMC is blowing up rn and this makes me excited.
In 2025 I did start convo’s with organizational bodies in the regulatory space but I paused that work. This is a good reminder to follow up in 2026, I’ll make a note.
It’s interesting how often I see people with a programing background walk into the same pitfalls with regards to liquid handlers. I guess having a new tool that you feel you can throw at anything is only going to accelerate this.
Yes, AI will easily throw together a pipetting method. I guess nobody can stop you from reinventing Smart/Power Steps, it seems like a waste of resources, though. Throwing together a method that does your pipetting in simulation has never been a big thing, it’s the “Hello world” of lab automation.
The problems start with integrating third party devices, continue with datahandling that is tailormade for every permutation of LIMS and end (but not really) with the bother of actually having to move liquids.
By the by, that last part is also why you probably won’t see the graphic interfaces vanish for a good while. They are annoying for a programer who is used to controlling all of their code, who wants to version control it and who wants access to open source solutions. They are extremely useful for the guy that has to get a system running in the bowels of a big biotech player which wants less than zero interaction with the outside world. Oh yes, and the system was programed by someone else.
No offense taken by the implication that AI can program liquid handlers, honestly. And I see the problems with the current approaches. It’s just, the problems (as in many othe areas that currently find an influx of AI) are very often not a result of old fogeys stubbornly clinging to outdated ideas, but consequences of integral and useful concepts.
I would say integrating with third party devices and LIMS is vastly easier with programming. I don’t really see the specific advantage of GUIs there. I also don’t see the specific advantage of GUIs for the example you give of a big biotech player. What does the GUI give you in that case?
I guess the pushback I see is that AI is not going to solve the liquid-handling for you. I think what I’ve seen is that programming makes it a lot easier to solve, even if the engineer is still the one using their judgement to make decisions. For instance it takes me no time at all to write a quick optimization test script that allows me to iterate over different liquid class parameters and see which ones cause bubbles and so on. These small test scripts are the backbone of how I develop more complex methods, and being able to spin them up quickly is a really big advantage.
