Accelerating Robotics at Software Speed
The slow and fast domains of physical hardware
Dear SoTA,
Why do we see rapid, predictable development in some domains, while progress stalls in others?
My favourite explanation to this question has been from Ray Kurzweil. The American author and scientist has a two-pronged explanation for the pace of a field. The first is the medium. Speed is fastest in the information layer (specifically digital), since producing, transmitting and modifying it are all quick and copying it is essentially free and instant. The more of your domain you can get into the information layer, the faster it can move. The second prong is the feedback loop. In some domains the outputs can be used as inputs to create the next generation. In computing, more powerful chips feed into chip design software, which helps produce the next generation of chips. This creates a feedback loop which results in measurable effects like Moore’s law. While most fields nowadays have a lot in the information layer, especially in planning and design, they lack the feedback loop. An aircraft made by Airbus cannot be used as an input to create the next generation of airplanes.
Kurzweil’s explanation rings ever more true for today’s AI industry, which shows the same pattern as chips but more profoundly. LLMs and coding agents exist within the information layer, so they start with its baseline speed. But the more powerful prong is the feedback loop. The output of each generation of AI goes straight into the inputs for the next. Better code builds the training infrastructure for the next round of models, and shrinks the gap between a researcher having an idea, implementing it, and getting evaluation data back from experiments. The output is increasingly doing the work of building the next generation. That makes it the purest form of what Kurzweil was getting at. It may be the quintessential exponential technology. Anthropic’s recent note on recursive self-improvement, When AI builds itself, backs this up quantitatively. By mid-2026 more than 80% of the code they merged was written by Claude, up from low single digits before Claude Code shipped in early 2025, and a typical engineer was merging around 8 times as much code per day as in 2024, directing and reviewing rather than typing it. The feedback loop is turning at a dizzying pace.
As all this goes on, those of us in robotics, happy to let the agents write our code, are dutifully collecting yet another hour of teleoperation data while the 3D printer whirs out a camera mount and the replacement for a burned-out motor sits 2 weeks away, once stock is refilled.
As Physical AI researchers, we think a lot about how to speed up the development of capabilities in robotics. How can we tighten the iteration cycles and move closer to the speed of information?
Limiting Factors in Robotics
The way to answer that is to look at robotics research and development, activity by activity, and ask which parts are stuck in the slow domain and which already live in the fast one.
Hardware design. Mostly slow and physical, but it’s starting to get pulled into the information layer. Rather than generating 3D meshes directly, agentic coding tools design parts as code. If you’ve ever asked Claude to draw an icon or a logo with SVG, you’ve seen a simplified version of the same process. This piggybacks off of how good LLMs have gotten at writing code. Generative design, going straight from a text prompt or a sketch to a finished part, is more speculative.
Hardware setup and maintenance. Getting robots running and keeping them that way. Firmly in the slow domain and will stay there. People underrate how hard this is. A robot has hundreds of moving parts, every one research grade, not production grade. Each one fails rarely on its own, but the setup runs only when all of them are working at the same time, and any single failure takes the whole thing down. The more parts you add, the shorter those windows of everything-working-at-once get, so failures arrive far more often than the lifetime of any one part would suggest. A flaky motor, a loose connector, a firmware quirk and your system is down with you frantically debugging.
Model training. Lives in the information layer, but gated by access to data, compute, and know-how, so it stays concentrated in a few top labs.
Data collection. Slow domain. Teleoperation happens in real time, one trajectory at a time, gated by physical robots and human operators. Simulation and World Models could move this into the fast domain and serious teams are betting on both. It’s a different bet from teleop, with its own requirements: a lot of capital, strong researchers and an answer to whether sim data transfers to the real robot, since contact dynamics and deformables are what simulators tend to get wrong as of now.
RL on top of trained models. Slow domain, and about to be the binding constraint. Once the models are good enough, the next gains come from RL rather than more pretraining, but RL needs a fleet of robots generating experience in the real world.
Most researchers and builders won’t design hardware or pretrain foundation models. They’ll work downstream of both, which leaves code, evals and RL as their core loop. This loop is slow because every iteration still has to be validated on physical hardware that’s painful to set up and keep alive.
Robotics doesn’t get the feedback loop and it’s worth being honest about why. A better robot model, or a better robot, isn’t an input to developing the next generation. A robot model drives motors and the robot moves objects around, neither one designs nor trains its successor. It’s the same issue as the Airbus example earlier. The one small exception is data: the experience a fleet collects can train the next model. But gathering it is gated by real-time physical work, so even that exists in the slow domain. The prong we can actually aim for is raw speed and that alone would be a big unlock.
This is where we’re hoping to contribute.
We’re building a fleet of robots you can deploy to with a few lines of code. The fleet can run CI/CD tests on real bots, rank model checkpoints through evals, act as RL actors generating experience, collect suboptimal experience data for pre-training etc.
Today, getting any of this done means setting up your own hardware and keeping it alive, which is a slog and takes time away from the meat of the work. The gap between a new checkpoint and a result on real bots is days or weeks, because someone has to physically run it and reset the scene after every attempt. We want to make it hours. We run the hardware and deal with the failures, so your team can spend its time deciding what to test, what to collect and which checkpoints to trust.
No single lab will build this for the whole field. They’d build it for their own hardware and tasks. The value is in doing it across embodiments and setups, so the diversity of hardware becomes an asset rather than everyone’s private maintenance burden, and the whole field can iterate closer to software speed.
We’re building this now and hiring engineers. Reach out if you’re interested and watch this space for updates.
Yours,
Praveen & Ville
Praveen Selvaraj is co-founder of Safe Robotics and previously researched synthetic data generation at the Alan Turing Institute.
Ville Kuosmanen is co-founder and CEO of Safe Robotics, previously a technical lead at Elwood, one of London’s best-funded fintech startups.
Emails: praveen@saferobotics.co, ville@saferobotics.co