Let me start with a real life scenario. A software engineer joins a robotics team. He is excited to finally write autonomy code. 3 weeks in and he realises he hasn’t written a single line of it. He’s still figuring out the environment setup. This is quite a common story which is basically the theme of everything I wanted to cover in this article. Software engineers assume the difficulty is the algorithms. But it’s actually everything else surrounding the algorithms. And that gap is where robotics quietly loses most of the time.
ROBOTICS IS HARD. But the reasons people think on why it is hard are entirely different to the reality.
Misunderstanding 1: “It’s a software problem, so software tools should work”
The instinct is ofcourse reasonable. Because you think you have Git, CI, tests, containers, so this should transfer. The reality: Your code is not running against physics not a runtime. Same input can have different outputs depending on friction, temperature, exactly where an object happened to land.
A commit captures your code perfectly but it captures nothing about the friction of the table your robot is working on.
What’s missing here isn’t a better version control tool. It’s a way to version and reproduce the environment along with the code that runs in it.
Misunderstanding 2: “Just run it in a simulator”
Simulation seema like it is the robotics equivalent of a test suite. So you try to write the logic, run it in sim and then ship.
The reality: Simulation gets treated as a testing tool but most engineers don’t actually trust it. So they fall back to real hardware anyway which basically takes away the entire point.
Your simulated robot and your real robot are 2 different robots until you prove/verify it.
Here, the fix is not another better simulator. It’s simulation built from real measurements like actual friction, actual sensor noise and actual motor response instead of approximations.
Misunderstanding 3: “We’ll write tests for it”
You have been keeping up with standard software discipline i.e unit tests, integration tests and coverage numbers. The reality: What does a passing test even mean when success is probabilistic! The test results in Robotics go like this has a 94% grasp rate. Now do you consider that a pass or a fail? Basically, there’s no standard answer to whether a change made the robot better or worse? Testing usually assumes a binary outcome when Robotics rarely gives you even one. Evaluation is the real missing discipline and we have negligible tooling for it.
Misunderstanding 4: “The AI will handle it”
Most of you think that foundation models are eating everything. So Robotics is obviously the next thing.
The reality: Better policies raise the value of verification instead of removing the need for it. The best live demos in the world right now are not coming from the smartest models, but they are coming from teams with the deepest internal testing and evaluation loops.
If you closely look at the pattern across every company actually shipping reliable demos this year, there’s one common thing - A tooling nobody else has.
Misunderstanding 5: “Iteration speed is a matter of discipline”
You are used to shipping fast and iterating constantly and moving forward, all agile. That’s an average startup advice.
The reality: When one experiment takes 20 minutes and needs physical hardware, iteration speed stops being a discipline problem. It becomes a hardware-availability problem. Fewer experiments per day means slower learning, which means slower robots. Whoever shortens that loop doesn’t just move faster — they change the output of the entire field.
Misunderstanding 6: “This is a niche”
Robotics is a small, specialized corner of tech. Not something most engineers will ever touch.
The reality: Every physical AI company today is also software company with a hardware problem. Nearly all of them are independently rebuilding the same missing infrastructure from scratch in parallel.
Well, we’ve seen this pattern happen before: - Chip design didn’t scale until design and verification tooling arrived. - Autonomous vehicles didn’t scale until simulation got industrialized. Robotics is at the exact same inflection point right now.
What do software engineers actually get right?
Give credit where it’s due because most of the instinct software engineers have here is correct and valid.
It’s right that this is fundamentally a tooling problem. It’s right that the core abstractions are missing. It’s right that it shouldn’t take three weeks just to get started.
The only mistake is assuming that someone’s already built the layer that makes it work. Well, not yet, it’s all under building and processing phase.
Conclusion
Coming back to the real life scenario in the beginning. The figuring out is just misdirected towards somethings that stay in the background but are the real problems.
All this is a symptom of missing infrastructure. And it’s the same missing layer every team in this industry is quietly rebuilding alone right now in parallel.
Robotics doesn’t need more core robotics builders. We just need the tools that let everyone else contribute too.