Three numbers, before anything else.
[ Insights ]
What 10 Months in Production Taught Us About the Robotics “Bubble”
Category:
Insights
Author:
York Yang
Date:
May 2026
[ Overview ]
[ Total Raised ]
$0B
raised across 235 deals, 2022 – 2025
Annual funding tripled $2.86B → $8.76B
[ Humanoid Makers ]
0+
humanoid manufacturers in China
Shipping over 330 products
[ Combined Valuation ]
$0B+
new-wave US robotics companies
Real industrial revenue: ~$2M
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.
Unitree revenue mix
First 9 months of 2025 · per IPO prospectus
Research & education73.6%
Other17.4%
Industrial deployment9%
~$0M
Real manufacturing revenue — from the world's largest humanoid shipper. Just 9% of humanoid revenue is true industrial deployment; most is reception & tour-guide work.
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.
[ The Bubble ]
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.
[ Analogies ]
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.
[ Mistakes ]
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.
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. 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:
Scenario evaluation and task-boundary definition
On-site setup and debugging
Data collection and routing back to training
Remote diagnostics and reliability monitoring
Continuous model and system updates
Turning each deployment into reusable engineering tooling for the next one
This is the flywheel. Without it:
The robot doesn't enter real environments.
The model doesn't get real post-training signal.
The pre-train ↔ post-train loop doesn't close.
The capability curve flattens, regardless of pre-training compute.
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 Bets ]
Three paths, three bets
The field has split into roughly three camps.
Model-first. Build the foundation model. Hardware will be commoditized; channel will sort itself out.
Hardware-first. Get the body right, and models will commoditize the way open-source software always does.
Integration. Build all of it — model, hardware, deployment, channel — and control the loop end-to-end until the industry matures enough for clean specialization.
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.
[ Learnings ]
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:
The longest-running deployment is now ~10 months of daily use. 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.
[ Convictions ]
DYNA's convictions
Model and data are a first-class research problem, not a solved input. The primitives that failed us on customer floors weren't 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're investing in that loop as a core research capability.
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.
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 slower in the short term, but we believe it's the only path that closes the loop today.
The proof 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.
[ To The Field ]
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.
[ Stay Updated ]
Our research straight to your inbox.
