No thanks.
Restriction of liquid classes or profile or whatever the heck companies want to call them is an automatic no from me.
For example, I work with a modestly sized biotech company of ~60 employees & ~20 scientists. From this 60, we have 30 homies who know how to code and 10 FTEs who write software all day.
We can take over almost all aspects of the software stack, and this actually helps us develop our internal infrastructure & iterate faster on our science.
There is 0 chance a hardware company like Tecan could predict the things weād like to do for our specific assay. Biology is complex and software is pliable. Let us work on the software & biology in concert, ourselves.
For a moment, letās imagine an alternative future:
if instead of writing software for scientists, Hamilton focused ONLY on eliminating their own internal inefficiencies and were able to drive the price of a new STAR to no more than $20k. What would this enable?
Every hospital in the US already has an automated blood testing system. Blood tests, even IVD-certified testing, is super basic & could be done by a startup outside of a hospital.
Access to healthcare services is largely limited by cost, and hardware vendor inefficacy is the last bastion of hope to fix this issue. Where else are you gonna pull cost from in the system?
The reason biotech is so expensive is largely because we need to purchase these ridiculously non-turnkey machines for so much money. Just donāt try to make a turnkey solution - they donāt exist!
I think weād appreciate cost reductions far more than half-baked projects like the ML prep touchscreen, the Tecan Veya, and InstictV. I think the market has proven these low-code customers are simply not serious enough about their business and their liquid handling to convert into high-$$$ customers through gains using automated systems.
2 Likes
Just want to add that biotech has so many cost inefficiencies, many of them systemic. Everyone obv tries to skim off the top. Thatās just business period. Itās just unfortunate that itās business as usual with peopleās lives.
For example, one lab bench alone can be as much as $15k per month. The costs of plastics and reagents are crazy. The competition and cost of all labor is intense, from research to QA.
ALL OF THAT TO SAY, I think when people turn to automation they think of it as a cost cutting measure. Theyāre happy to spend $400,000 if it saves them $10 million over the next 5-10 years in headcount and lab space. As a result I do wish lab automation engineers were better compensated. Iāve met folks making pennies relative to the savings and their talent. We have to straddle many worlds and wear many hats. Most of us learn on the job or in our spare time.
One thing Iād love to see more of is a collective pride in our work but also a pay scale that actually reflects it.
For sure - definitely on my radar. Still a fairly new offering so itāll be interesting to see how / if it takes off and what sort of hurdles it may hit. Great first steps IMO.
Thereās gotta be overrides (e.g. āadvancedā mode) for tinkerers and optimizers though. Formulatrix has been good about exposing various parameters for tweaking in my experience.
Ctrl+z?
4 Likes
It ultimately comes down to software limitations. GUI-based interfaces typically require more resources to implement comprehensive functionality. If the software included all the features that an automation engineer or scientist might needālike version control, an undo function, and full control over robotic movementsāI believe we would be satisfied with it.
However, many companies that focus on developing GUI interfaces tend to prioritize speed over completeness, often leaving out essential functionalities. This lack of a fully developed software solution is why many of us prefer code-based approaches.
1 Like
Wow, this topic exploded. Yes, I agree with GUI interfaces prioritising speed, and ease of use over the full control of everything and everything. I think that depends on a use-by-use basis. If you want to run simple sample prep, sample dilutions, and normalisation experiments but donāt want to learn Venus then I see the use of a no-code solution, the alternatives are to hire an automation engineer or run it manually.
I feel like there is space for low-cost automation. If I was to start a company, with automation and digitisation in mind, then thereās a lot of software I need before I even have anything. ELNs, LIMs, automation, lab space, headcountā¦the list goes on.
If I can save $100k and put that into different software it will help a lot, instead of buying something that is $200k+ and having no one run it, or hiring an automation engineer on pennies as @luisvillaautomata says. Most likely the automation engineer would be here to learn on the job, build up his experience then leave. That leaves me back to the beginning. 
1 Like
Would like to revive this thread now that Hamilton has an API for the ML_Prep, a low code solution that pivoted 180 degrees to having a fully programable API.
I think this shows how a low code interfaces isnāt always the best. Especially now with AI; I can feed the API JSON and ask Claude to make me a normalization protocol. Yes, it might not 1 shot it, but to be fair these are small scripts compared to what others are doing with LLMās (with 1M token context windows most of our scripts probably use .1-1% of that). I think itād probably work right away (donāt have a ML_Prep to test with).
I see a future where low code interfaces are gone due to LLMāsā¦ I think all companies should be focusing on making their robots to integrate with LLMās by using APIās (or pylabrobot 
). The company that endorses a fully standardized language that actually works with LLMās and Git will easily take over the entire market, just my two cents. Everyone has had similar hardware for a decade nowā¦ the market leader will be ease of use to code. This would allow anyone to program a protocol, what they wanted with GUI interfaces to begin with. Yes you will still need an engineer to validate and tweak for liquid classes, niche assays, and labware but you can 1 shot 90% of the code.
4 Likes
Claude is just a low code interface.
4 Likes
we built a lab during the last 3 years fully embracing pylabrobot, git, and llms
llms + pylabrobot enabled some magical things. our scientists describe protocols in english language and with enough prompting and physical testing, arrive at working jupyter notebook wetlab methods
there exists 1 trillion-dollar AI lab working on llms + lab automation. few will know the benefits until official products launch
7 Likes