Each user has different needs.
Operators and many scientists without programming background still need a GUI to program simple tasks (e.g. serial dilution).
Software and automation engineers will prefer more granular control in python, C# or any language. And others in between will be comfortable with an old school drag n drop IDE like VENUS, Biomek or Evoware, and some minor scripting for data handling.
The AI can definitely save time writing methods these days.
But you are still dealing with the multiple variables and physics of liquid handling to fine tune the results, and the human operator still needs to feed back the AI with the observed results after every test (e.g. small droplet on the well’s wall, not fully resuspended solution, the tip touches a bit the bottom cell layer, etc.).
Like others mentioned, liquid handling vendors don´t have the luxury of accessing their install base data to train an AI, so community sharing like Github or this forum will be key to improve AI method generation in the coming years.
But the number of options on those moves and the number of ways those moves can be made is nearly infinite. It’s one thing to say you’re just going to move a liquid from here to there in the abstract. In reality you need to deal with the liquid classes, how fast will you draw up? How fast to dispense? Will you touch off? Will all the liquid end up in the well or is there any chance that a drop stays on the tip? Do you need to think about the viscosity? How will the conductivity of the liquid affect the liquid level detection? What about timing issues? Will this reaction go too far while we are waiting on the robot to set up the next step? I could go on and on.
If I want to be as reductive about your specialty then I would just say what is so hard about programming? You ask the LLM and it gives you the code. You need to know nothing. But for setting up a protocol you need to know the science behind it. It is at least as involved as doing the same protocol on the bench by hand and I don’t know many programmers that could just jump into a lab situation and do that.
There’s a lot that you don’t realize that you don’t know.
I guess I just mean to say that there is a lot more to setting up a robotics protocol than just planning the pipetting steps. Anyone who has ever done that in real life knows that. Even when you have the nice graphical interfaces making it easy to plan the pipetting steps, there is still a LOT more to developing a method for a robot than just that.
This is a topic I’m quite interested in. We’re thinking about using AI agents or related techniques to evaluate liquid classes and build a pipetting parameter database that works across most applications.
Curious if anyone here has experience with this or any tips to share.
Someone at one my hackathons built a database of sorts. It did not win but it received a special shout out and was a very interesting approach to the problem.
There are also some interesting papers that have come out recently on the subject. Quite a few camera driven solutions as well (which won’t scale.) And I’ve seen a few groups like Festo advertise products that are in this domain that look to be available to demo at SLAS.
If you’re working with Hamiltons then TADM can be very helpful, TADM curves can show you not only if an aspiration worked correctly but the specific way it failed if it did (requires some interpretation).
This is very helpful information, thank you!
We are using our own pipettes and test platform, so it may take some time to set up the testing environment, but it is definitely worth trying. I will share feedback once we have results.
We are using our own pipettes, and we plan to use the balance data as the main feedback. The pressure curve can of course be used as complementary information as well. Thank you for the suggestion.
Hey all. I’m loving the conversation here. We’ve been working on exactly this problem at Cornucopia Biosciences. The dream, of course, is to be able to feed the AI a protocol and have it do all of the methods development instantly. However,
As pointed out, there are numerous hurdles to overcome before it is reasonable to start thinking about taking the human out of the loop. Part of that involves building custom RAGs to build up the full context needed for any particular customer, or even particular device.
The way we are thinking of it at the beginning is to use the agents to dramatically accelerate the development process. This allows one engineer to do more, more quickly. An example is of course the de novo code generation. But I’m also talking with the agent as I’m doing the liquid transfer validations. “We are pinning on this plate, adjust all offsets when using the current pipette up my 2mm” and the agents runs through the entire method and makes the update.
The agents also enable non code people to make small tweaks to methods without having to bring in an engineer. Or requiring the engineer to code in a whole bunch of runtime parameters. Example: “We need to move the reaction plate over by two carriers”. “Reduce the sample input volume in half” It’s all coming together remarkably quickly.