A robotics engineer I know has a line he uses on software people who wander into his field: "Your bug throws an exception. Mine breaks something, or someone."
He is not being dramatic. It is the single most important difference between the software I write and the software that moves things in the physical world, and almost everything strange about robotics engineering follows from it. Physical AI is having a genuine moment — humanoid platforms, warehouse automation, autonomous inspection, agricultural machinery — and a lot of software engineers are looking at it with the assumptions of someone who has only ever shipped to a server.
Here is what actually transfers, what does not, and where the field honestly stands.
The Architecture Is Familiar. The Constraints Are Not.
The loop looks like something you have built. Sense the environment, build a model of what is happening, decide what to do, act, observe the result, repeat.
If you have written an AI agent, you recognise that. Perception is your input parsing, planning is your reasoning step, actuation is your tool calls, and the feedback loop is the same shape. That similarity is real and it is why agentic AI and robotics are converging in interesting ways.
Then the constraints arrive:
The loop cannot pause to think. A balance controller runs at hundreds of hertz. Missing a deadline is not slow — it is a fall. This is why real robots have a layered architecture: a hard real-time layer for control that must never be late, and a slower deliberative layer for planning that can take its time. Language models live in the slow layer, and they always will.
You cannot undo. No rollback, no retry on a broken part, no "just restart it." Every action changes the world permanently, which puts enormous weight on the decision to act.
Sensors lie constantly. Not occasionally — as a normal condition. Noise, drift, reflections, dust on a lens, an object outside the training distribution. Software engineers assume input is what it says it is; robotics assumes every reading is a hypothesis with error bars, which is why probabilistic estimation is foundational rather than advanced.
Reality has no test environment. You can simulate, and simulation is essential, and it is never quite right. Friction, compliance, wear, lighting, the specific way a cardboard box deforms. Everything works in simulation. The gap between simulation and reality is where the field's hardest engineering lives.
What Actually Improved Recently
The progress is real, and it is worth being precise about where it came from, because "AI got better" is too vague to be useful.
Perception crossed a threshold. This is the big one. Recognising objects, estimating pose, segmenting a scene, understanding what a surface is — these used to require carefully engineered features and controlled conditions. Learned models now handle messy, varied, real environments well enough to build on. Most of the impressive demonstrations you have seen rest on this.
Language became an interface. Being able to say "pick up the red container and put it on the second shelf" and have that decomposed into a plan is a genuine change in how these systems are commanded. It moves the operator from a programmer to a supervisor.
Simulation and transfer got substantially better. Training in simulation with randomised physics and appearance, then deploying to hardware, works far better than it did five years ago. Not solved. Much better.
Hardware got cheaper. Actuators, sensors and compute have all come down enough that experimentation is accessible to more than a handful of well-funded labs.
What Has Not Been Solved
The honest counterweight, because the demonstration videos are heavily selected.
Manipulation of unfamiliar objects. Robots handle known objects in known conditions well. A novel object, an unexpected grip, a thing that is heavier or more slippery than it looks — human infants handle this better than the best current systems. Dexterity remains genuinely hard.
The long tail. A system that handles 95% of cases is not 95% finished. In a warehouse, the remaining 5% is a person walking through, a pallet at an odd angle, a label that peeled off, water on the floor. Getting from working demonstration to a machine that runs an eight-hour shift unattended is most of the total effort.
Recovering from failure. Humans recover from mistakes constantly and barely notice. Robots tend to either not notice the failure or stop entirely. Graceful degradation is an unsolved area and it is what actually determines whether a deployment succeeds.
Humanoids specifically. The form factor is compelling — the world is built for human bodies — and the progress is remarkable. But bipedal locomotion consumes an enormous amount of the engineering budget for a benefit that a wheeled base with an arm often delivers more cheaply. I would expect the commercial successes over the next few years to be mostly non-humanoid, with humanoids finding narrower niches than the funding suggests.
Safety Is Architecture, Not a Feature
This is the part software engineers most need to internalise, and it is the reason robotics teams look conservative from outside.
You cannot make a learned model safe by asking it nicely, and you cannot verify a neural network the way you verify a state machine. So the discipline is to never let the learned component be the last line of defence.
Real systems put a deterministic safety layer underneath the intelligent one: force limits enforced in hardware, speed limits when a human is detected nearby, geometric boundaries the arm physically cannot exceed, an emergency stop that cuts power without asking software for permission. The clever model proposes; the simple, verifiable layer disposes.
The parallel to AI agents is exact, and it is the transferable lesson. An agent that can spend money should not be trusted because the prompt says be careful. The authorisation check sits outside the model, in code you can read. Robotics arrived at that conclusion decades earlier because their failures were visible.
If You Are a Software Engineer Curious About This
The transferable skills are more than you would think. Distributed systems thinking maps well — a robot is nodes exchanging messages with latency and failure. Data pipelines matter enormously, because these systems generate huge volumes of sensor data that has to be collected, labelled and fed back into training. Deployment and fleet management is the same discipline as IoT: signed updates, staged rollout, version visibility across machines you cannot reach.
What you would need to add: control theory at least to the level of understanding feedback and stability, probability and state estimation, the fundamentals of coordinate frames and transforms, and enough C++ to work in the real-time layer. ROS 2 is the common middleware and worth learning early, mostly because the ecosystem assumes it.
The most useful mental adjustment is smaller than any of that, though. Stop thinking of the physical world as an environment your code runs in, and start thinking of it as the thing your code is negotiating with — one that does not read your documentation, has no API contract, and will present you with a situation nobody imagined on the day you least expect it.
That is the job. It is genuinely difficult, and it is why the demonstration videos and the deployed systems are still further apart than the headlines suggest.
