Are We Building AI to Help Humans, or AI That Needs Humans to Help It?
A discussion on why AI often struggles in human-designed interfaces, and how machine-native systems may be the real future of automation.
I watched a recent Tesla robot video where it was trying to adjust a stove flame, and it honestly looked useless. It couldn’t rotate the knob properly, accidentally turned the flame off, couldn’t turn it back on, almost fell while standing, and eventually a human had to step in and help. At that point I seriously wondered: are we building AI to help humans, or building AI that needs humans to help it?
This reminds me a lot of what happened last year with browser-based AI agents. Everyone was hyped about AI that could browse the web on a VM, move a cursor, click buttons, and “use the internet like a human.” In reality, it was slow, fragile, painful to use, and often got stuck. The AI wasn’t dumb, it was just forced to operate in a human interface using screenshots and cursor coordinates.
Then tools like OpenClaw appeared and suddenly the same models felt powerful. Not because AI magically got smarter, but because execution changed. Instead of making the model browse a browser, it was allowed to use the terminal and APIs. Same brain, completely different results.
That’s the same mistake we’re repeating with robots. A stove knob is a human interface, just like a browser UI. Forcing robots to twist knobs and visually estimate flames is the physical version of forcing AI to click buttons. We already know the better solution: machine-native interfaces. We use APIs to order food, but expect robots to cook by struggling like humans.
The future won’t be robots perfectly imitating us. Just like the internet moved from UIs to APIs for machines, the physical world will too. Smart appliances, machine control layers, and AI orchestrating systems, not fighting knobs and balance.
Right now, humanoid robots feel impressive in demos, but architecturally they’re the same mistake we already made in software.