# Robotics companies are building hardware faster than they can debug

Dara Miao · 2026-08-18 · Updated 2026-08-27

Everyone is building in hardware: humanoid robots, bird-like drones, autonomous driving.

Yet we cannot debug these systems as fast as we debug software, so we cannot iterate as fast. 

In software you ship, something breaks, you patch it. But once a robot is deployed, there is no retry like that. 

Founders are getting machines onto production floors before they know how to fix them once they are operationalized.

So a new category of robotics debugging emerges. The question I keep coming back to: will the best robotics companies actually buy this, or will they just build it in-house?

## Why robots cannot iterate as fast as software

In software, you ship, users hit the edge cases, you can just patch. A bad answer is a retry away so you can simply iterate in a day.

A robot does not get a retry. If it drops a part, someone has to walk over. And if it does that a few hundred times a shift, you don't have a product but a machine that needs constant human oversight. A 95% success rate can look fine in a video but say 10k picks in a day and that's 500 times a person has to step in.

And that is one station. Across a line it compounds. A [recent working paper](https://arxiv.org/pdf/2603.04457) on embodied capability thresholds runs the arithmetic: for a 50-station line, per-station reliability of 99% produces a clean full cycle only about 60% of the time, 99.9% gets you to 95%, and 99.99% to 99.5%. The authors put it in staffing terms. At 99% you need near-continuous human monitoring, at 99.9% intermittent supervision, and only at 99.99% do failures get rare enough to handle remotely instead of with someone standing there. They are upfront that these thresholds are estimates, but the shape is what matters. The distance between a demo number and a deployable one is two decimal places, and each one costs years.

Waymo is a recent example I have been thinking of since Startup School. Waymo's co-CEO, [Dmitri Dolgov](https://www.ycrootaccess.com/p/dmitri-dolgov-seven-lessons-from), said their first working autonomous demo took 18 months. But turning that into a reliable commercial service took 15 years. A working demo, he said, is 1% of the work at best.

And we already see this happening in robotics. Figure ran humanoids for eleven months inside [BMW's Spartanburg plant](https://www.press.bmwgroup.com/global/article/detail/T0458778EN/bmw-group-advances-the-use-of-physical-ai-in-production-with-figure-03-project-in-spartanburg?language=en), and BMW has since put the next generation on live logistics work at the same site. Agility's Digit has [moved more than 100,000 totes](https://www.agilityrobotics.com/content/digit-moves-over-100k-totes) in commercial operation at a GXO warehouse in Georgia. Tesla is making Optimus for its own factories. Hardware is starting to leave the lab.

Look at [what Figure chose to publish from BMW](https://www.figure.ai/news/production-at-bmw). Eleven months. More than 90,000 parts. 1,250 hours. 30,000 X3s. Those numbers tell you the robot was on the line. They also defined three KPIs for the cell: cycle time at 84 seconds with a 37 second load, placement accuracy above 99% per shift, and interventions, meaning the number of times a human has to pause or reset the robot, with a goal of zero per shift. Then they shipped the cycle time and the accuracy and not the intervention count.

I don't think that's concealment. It's a marketing post, and BMW obviously knows the number. What interests me is that Figure named the right metric. The industry knows interventions are what separates a robot on a line from a robot you can leave alone. It just has no reason to say them out loud.

Cars solved this differently, and the contrast is instructive. California requires every company testing autonomous vehicles on public roads to file an [annual disengagement report](https://www.dmv.ca.gov/portal/news-and-media/news-releases/autonomous-vehicle-permit-holders-report-a-record-9-million-test-miles-in-california-in-12-months/). The reports carry the total number of disengagements, the circumstances and testing conditions, the location, and the miles driven autonomously for each permit holder, and a disengagement counts when the technology fails or when a safety driver has to take immediate control. So Waymo's intervention rate is public and traceable year over year: [13,219 miles per disengagement in 2019, 29,944 the year after](https://thelastdriverlicenseholder.com/2021/02/09/2020-disengagement-reports-from-california/).

That regime exists because cars operate in public space. A humanoid inside a private plant does not, so no equivalent will show up. Which means the asymmetry in the Figure post isn't a lapse. It's the permanent condition of this market. Nobody outside the building will ever be able to check anyone's deployment claim.

Even the mandated version leaks. Each company defines a disengagement for itself, and driverless miles produce none by definition since there is no safety driver, with remote assistance uncounted. The companies filing the reports openly question what the data is worth. If an intervention metric gets argued over when it's legally required, that says something about how much weight to put on a voluntary one.

## A recorded robot run is not enough to operationalize it

There is software for recording what a robot did, replaying the run, and sharing it with the rest of the team. Dexterity used to maintain that stack themselves. They [switched to Foxglove](https://foxglove.dev/customers/dexterity) and now discover issues in under a day, triage them in under ten minutes, and deploy a fix the same day. So people will indeed pay to watch a failure. But it isn't the same as being able to iterate off it.

Dolgov splits the difference into open loop and closed loop. Open loop is: here is a situation, what would you have done, then you score the answer. Closed loop is: the agent takes an action, the world moves, the sensors update, it has to act again. A log is mostly the first one. You can scrub a recording and argue about a frame. You cannot, from that recording alone, answer what would have happened if the robot had grabbed two inches to the left, because that world never existed.

The label on the recording is thin too. The standard signal on a rollout is sparse: one binary success or failure at the end of the episode. [Approaches built that way](https://arxiv.org/html/2607.13033) give limited credit assignment for the intermediate actions, and sparse binary indicators are easy to specify but yield weak learning signal on long-horizon manipulation, which is why dense rewards or a value function are what actually enable credit assignment. Put concretely: if the robot approached cleanly, grasped well, and then placed badly, one label at the end cannot tell you which part to fix. The video shows you everything and tells you nothing. Constructing the signal that does tell you is [its own research problem](https://arxiv.org/html/2604.03037v1), not a feature you turn on in a viewer.

Operationalizing is the second loop. You need a way to keep putting the robot back into the situation, including situations it has not hit yet, and a way to score whether the new attempt was better. Waymo's version is that you do not build one model. You build three: the agent that acts, a simulator that is the virtual playground it learns in, and a critic that rigorously judges its performance and tells it how to improve. At Waymo all three run on the same foundation world model.

The simulator here is important because you cannot wait for every failure to happen in traffic. The model is table stakes, in his phrasing, and eval and metrics are the strategic moat.

## Will the best robotics companies buy debugging, or build it in-house?

We are then faced with the classic buy or build question. It comes down to how you define debugging.

If debugging means logs and replay, companies already buy it. Dexterity did. That market exists, because watching a recording is infrastructure. It isn't policy, however.

If debugging means the loop that makes the robot itself better, the best labs are treating that as the company. [Physical Intelligence's Recap](https://www.pi.website/blog/pistar06) is the clearest writeup of what that actually is. You run the current policy. You label whether the episode worked. Sometimes a person takes over and shows the correction. Then you train a value function that scores how close you were to finishing, and you use that score to train the next policy to prefer the better actions. Deploy, score, update. On the hardest tasks they tried, that loop more than doubled throughput and roughly halved failures. They ran espresso for 13 hours straight. 

Figure is doing their version in-house too. [Helix 02](https://www.figure.ai/news/f-03-at-bmw) is their pixels-to-actions VLA, and the Figure 03 sequencing writeup is a Helix writeup: parts shift, rotate, and sit partially hidden inside the containers, so no two picks are the same and the task cannot be solved with hard-coded motions. Figure also brought Helix fully in-house after ending its earlier partnership with OpenAI. Tesla is running the same play with Optimus. On the [Q2 2026 earnings call](https://www.theglobeandmail.com/investing/markets/stocks/TSLA/pressreleases/3667292/tesla-tsla-q2-2026-earnings-call-transcript/), Ashok Elluswamy said Optimus learns by observing the workers in Tesla's own factories, that a dedicated team supplies a small amount of high-quality demonstrations for post-training, and that the reinforcement learning loop kicks in when the bots attempt tasks themselves, fail sometimes, and learn from both. The factory is the customer and the training set. Lachy Groom at Physical Intelligence [will not give investors a commercialization timeline at all](https://techcrunch.com/2026/01/30/physical-intelligence-stripe-veteran-lachy-grooms-latest-bet-is-building-silicon-valleys-buzziest-robot-brains/). The team set a five to ten year roadmap of what they thought was possible and blew through it by month 18. What's hard, he says, is the hardware. It breaks, it arrives late, and safety is a constant problem.

There's a second reason to build it yourself, and it follows from the disclosure gap. If no robotics company will ever publish its intervention rate, then no buyer can compare two vendors' claims about closing the loop on evidence. You would be purchasing the most important system in your company on a demo and a pitch. Building it is not only protecting the moat. It's the only version you can actually verify.

So I don't think they will outsource the system that turns a field failure into the next model.

## Who robotics debugging companies can sell to

That still leaves a market. It's just not the one the pitch usually shows.

The companies racing to have a robot they can leave in a plant will build the agent, the scoring, and the data loop themselves. Selling them that is selling them their advantage.

And everyone else still has to get past a demo. A small robotics startup, a logistics company that is not going to hire hundreds of people to build a simulator and a critic, either buys recording and evaluation tools or they stay stuck there.

Cars showed this, though not as cleanly as the pitch suggests. Applied Intuition says it sells simulation software to [18 of the top 20 automakers](https://www.cnbc.com/2026/05/19/applied-intuition-cnbc-disruptor-50-ranking.html), naming GM, Toyota, Volkswagen, Porsche and Stellantis among them. Those are not the companies that gave up on autonomy. They bought the tooling and kept their own programs. So the line isn't recording on one side and the loop on the other. It's that pieces of the loop commoditize, the simulation environment, the logging, the eval harness, while the part that encodes how your specific policy gets better does not. You can buy the room. You cannot buy the judgment about what went wrong in it.

The recording layer is also load-bearing in a way that has nothing to do with model quality. Somebody has to produce a number that two parties trust. If robots get deployed on service contracts rather than sold outright, and that is where the economics point, then uptime and intervention counts are what the contract is written against. That's a durable business even if it never touches a policy.

I am still bullish on this. Confident that the hardware rush is real, and that it is running ahead of the ability to debug and iterate once robots are in the world. People are getting hardware out the door before they know how to fix it when it is operationalized.

I am not confident though that the best robotics companies will buy the rest from a startup. The ones that get furthest will probably build Recap-shaped loops themselves, because that is the work. Everyone else buys the commoditized pieces, the recording, the simulation, the eval harness, or they stay at a demo.

Hardware will keep getting the headlines. But we must figure out how to catch up on closing the loop after the robot leaves the lab.