No-Code vs Code Interface Discussion

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.

1 Like

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. :sob:

1 Like