Three numbers, before anything else.
- The robotics industry raised over 2.86B in 2022 to $8.76B in 2025.
- China alone has more than 140 humanoid manufacturers shipping over 330 products.
- Combined valuation of new waves of US robotics companies comfortably exceeds $100+ billion.
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 its 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 .
This is the gap I want to talk about.
Not because I want to “pop the bubble” — that phrase has become its own marketing genre. I want to talk about it because at Dyna we’ve spent the last year putting robots into real customer environments, and what we’ve seen has changed how we think about the entire stack. I’m writing this 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 between current capability and meaningful commercial value 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, and it reaches every connected human on Earth in milliseconds. Pre-internet, no business in history had that. LLM growth has been an internet-shaped curve.
Robots are physical, so they look more like autonomous driving — but they’re harder. Cars are useful even without autonomy. A non-autonomous car is still a thing people buy, drive, and replace. 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 + reliable channel, not on any one piece.
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 at all today. There is no installed base to upgrade. There is no “iPhone moment” infrastructure waiting for the right software.
The implication: robotics will not have an LLM-shaped takeoff curve. It will not even have an AV-shaped takeoff curve. It will have a robotics-shaped curve, and we don’t yet fully know what that looks like — but 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.
This is the most expensive misconception in the field: getting hardware out the door is not the same as building a channel.
The car analogy fails here, and a lot of robotics strategy depends on missing that.
The mistake is intuitive. Cars work as a channel because cars are useful. So if I get my robot into the customer’s facility, the thinking goes, the channel takes care of itself.
But this only holds when the underlying product creates enough recurring value that the user keeps coming back. If a robot enters a facility, performs a flashy demo, and then sits idle three weeks later because it cannot meet the actual ROI bar, you do not have a channel. You have a deployment that decayed.
A real channel in robotics is not a sales motion. It is an entire deployment system: scene assessment, task boundary definition, data capture and feedback, on-site debugging, remote diagnostics, continuous updates, reliability maintenance, and the engineering tooling that turns each deployment into a reusable artifact for the next one. Without this stack, the flywheel does not 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. Hardware can sell without becoming a high-frequency, high-stability, growing distribution layer. If the device gets touched once a month or once a year, it isn’t a channel — it’s inventory.
2. Model ≠ foundation model ≠ pre-training-only.
The second misconception is more technical.
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 is not the whole game, even in LLMs. The reason today’s LLM’s coding capability has got so much better is not ONLY that pre-training got bigger. It is that the loop between pre-training and post-training is being run aggressively, on domain-specific data, with task-specific evaluation.
The performance frontier moves from “scale + data” to “scale + data + iterated post-training feedback”.
Robotics has barely begun this loop. Most teams are still optimizing 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 vs what ships value on a customer’s floor can only be closed by teams that have 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 of those are unified across today’s training datasets in any rigorous way.
Scaling matters. However, 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 paths, three bets
Faced with the gap above, the field has split into roughly three camps.
Model-first. Build the foundation model. Hardware will be commoditized; channel will sort itself out. Bet: the model is the hardest part and creates the most defensible value.
Hardware-first. Get the body right, and models will commoditize the way open-source software always does. Bet: hardware is the constraint, and once you have a great body, software will catch up.
Integration. Build all of it — model, hardware, deployment, channel — and control the loop end-to-end until the industry matures enough for clean specialization. Bet: in robotics today, no single layer is mature enough to specialize around.
I’d argue the model-first and hardware-first paths rest on assumptions that haven’t been validated — and the assumptions hide some structural traps.
Each road is internally coherent. In a more mature field, the model-first or hardware-first paths might be the right answer. But the metrics at every layer of robotics today 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 did not arrive at that position because vertical integration is fashionable. We arrived at it 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 at one customer. 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 Dyna-specific.It’s the central problem in robotics today, and it’s 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, and we admire the teams doing them.
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.
— York