What 10 Months in Production Taught Us About the Robotics "Bubble" | DYNA Robotics

What 10 Months in Production Taught Us About the Robotics "Bubble"

May 2026

By: York Yang, Co-Founder, DYNA Robotics

Three numbers, before anything else.

Total Raised

$18B raised across 235 deals
2022 – 2025

Annual funding tripled $2.86B → $8.76B

Humanoid Manufacturers

140+ in China alone
shipping over 330 products

Combined Valuation

$100B+ new-wave US robotics

Total useful work performed? A rounding error.

Total useful work performed by humanoid robots in 2025? A rounding error.

In January 2026, Elon Musk acknowledged on Tesla's earnings call that zero Optimus robots were doing useful work in Tesla's factories. Unitree's IPO prospectus, filed in March, disclosed that 73.6% of their humanoid revenue in the first nine months of 2025 came from research and education, and only ~9% was true industrial deployment. Within that 9%, most is "enterprise reception and tour-guide" work. Real industrial-manufacturing revenue from the world's largest humanoid shipper: roughly $2M.

Unitree Revenue Breakdown

First 9 months of 2025 · per IPO prospectus

Unitree Revenue Mix

Of that 9% industrial — only ~$2M is real manufacturing revenue (world's largest humanoid shipper)

Over the last year DYNA has put robots into real customer environments, and what those deployments showed has changed how the team thinks about the entire stack. This piece is for the people building, funding, and selling into this market.

What "bubble" actually means

Bubble is a loaded word. In tech, it isn't always a bad thing. The most useful definition I've found, after watching this industry up close:

A bubble is the gap between current technical capability and human expectations, multiplied by time.

If the gap closes in a year, it isn't really a bubble. If it takes a decade, then for the first five years it is — because capital has time value. A return in year one and a return in year ten aren't the same return, even at the same nominal value.

So the right question isn't "is robotics overhyped?" The right question is:

Can current robotics capability produce commercially meaningful value in a reasonable time, and is that value linearly tied to underlying technical progress?

If yes, it isn't a bubble. If no, it is.

By that measure, large parts of the current robotics market are bubbles. Not because the technology won't get there, but because the timeline is longer than current funding levels assume.

Robotics is not LLMs. Robotics is not autonomous driving.

A lot of bad robotics strategy comes from importing the wrong analogy.

LLMs scaled exponentially because they're pure software. The browser is the distribution layer, reaching every connected human on Earth in milliseconds.

Robots are physical, so they look more like autonomous driving, but they're harder. Cars are useful even without autonomy. The car was a finished distribution channel waiting for AI to plug into. Even that hasn't been enough: AV is bottlenecked on the combination of reliable model, reliable vehicle, and reliable channel.

Robots have none of that. A non-intelligent humanoid is a 60-pound machine with 28 degrees of freedom and no purpose. It has no built-in user base, no reason to be plugged in, and no distribution layer. Outside of industrial arms and Roombas, robots are barely deployed today. There is no installed base to upgrade, no "iPhone moment" infrastructure waiting for the right software.

Robotics will have a robotics-shaped curve, and the field doesn't yet know what that looks like. Importing the wrong reference class is one of the most expensive mistakes in this market.

Three things the market keeps getting wrong

1. Hardware ≠ channel.

Getting hardware out the door is not the same as building a channel. The mistake is intuitive: cars work as a channel because cars are useful, so the thinking goes that getting your robot into the customer's facility is enough. But this only holds when the product creates enough recurring value that the user keeps coming back. If a robot performs a flashy demo and sits idle three weeks later because it can't meet the ROI bar, that isn't a channel. That's a deployment that decayed.

A real channel is an entire deployment system: scene assessment, task boundary definition, data capture and feedback, on-site debugging, remote diagnostics, continuous updates, reliability maintenance, and tooling that turns each deployment into a reusable artifact for the next one. Without this stack, the flywheel doesn't spin. Each new customer is a one-off project, not a compounding asset.

The test of a channel is whether the next deployment is faster than the last one. If it is not, you have not built a channel. You have built inventory and PR.

This is what AR/VR taught us. If the device gets touched once a month, it isn't a channel. It's inventory.

2. Model ≠ foundation model ≠ pre-training-only.

Every robotics conversation in 2025 was about pre-training scale. "How many hours of data?" was often the only metric anyone tracked.

But pre-training isn't the whole game, even in LLMs. Today's LLM coding capability has improved so much not only because pre-training got bigger, but because the loop between pre-training and post-training is being run aggressively, on domain-specific data, with task-specific evaluation. The frontier has moved from "scale + data" to "scale + data + iterated post-training feedback."

Robotics has barely begun this loop. Most teams optimize pre-training as if more hours of data automatically translate to downstream capability. The post-training signal has to come from real deployments. The gap between a model that works on a benchmark and one that ships value on a customer's floor can only be closed by teams with a real production loop.

To go one layer deeper, the scaling-law conversation in robotics is more confused than the field admits. LLM scaling laws hold because pre-training and post-training share a relatively unified evaluation surface, perplexity and its descendants, that lets both phases optimize toward a common target. Robotics has nothing of the kind. Downstream tasks have explicit requirements for speed, output quality, and reliability, none unified across today's training datasets. Saying "more data" without saying "data measured how, against what target, for which downstream metric" is, at best, an act of faith.

3. Channel construction is the most underestimated lever in the stack.

By "channel," I don't mean sales pipeline. I mean the full deployment infrastructure:

This is the flywheel. Without it:

When people ask "where's the robotics bubble?", most of it lives in the gap between teams that have understood this and teams still optimizing for benchmark numbers and demo videos.

Three paths, three bets

The field has split into roughly three camps.

Each road is internally coherent. In a more mature field either of the first two might be right. But the metrics at every layer of robotics are still being defined. A model team optimizing for benchmark performance has no way to know whether its gains translate downstream. A hardware team shipping units has no way to know whether the units will be used six months later. Specialization works when the interfaces between layers are stable. The interfaces in robotics are not stable yet.

DYNA is in the integrated camp. We didn't arrive there because vertical integration is fashionable. We arrived because the deployment work made the alternative impossible.

What we learned at Dyna in the last year

Most of what I just described, we learned the hard way.

When we shipped DYNA-1 in April 2025 — a foundation model running 24+ hours autonomously at 99%+ success on tasks like napkin folding — we thought the hardest part was behind us. Strong model, real ROI on a real task. Twelve months later:

Our longest-running deployment is now around 10 months of daily usage. The system is still creating value. But getting from "sale" to "running reliably without us" took weeks-to-months of on-site engineering, and most of that work didn't transfer cleanly to the next customer.

Deployment didn't self-accelerate. It was supposed to follow the standard pattern: research and deployment teams separate, deployment becomes process-driven, each new customer faster than the last. That hasn't happened, and as far as we can tell from peers, it hasn't happened anywhere in the industry yet.

The failure isn't in deployment teams. It's that the underlying primitives (model, hardware, deployment system) aren't yet good enough to let deployment run as an independent loop. The loop has to close across research, hardware, and deployment simultaneously, or it doesn't close at all. This is not a DYNA-specific problem. It's the central problem in robotics today, largely invisible from the outside because demos hide it.

DYNA's Convictions

We have decided that model and data are a first-class research problem, not a solved input. The primitives that failed us on customer floors were not only the deployment system and the hardware — the foundation model itself had capability gaps that pre-training scale alone couldn't close. The post-training loop, fed by real deployment data and measured against task-specific metrics, is where the model actually matures. We are investing in that loop as a core research capability, not treating it as a handoff from pre-training.

We have decided that deployment-system engineering is as much a research problem as model architecture. Significant effort has gone into building the tooling that turns deployment know-how into compounding infrastructure. Without it, the data the model needs never reaches it. The loop doesn't close.

We have decided that hardware is in scope. We have hardware design, manufacturing, and production capability, closely paired with research. People didn't fly by getting smarter. They flew by inventing airplanes. Vertical integration is more capital-intensive and slower in the short term, but we believe it's the only path that closes the loop today.

The proof of all of this is repeated, durable production deployment, not demos. Whether the second deployment is faster than the first, and the tenth faster than the ninth. No one in the industry has shown that yet at scale, including us. The first team that does will define the next phase.

What I would say to the field

The bubble isn't where the noise is. It isn't dancing humanoids or marathon-running quadrupeds. Those are real engineering achievements.

The bubble is in the assumption that capability will turn into commercial value on an LLM-shaped curve. It won't. The fastest way to shorten the gap is not better demos. It is harder, more honest engineering against real customer ROI, and the patience to let the deployment flywheel compound before declaring victory.

That is the work in front of us. It is in front of everyone else, too. More to come. Stay tuned.