Nearly 30 million recalls explain the software-defined car’s real problem

Nearly 30 million recalled vehicles is the number that should sober up the software-defined-car era. Not because code in cars is inherently bad. Because the industry is increasingly selling software like a product layer while still validating it like a late-cycle feature.

Reported fact first: CarBuzz’s recent recall analysis points to software as the culprit behind nearly 30 million vehicle recalls last year. Motor1’s camera explainer lays out the hardware side of the same shift: new vehicles now carry lenses in places like the grille, mirrors, windshield, and dashboard for driver assistance, parking, visibility, and cabin monitoring. Carscoops, meanwhile, reports the business reason the software layer keeps expanding: GM keeps about 70 cents of every subscription dollar, versus about 4 cents on a car sale.

Field Signal read: those three facts describe one machine. The modern car is becoming a rolling sensor stack with a recurring-revenue interface attached. The failure mode is not the screen. It is the gap between how fast software teams can ship, how slowly safety-critical validation should move, and how little control the owner has once cameras, compute, and features become bundled into a remotely managed product.

This is why the camera count matters. A windshield camera is not just a convenience part. It feeds lane keeping, automatic emergency braking, adaptive cruise behavior, traffic-sign recognition, dashcam functions, or driver monitoring depending on the car. A mirror camera is not just a lens; it becomes calibration labor after a collision. A cabin camera is not just another sensor; it creates a data-rights question inside a privately owned vehicle. Once those systems are tied to subscriptions or OTA feature flags, the carmaker is no longer merely selling equipment. It is operating a service inside someone else’s garage.

There is a good version of this future. Waymo is the cleanest counterexample in the brief. The Drive reports that a study found Waymo’s self-driving cars crash less often than human drivers, while noting that the authors still want more data. Electrek’s writeup of the IIHS-related analysis says Waymo crashes 68 percent less than the average human driver, again with caveats. The important distinction is operational discipline: Waymo’s product is a controlled autonomous service with mapped operating domains, fleet monitoring, and a feedback loop built for software behavior. That is a different problem from shipping millions of privately owned vehicles with feature combinations that vary by trim, market, subscription state, repair history, and software version.

The operator lesson for car companies is blunt: if the vehicle is software-defined, the release workflow has to be vehicle-defined. That means hardware abstraction is not enough. Every OTA update needs a bill of materials map, sensor-calibration state, regional regulation check, feature-entitlement state, and rollback plan. The test matrix has to know whether the car has the windshield camera replaced by a body shop, whether the owner declined a connected-services plan, whether a feature is active only during a trial, and whether a previous update changed braking, steering, lighting, or driver-alert timing.

That is expensive and unglamorous. It is also the part customers feel. A bad phone update annoys you. A bad vehicle update can disable a safety feature, trigger a recall, or strand a service department with cars that are mechanically fine and logically confused. Dealers then become software triage centers. Independent repairers need calibration access and service documentation. Owners need to know which features will still work if they stop paying, sell the car, replace a module, or opt out of data sharing.

The money explains why this is not going away. If a subscription dollar really carries a dramatically better margin than a vehicle sale, automakers will keep hunting for software attach points: enhanced navigation, driver-assistance packages, remote functions, camera recording, performance modes, charging features, and concierge services. Some of that can be useful. But the moment a paid feature touches the car’s sensors or control systems, the company owes the driver a clearer contract: what data is collected, what happens offline, what survives resale, what can be repaired outside the dealer network, and what changes after an update.

Enthusiasts should care because this changes how cars age. A great engine can be rebuilt. A hydraulic rack can be refreshed. A mechanical limited-slip diff can be understood on a bench. A software-defined ADAS stack ages differently: camera resolution, compute headroom, update eligibility, subscription policy, and calibration tooling become part of the car’s long-term character. The next collectible performance car may be judged not only by its suspension geometry or shift feel, but by whether its best functions still work after the server contract changes.

So no, the answer is not to make cars dumb again. Cameras prevent curb rash, help emergency braking, and can make big vehicles easier to place. OTA updates can fix problems without a service visit. Fleet learning can make autonomy safer when the domain is tightly managed and the evidence is honest. The answer is to stop treating automotive software like a growth hack bolted to a homologated machine.

The tell is still that recall number. Nearly 30 million vehicles is not an argument against code. It is an argument for grown-up software governance: slower safety releases, better simulation, open repair paths, transparent data rights, durable feature ownership, and validation that follows the car after it leaves the plant. The software-defined car will only earn the name when the software is as maintainable as the hardware it now controls.