The honest answer to the bench scientist's first question — and the three ways labs actually "program" a robot.
No — not with plain-language automation. Traditional lab automation is driven by scripting (often Python) or a drag-and-drop protocol designer; a physical-AI system lets you describe the protocol in plain English and runs it, using vision to confirm each step. You still need to understand your science — you just don't need to learn to program a robot.
| Approach | What you do | Who it suits |
|---|---|---|
| Code / API | Write scripts (e.g. Python) to control the deck | Teams with engineers or coding-comfortable scientists |
| Visual protocol designer | Drag and drop steps in a GUI | Scientists willing to learn a tool's building blocks |
| Plain language | Describe the protocol in natural language | Any scientist; no programming required |
Code gives maximum control but gates automation behind programming skill — the reason many benches never adopt it. Visual designers lower that barrier but still ask you to translate your protocol into the tool's specific blocks and quirks. Plain language removes the translation step entirely: you express intent, and the system maps it to robot actions.
The goal isn't to make scientists into programmers. It's to let them speak science, not robot.
"No code" doesn't mean "no thought." You still: state the protocol clearly (volumes, plates, steps, conditions), validate the first runs against your controls, and handle the occasional exception the system flags. What disappears is the syntax, the deck-scripting, and the debugging of a programming language.
Plain language only works if the robot can confirm it did the right thing. Onboard vision checks each step — tip pickup, plate position, liquid transfer — so a misread instruction or a mis-seated plate is caught and corrected mid-run rather than surfacing later as a failed result. That closed loop is what makes describing a protocol, instead of scripting it, trustworthy.
