Working up a project to get liquid handler methods in PyLabRobot generated with Claude Code. Just by referencing the PLR code base and then user specifics (machines, resources, etc), this is already pretty doable and has been with previous LLMs/agents. I’m wondering if anyone has any tips or lessons learned from stuff they have done so far, like particularly helpful CLAUDE.md instructions or Skills. This is more for the lab user side versus development.
just this “basic” setup is already super powerful for us, especially when you run claude in the directory that also contains the existing protocols / data management systems.
that said, I have worked with biomni (https://biomni.phylo.bio) to create a PLR tool in their system, which has some more specialized prompts. I haven’t really compared them side by side because the benefit of it having access to our local code outweighs the custom prompts in biomni.
Also, I was talking to Elnora which actually runs inside Claude Code and adds more scientific tools. It doesn’t yet have specialized tools for PLR, but might help with scientific understanding.
I am completely amazed by how good the claude models are. 1+ to Rick’s comment, if you run it in the PLR directory with examples, it can figure out a ton. We were trying to do this 2 years ago with ChatGPT and never got it working. Now claude can just figure it out.
I would say that pulling the docstrings for the aspirate, dispense, etc. functions into the Claude.md (or a specialized protocol_creation_instructions.md) and creating a labware_library.py file for the specific labware you use is helpful. Also, because the setup is generally static (ie carrier locations) - providing the import and setup header makes it so the generated scripts are consistent and you don’t have to spend time and tokens going over that every time.
Rick - is it possible to enable the forum’s upload feature to accept .md files?
2 Likes
done
Thanks Rick!
So I ran a little test to see if an instructions file actually helps.
I gave Claude this prompt with and without the protocol_generation.md file (and clearing the context right before each time):
use the @keyser-testing/protocol_generation.md instructions, create a protocol that does the following:0. Setup = Tecan Evo, 8x AirLiHa, MP3_Pos carrier on rail 16, 50uL SBS DiTi tipbox on carrier position 2, Eppendorf 96well 250uL Vb on position 1 as destination, Eppendorf 96well 250uL Vb on position 0 as source
-
Perform a 1:5 serial dilution in columns 1-6 of the source plate (50uL of the compound in DMSO is in column 1, 40uL of DMSO is in columns 2-6) -
Transfer 2uL of the diluted compounds into the destination plate. Create replicates in columns 1 and 7, 2 and 8 etc. The destination plate has 98uL of assay buffer already.
Write the protocol to a python file in the keyser-testing directory.
protocol_generation.md (14.8 KB)
The output is nearly the same. It uses different syntax, but does all of the steps correctly (didn’t test on the robot yet though).
With the instruction file - it took 1:18 to complete
Without the instruction file - it took 1:43, there was a lot more background searching, but it went pretty fast
I don’t know that this test proves anything other than claude is amazing. Maybe the delta would be bigger with more complex protocols and repeat use. Or maybe just giving it un-biased access to the underlying source is the best way to go.
3 Likes
Wow that is super interesting. Thanks for sharing that instructions file - my instinct is that something like this file will prevent wasting tokens/thinking on the hardcoded stuff (equipment setup w/ carriers and tips, imports). Plus there is still a lot of power in a detailed vs a generic “do a serial dilution” prompt.
I’m also thinking of some Skills that allow users to easily save/back up their new script and associate it with a given experiment or LIMS entities.