You Don’t Need an AI Robot Arm to Make Coffee

Computex wrapped up last week here in Taiwan, and naturally it featured a robot barista.

The coffee-making robot is a pretty predictable demo at this point: An AI-powered six-axis arm sits behind glass, picks up a cup, moves it between stations, pulls a shot, adds milk, and hands over the drink. It looks sci-fi futuristic. It is easy to understand. It is fun to watch. But every time I see one, I have the same reaction:

You probably don’t need a robot arm to make coffee.

That is not an anti-robotics point. In fact, it’s the opposite. Robotics is too potentially useful to judge mainly by whether a machine looks like a person doing a familiar job. A robot arm making coffee may be impressive, but as you know, coffee automation is not new. We have had vending machines, office coffee systems, 7Eleven store machines, and automated espresso systems for years. It’s been a long time, but I’m pretty sure the coffee machine in the math building when I was in college made a decent cup. The unattended café I used to walk by on my way to the Science Park every day is great.

Obviously coffee can be automated. The interesting question is why, exactly, the automation needs to look like a human arm.

Humanoid Automation Is a Compatibility Layer

A robot arm makes sense when the environment is already designed around human motion. If you want to use an existing espresso machine, an existing grinder, existing cups, existing buttons, existing counters, and existing cleaning functions, then a robotic arm is a reasonable solution. You can place a robot in front of human-oriented tools and teach it to operate them.

That is powerful, but it also tells us something important: The arm is not necessarily the optimal architecture for making coffee. It is a compatibility layer for a world designed around hands.

The same is true of humanoid robots more generally. Humanoid robots are exciting because the world is full of stairs, doors, handles, shelves, tools, vehicles, kitchens, hospitals, warehouses, and homes designed around, well, humans. If you want a robot that can manipulate those objects without rebuilding everything from scratch, a human-like form starts to make sense. That is a big advantage.

But it is not the same as saying the humanoid form is the best way to solve any specific automation problem at scale. 

If you were designing a coffee automation system from scratch, you probably would not begin by recreating an arm. In fact, arms and hands are pretty hard. Instead, you would use pumps, valves, fixed dispensers, cup handling, controlled cleaning cycles, sensors, and other purpose-built thingies. Basically, the same kind of architecture my college math building had decades ago, but better and up to 2020’s standards.

You would not start by asking, “How do we get a robot to do what the person does?” You would ask, “How should this process work if no person had to operate it?” Those questions lead to very different designs in most cases.

Demos Are Not Deployment Architectures

This is also why I find some of the recent humanoid robot demonstrations from China so interesting. The demos are genuinely impressive. Robots dance. Run. Box. Serve drinks. Perform kung fu routines. Show up in highly publicized events. Build nationalistic pride. China’s robotics ecosystem is clearly moving quickly, and the manufacturing base behind it (like most manufacturing bases in China) is serious.

But as you probably all know after almost four years of LLMs, a demo can prove less than it appears to prove. A humanoid robot completing a choreographed routine or a controlled race is a significant technical achievement. It says something about actuation, balance, controls, cost curves, manufacturing, and iteration speed. It does not automatically tell us that humanoid robots are the best way to run a factory, stock a warehouse, make coffee, prepare food, or care for elders at scale. Those are completely different questions.

In fact, maybe the only thing harder than making humanoid robots is marketing them. Production capacity and public demos are advancing quickly, but broad commercial demand is still constrained by cost, functionality, and the need for structured environments. That is precisely the gap between a compelling demo and a durable deployment architecture.

A demo asks, “Can a robot do the work?” But at this blog, we build scalable systems. A scalable systems designer asks, “Is this the best way to build the thing that does the work?” That second question is much less exciting on TikTok. It is also where most of the real value is.

The AI Coding Tool Analogy

A lot of AI coding tools today are, in a sense, compatibility layers, too. They operate inside the world we already built. They usually generate code in human-palatable programming languages. (Even Rust.) They automate by generating and executing weirdly intricate shell commands in bash. They push changes through our existing CI, repository, ticketing, and code review systems.

That is why they are useful, and why adoption has been able to happen so quickly: They fit into the existing software development lifecycle and do things in a human-software-developer-shaped way. That can be extremely valuable. Compatibility matters. Most organizations cannot redesign their entire software delivery process just because AI tools arrived.

But we should not confuse compatibility with the final-state endpoint.

The biggest gains from AI in software development may not come from making the AI act more and more like the much-maligned junior developer sitting at a laptop cranking out code. They may come from changing the shape of the work itself. Maybe some tasks should not result in code at all. Maybe more requirements should become executable specifications, as many people envisioned decades ago. Maybe more architecture and compliance checks should happen continuously rather than during post-facto review. Maybe the pull request is not the ideal unit of AI-assisted software work forever.

Viewed from that angle, the AI coding assistant inside the IDE looks a lot like the robot arm in front of the espresso machine: A useful bridge into an existing human-designed process.

But the long-term question leaders and visionaries need to be asking is whether the process itself should change.

The Best Automation Often Does Not Look Human

When you control the environment, the optimal machine usually does not look like a person. The ideal automated smart manufacturing factory is probably not a room full of humanoid workers standing at human workstations or driving old forklifts. It is fixtures, conveyors, sensors, tooling, robotic cells, machine vision, scheduling systems, and co-designed software.

Once the TikTok videos have played themselves out, a scalable coffee kiosk probably does not need an arm dramatically moving cups around like a barista. It needs a reliable architecture for producing high-quality, consistent drinks. A high-performing software organization may not need AI agents that perfectly imitate every habit of human developers, especially since many of those habits weren’t very good to begin with. It may need better interfaces between requirements, constraints, code, tests, deployment, and operations.

This is the difference between automating the worker and redesigning the work. 

Humanoid robots and AI agents are most compelling when the existing world cannot be redesigned, when flexibility and rapid adaptation matters more than efficiency, or when the system needs to operate across many environments built for humans. Or when you just need that demo for Computex and/or TikTok.

To be clear, that is a huge category: homes, hospitals, hotels, brownfield industrial environments, legacy software systems, existing enterprise workflows. In those places, compatibility may be the breakthrough that justifies the investment.

But when we do control the environment, we should be careful. A human-shaped robot may be the most intuitive, obvious, perhaps rather uncreative solution. That does not mean it is the best one.

The Real Question

So no, you probably do not need a six-axis AI robot arm to make good coffee. But that does not mean the arm is silly. It may be a smart short-term compatibility layer. It may be a useful robotics demo. It may be a bridge into environments designed for human hands. It may be an effective way to show customers, VCs, and the public what modern robotics can do.

The mistake is treating that as proof that human-shaped automation is the future of every task. The same caution applies to humanoid robots. It applies to AI coding assistants. It applies to enterprise AI agents. It applies to almost every automation technology that starts by imitating a person doing an existing job.

Sometimes in addition to being the greatest form of flattery, imitation is the fastest path to adoption. Sometimes it is just the first step before the workflow can be redesigned.

The more important question is not: Can the machine do what the human does? The better question is: If we were designing the system around the technology and the business requirements instead of around the old job, would it look like this at all?

At least for scalable systems, that is usually where the better answer is: Not in copying the old human workflow, but in redesigning the workflow around what the technology actually makes possible.