For most of the software era, a mistake in code cost time, money, or data. A screen froze, a payment bounced, a file corrupted, and we recovered by rebooting, refunding, or restoring from a backup. Failure was a nuisance, and nuisances can be undone.
That forgiving arrangement is ending. As computation moves off the screen and into cars, surgical tools, factory floors, and the power grid, the same class of fault that once produced an error message now produces motion, force, and heat. The defining change of the coming decade is not that machines are getting smarter, it is that their mistakes are becoming physical, and physical mistakes are far harder to take back.
The Day Software Stopped Staying on the Screen
Consider two software faults with the same root cause. A logic error in a spreadsheet miscalculates a forecast, and a colleague catches it in review. The identical error in a vehicle’s perception stack misclassifies a pedestrian, and nothing sits between that decision and the physical world.
The code is no more advanced in the second case; only the output changed, from a number on a screen into force in the world. This is the quiet inversion running through the industry. We spent forty years optimizing software for speed of iteration, rewarding teams that shipped fast and fixed later, and we are now pushing that same fast, imperfect software into systems where fixing later can mean after a collision, a burn, or a fall.
Why “Undo” Is Disappearing
The clearest lens for this shift is reversibility. Traditional failures were informational, and information can be restored from a backup; a physical failure turns a computation into an event, and events obey thermodynamics rather than version control. There is no restore point for a fractured bone.
That single distinction rewrites what an acceptable failure rate even means. A messaging app that drops one message in ten thousand is a fine app; a braking controller that fails once in ten thousand activations is a public danger. The same engineering event lands very differently depending on which side of the screen it occurs.
| Dimension | Informational failure | Physical failure |
| Typical outcome | Lost data, a wrong number, downtime | Motion, force, injury, property damage |
| Recovery path | Reboot, restore, refund, patch | Often none; the harm is already done |
| Time to consequence | Minutes to days, usually noticed first | Milliseconds; the consequence precedes review |
| Tolerable error rate | Relatively high, softened by retries | Near zero on any safety-critical path |
Once framed this way, much of the current unease about advanced technology becomes clearer. The worry is rarely the intelligence of a system in the abstract; it is that we are granting physical authority to systems built with tolerances designed for a reversible world.
The asymmetry also runs deeper than the raw error rate. In a reversible system the cost of making a mistake and the cost of catching it late are roughly the same, since both end in a fix. In an irreversible one those costs diverge violently: catching a fault in review costs an afternoon, while missing it can cost a life, and no amount of later diligence buys the outcome back. Engineering for the physical world is, at bottom, the practice of pushing every possible discovery of error earlier, before the machine is ever allowed to move.
What Made the Physical Turn Affordable
The physical turn is not ambition alone, it became affordable when four cost curves crossed at once. Sensors that once cost thousands now cost cents, batteries store enough energy to move heavy objects for hours, actuators have grown precise and cheap, and machine-learning models finally became good enough to act on perception rather than merely describe it.
The evidence is in deployment scale, not laboratory demonstrations:
• The number of industrial robots in operational use worldwide reached roughly 4.66 million units in 2024, according to the International Federation of Robotics, with about 542,000 new units installed that year alone, more than double the annual figure from a decade earlier.
• Collaborative robots, the kind explicitly built to work beside people rather than behind fences, rose from around 11,100 units installed in 2017 to roughly 64,500 in 2024, the fastest growth in the machines least separated from human bodies.
• Waymo’s driverless vehicles had logged more than 170 million rider-only miles on public roads by early 2026, a scale at which the software is no longer being tested so much as woven into ordinary traffic.
None of these numbers would have been credible in 2010. Together they mark the moment computation stopped being something we look at and became something that pushes back on the world.
Scale, moreover, is not only a sign of progress here; it is itself a source of risk. A flaw in a phone app inconveniences its users one screen at a time, but a flaw in a fleet of identical vehicles, or in a model shipped to thousands of identical robots, is a single defect copied across the physical world at once. Software’s great economic advantage, that one build runs everywhere simultaneously, becomes a safety liability the moment that build can move objects, because a latent fault then waits quietly in every unit until the precise conditions that trigger it happen to arrive.
When Decisions Become Motion
In classical software, many layers of abstraction sat between a developer’s commit and any real effect, and each layer offered a chance to catch a mistake. A cyber-physical system compresses that chain until a decision made in silicon becomes force in the world within milliseconds, faster than any human supervisor can intervene.
This collapse of distance, more than any single technology, is why physical consequences are growing. When perception, decision, and actuation happen inside one tight loop, there is no natural pause in which a person can veto a bad call, so safety can no longer be a step bolted on at the end.
There is also a subtler trap. Autonomous systems rarely fail on the common case, they fail on the rare one, the couch fallen on the highway, the person in an unusual costume, the low sun that washes out a camera. A model can perform superbly across billions of ordinary situations and still meet a scene effectively absent from its training, and in a physical system that single novel case is a crash rather than a shrug. This is why total miles driven is a misleading proxy for safety.
On the Road: Software That Steers
Autonomous and driver-assist systems are the most visible frontier of this shift, and the early data is genuinely encouraging. Studies of Waymo’s rider-only fleet found roughly 80 percent fewer injury-causing crashes than human benchmarks on the same streets, and independent analysis by the Insurance Institute for Highway Safety put the overall crash-involvement rate about 68 percent lower than that of human drivers. Fewer crashes is an unambiguous good, worth stating plainly before any caution.
Yet a lower crash rate is not a zero crash rate, and every remaining collision raises a question the software cannot answer on its own: who is responsible when no one was driving? When a human errs, liability is well understood; when a vehicle guided by a perception model strikes someone, responsibility fractures across the manufacturer, the software vendor, the fleet operator, and sometimes a safety driver who was told to trust the system.
This is where the physical turn meets the human institutions built to handle harm, and those institutions have not gone anywhere. Someone injured by a partially automated vehicle still files a claim, still needs the crash reconstructed, and still relies on a professional such as a Maine car accident attorney to establish fault and pursue compensation, because the system that assigns real-world consequences stays stubbornly human even when the driving is not. Automating the action does not automate responsibility for it, and the gap between the two is exactly where the physical cost of software now lands.
On the Factory Floor: Machines Without Fences
For decades industrial robots were kept behind physical barriers, and the safety model was simple: keep people and machines in separate spaces. The economics of collaborative robots dismantled that model on purpose, placing powerful actuators within arm’s reach of workers so the two can share a task.
That proximity is the entire point and the entire risk. A cobot that misjudges the position of a hand does not log an exception, it produces a crush injury, and the speed and torque of an industrial arm leave no time to react once a motion has begun. These machines are also the fastest-growing category precisely because they remove the fence, and they are being adopted by the smaller manufacturers and workshops that historically employed the fewest safety engineers, so the surface area for harm widens faster than the safety culture around it can mature. Every newly automated workshop, in effect, becomes a place where AI automation can turn a software decision into physical action within reach of an unprotected human body.
Inside the Body: Where There Is No Backup
Nowhere is reversibility scarcer than inside the human body, and that is exactly where software is heading next. Robotic surgical systems assist in millions of procedures, insulin pumps and cardiac devices dose and pace automatically, and algorithms increasingly adjust treatment in real time.
Here a defect is not a bug report, it is a clinical event, and the margin for error is set by physiology rather than by user patience. Regulators have long treated software-driven therapy devices as their own risk class, because a coding fault can translate straight into a dose or a shock delivered to living tissue, and recalls of infusion pumps and implantable devices for software defects have periodically reached hundreds of thousands of units.
What makes the trend sharper is that treatment is increasingly continuous and automated rather than a discrete act a clinician signs off on, so a subtle timing fault or a miscalibrated sensor can act on a patient for hours before anyone notices. The benefits are real and often life-saving, which is exactly why the failure modes deserve equal seriousness.
Behind the Wall: Grids, Water, and Control Systems
The largest physical systems governed by software are the ones we notice only when they fail. Power grids, water plants, pipelines, and building controls are now cyber-physical systems in which a software fault or a security breach produces kinetic rather than merely digital effects.
Most of this equipment was built when the controllers running pumps, turbines, and valves were assumed to be sealed off from the open internet. That assumption dissolved as operators connected their machinery for remote monitoring and efficiency, exposing decades-old control hardware, never designed with security in mind, to networks anyone can probe. A vulnerability that once leaked data can now open a valve or drive a motor past its safe limit, so a security failure and a physical failure become the same event, and the consequence scales with the infrastructure, from a darkened region to a contaminated water supply.
The Question of Who Is to Blame
Every physical consequence eventually becomes a question of accountability, and our legal frameworks were largely written for products that do not think. Traditional product liability assumes a defect fixed at the moment of sale, but a learning system keeps changing after deployment through updates and adaptation, blurring the line between a manufacturing defect and an operational decision.
Responsibility now diffuses across a long chain, and each link can plausibly point to another:
• The sensor supplier and the chipmaker, whose readings and hardware produced the input and ran the inference, either of which can be blamed for a faulty signal.
• The model vendor that trained the system on data it did not fully control, and the integrator who tuned it for one specific machine and environment.
• The operator who deployed it, the organization that maintained it, and the user who may have been encouraged to trust it past its real competence.
The comfortable phrase “human in the loop” was meant to resolve this, but it increasingly works as a liability shield rather than a genuine safeguard. Asking a person to supervise a system that acts faster than human reflexes, then holding that person responsible when it errs, is the appearance of oversight rather than its substance, and courts and regulators are only beginning to reckon with the difference.
Borrowing Safety From the Older Industries
The culture that built the software industry does not survive contact with physics. “Move fast and break things” is rational when breakage is reversible and cheap, and reckless when breakage means a severed finger or a highway pileup. Fortunately, the industries that already live in the physical world have spent decades writing this discipline down.
| Field | Standard | What it demands of safety-critical software |
| Automotive | ISO 26262 | Functional-safety analysis that ties each hazard to a required integrity level and evidence |
| Avionics | DO-178C | Rigorous traceability from requirements to code to test, sized to how badly a fault could hurt |
| Medical devices | IEC 62304 | A defined software life cycle with risk classification and controlled changes after release |
| Industrial / process | IEC 61508 | Proving that a system fails into a safe state, with redundancy where a single fault is unacceptable |
The open problem is that the newest physical systems are built by companies with roots in consumer software and trained models rather than in aviation or medicine, so they often sit at the edges of these standards or outside them. Much of the real work of this era is translation, carrying hard-won safety engineering across from the fields that learned it painfully into the ones now acquiring physical power for the first time. That work is slower and costlier than shipping features, and the cost is simply the price of admission to the physical world.
Building Machines That Fail Gently
Because physical systems cannot promise never to fail, the mature goal is to govern how they fail. An autonomous vehicle sensing a fault should ease to the roadside rather than freeze in a lane; a robotic arm losing confidence in its position should stop rather than finish an uncertain motion.
In ordinary software a crash is an inconvenience to be logged, but in the physical world the failure state is a design decision as important as the success state, and graceful degradation, real redundancy, and genuine human override belong at the center of the design rather than at its edges.
None of this is an argument against the technology. Safer roads, more precise surgery, and more resilient infrastructure are real prizes, worth pursuing seriously rather than fearfully. But they are only won if we retire the assumptions of the reversible age as deliberately as we adopt the powers of the physical one.
The task ahead is not making technology more powerful, it is making powerful technology fail gently, answer clearly for what it does, and earn the physical authority we are already handing it. Treating software as machinery rather than as media is the whole of the work, and it begins now.
