The Software-Defined Vehicle: Or How They Sold You a Half-Built Car and Called It the Future
You want to know what the most expensive lie in the automotive industry is right now? Not the fuel economy numbers. Not the five-star…
The Software-Defined Vehicle: Or How They Sold You a Half-Built Car and Called It the Future
You want to know what the most expensive lie in the automotive industry is right now? Not the fuel economy numbers. Not the five-star safety rating on a truck that turns into a rolling campfire when the battery gets wet. The most expensive lie is three words. Three beautiful, meaningless, consultant-approved, PowerPoint-ready words.
Software. Defined. Vehicle.
Say it out loud. Software-defined vehicle. Doesn’t that sound incredible? Doesn’t that sound like something a very serious, very intelligent person who went to a very good business school came up with between their third espresso and their eleven o’clock earnings call? It sounds like the future. It sounds like progress. It sounds like exactly the kind of thing you should pay an extra fifteen thousand dollars for.
And here is the beautiful part. Here is the part that should make you appreciate the craftsmanship involved. The people saying it know it’s not true. The engineers who build these cars know it’s not true. The consultants who wrote the strategy decks know it’s not true. They surveyed eleven hundred automotive developers and those developers said, anonymously, because they can’t say it publicly, that their companies are deploying this technology before the systems to support it safely even exist. That is not incompetence. That is a plan. A very good plan. For them.
HERE IS WHAT IT IS SUPPOSED TO MEAN
A software-defined vehicle is supposed to be a vehicle whose behavior is determined by software running on centralized hardware rather than by fixed physical components. Like a smartphone. Your car gets better over time. New features arrive while you sleep. A safety problem in your brakes gets fixed overnight without you driving to a dealership and waiting in a plastic chair next to a coffee machine that has been broken since 2019.
That is what it is supposed to mean.
You know what it actually means when General Motors or Ford or Stellantis puts it on a window sticker?
The radio gets map updates.
That’s it. That is the software-defined vehicle. Your navigation system knows about the new roundabout they built. Everything else — the braking system, the steering, the powertrain control, the battery management, all of the systems that determine whether your car moves, stops, or catches fire — is running on hardware designed in the 1990s, communicating over protocols invented in 1983, sealed inside black boxes that were never intended to be touched after they left the factory.
The software-defined vehicle is a label on the navigation system. Below that label is the same hardware-defined car you would have bought in 2005, wearing a turtleneck and charging you a subscription for the heated seats that are already installed in the vehicle you already paid for.
LET ME TELL YOU ABOUT THE THING RUNNING YOUR CAR
Because nobody in the industry wants to talk about this part. They want to talk about the future. The future is very convenient because it doesn’t exist yet and you can’t test drive it.
A current GM, Ford, or Stellantis vehicle has somewhere between seventy and one hundred and fifty separate electronic control units inside it. One hundred and fifty separate little computers. One for the brakes. One for the transmission. One for the engine. One for the airbags. One for the HVAC. One for each window. One for the body control module. One for the infotainment. It goes on. It keeps going. You think it’s going to stop and it doesn’t stop.
Each one of these ECUs was built by a different supplier. Bosch built some. Continental built some. Aptiv built some. Each one uses its own proprietary operating system. Its own software architecture. Its own calibration tools. Each one is what engineers call a sealed black box. It accepts inputs. It produces outputs. It runs its fixed software. And it is never intended to be changed after it leaves the production line. Ever. That was the deal. Sealed. Done. Goodbye.
These one hundred and fifty boxes talk to each other using a protocol called CAN bus. CAN bus was invented in 1983. Not updated in 1983. Invented in 1983. It tops out at one megabit per second. A modern smartphone operating system update is hundreds of megabytes. Pushing that over CAN bus would take days and it would block every other message the vehicle needs to send simultaneously to keep the engine running and the brakes working. You would push an update and your car would choose between the update and the brakes. That is not a hypothetical. That is the architecture.
This architecture has a name. AUTOSAR Classic Platform. It was valued at six point eight billion dollars in 2025. And here is the number that should make you put down whatever you are eating. It is projected to grow at eight and a half percent per year through 2034. Not shrink. Grow. The industry is building more of this architecture every year. In more vehicles. While telling you those vehicles are software-defined.
The architecture that can actually do what they’re promising has also existed since 2017. It’s called AUTOSAR Adaptive Platform. It uses actual networking instead of the 1983 thing. It runs on centralized computing hardware instead of one hundred and fifty separate boxes. It was specifically designed to enable the post-launch software updates the industry has been promising.
You know what happened in the eight years since it was published?
Every manufacturer built their own version of it. BMW built one. VW built one. Mercedes built one. Bosch built one. Continental built one. And none of them work with each other. Zero interoperability. Eight years of every major company in the industry independently spending billions of dollars building incompatible versions of the same standard that was supposed to end incompatibility. In 2025, the standards body had to publish an open-source reference implementation specifically to rescue the situation. The consortium used the phrase “integration nightmare” in its own announcement. “Vendor lock-in.” “Spiraling costs.” Those are their words. About their own standard. That they have been running for eight years.
This is what they’re building your software-defined vehicle on top of. A 1983 communication protocol. One hundred and fifty sealed black boxes from a hundred different suppliers. Eight years of a next-generation standard that produced eight years of proprietary incompatible interpretations. And a market projection showing the old architecture growing for the next nine years.
But have you seen the promotional materials? Beautiful. Really first-rate work.
THE SILVERADO: A CASE STUDY IN THE ART FORM
You don’t need to understand AUTOSAR to understand what this costs you. You just need to look at the Chevrolet Silverado EV.
GM’s flagship electric truck. Built on the revolutionary Ultium platform. Forty thousand to ninety thousand dollars depending on trim. Billions spent in development. Marketing materials absolutely packed with language about software integration, over-the-air updates, and the vehicle becoming better over time.
Here is what the customers got instead.
Owners started seeing a warning message on their displays. “Service High Voltage System.” Sometimes the regenerative braking just stopped working. Sometimes the truck went into what is politely called a “reduced power mode,” which means you paid ninety thousand dollars for a truck that just decided not to be a truck anymore. This happened during highway driving. Cold weather. Sustained loads. Normal things. Things any manufacturer with an actual pre-production validation program would have tested before shipping the product to human beings who paid for it.
Now here is the part where you need to pay attention, because this is where the craft really shows.
In November 2022, GM issued a Technical Service Bulletin. A TSB is an internal engineering document acknowledging a known field problem and telling dealers how to address it. This TSB documented moisture getting into the battery pack and causing isolation test resistance issues. They knew about the moisture problem. Before. The first. Customer. Took. Delivery.
Their response was to have dealers reflash the Battery Energy Control Module to adjust its fault detection thresholds. Not redesign the seal. Not fix the drainage path. Adjust the software so the module is less sensitive to the moisture. The moisture is still there. The software just stopped being as upset about it.
In October 2025, three years later, GM issued a formal service campaign. The official description says the update “refines BECM software to better identify moisture-related conditions.” Three years. The enclosure design has not changed. The moisture is still there. They have now refined the software twice to be less bothered by the moisture that was there before the cars shipped.
There is a NHTSA bulletin about cold weather. The battery thermal management system was diverting power to heat the cabin and precondition the battery simultaneously, and the power budgeting algorithm hadn’t been calibrated for that scenario, so there wasn’t enough power available at the wheels when the driver wanted it. Cold weather. High power demand. Cabin heating on. Three things that happen simultaneously every winter morning in every cold climate on Earth. Apparently nobody ran that test.
The most serious issue is the thermal propagation recall covering 2023 through 2025 model years. Thermal propagation is the technical term for a battery fire spreading from one cell to all the others. NHTSA’s recall says the HV battery modules may experience thermal propagation. This is not fixable with software. Thermal propagation is a physical consequence of not having adequate barriers between cells. No software update changes what happens when lithium ion gets hot in a poorly constrained enclosure. The remedy is battery module inspection and replacement.
And then there is the one that deserves its own paragraph because of its specific character. A Canadian service company found that the Ultium pack’s pyro fuse — the explosive charge that disconnects the high-voltage system in a crash — can be accidentally triggered by the seatbelt pretensioner’s pyrotechnic charge in certain crash scenarios. The seatbelt fires. The HV system disconnects. The DC-DC converter goes offline. The twelve-volt system dies. And the vehicle is sitting in a crash without hazard lights, without emergency lighting, without powered door unlocking. Two pyrotechnic devices interacting with each other in a way nobody apparently modeled. No software patch addresses this because it is two physical explosive charges talking to each other in a way their designers did not intend.
The pattern is the same every time. Hardware integration problem. Software adjustment as the first response. Physical campaign when the software limit is reached. And the vehicle was shipped knowing about at least some of these conditions because the moisture TSB is dated before the first sale.
That is not bad luck. That is a methodology.
WHY THIS MAKES PERFECT SENSE IF YOU ARE THEM AND NOT YOU
Now. Before you get angry. Understand that this is not irrational. From their perspective this is exquisitely rational. This is what happens when the people who understand finance are making decisions that should be made by people who understand physics.
Revenue recognition under US GAAP and international accounting standards recognizes vehicle revenue at delivery. Not at feature completeness. Not at validated software stability. At the moment the customer drives it off the lot. A manufacturer that ships a vehicle with eighty percent of its intended software functionality and patches in the other twenty percent over the next eighteen months has already booked one hundred percent of the revenue. The missing twenty percent doesn’t appear on the income statement. It goes in the warranty reserve, which is a much smaller number, subject to management judgment, and very easy to bury in the footnotes.
The shareholder pressure is its own beautiful piece of machinery. The automotive industry has spent four years watching Tesla trade at valuation multiples that only make sense if Tesla is a software company. Software companies trade at ten to thirty times revenue. Car companies trade at three tenths to half of revenue. When a GM board looks at that gap the message is not subtle. Say you are a software company. Announce the OTA capability. Commit to recurring software revenue timelines. Watch the multiple expand. The product doesn’t have to actually be software-defined. The announcement does.
The legal protection is even more elegant. Most OEM sales contracts now contain language reserving the right to modify vehicle software post-sale via over-the-air updates. Fieldfisher, a law firm that analyzed this, found that customers are explicitly signing away their right to the product as described at purchase, buried inside the terms and conditions. NHTSA’s recall authority applies to safety defects but not to feature non-delivery. EU product liability covers physical defects but software is a grey zone in most member states. Manufacturers have had teams of lawyers working on this framework for years. You have not.
Tesla owners found out what this means in practice when class action plaintiffs documented OTA updates that reduced driving range on 2016 to 2019 Model S and X vehicles by up to twenty percent. Tesla said it was a safety improvement. They also said customers consented to software modification when they accepted the Terms of Service. Which is true. That is in the Terms of Service. Right there on page thirty-one of the forty-seven page document you agreed to when you turned on the navigation system for the first time.
You consented. You just didn’t read it. Neither did anyone else. That’s the business model.
ONE THOUSAND ONE HUNDRED ENGINEERS TOLD THE TRUTH ANONYMOUSLY
L’Embarqué surveyed eleven hundred embedded automotive developers in October 2025 about the state of SDV readiness inside their organizations.
The majority reported their organizations are deploying OTA update capabilities before their internal validation and verification processes are mature enough to support them safely.
The top three pressures driving premature deployment: competitive pressure to match Tesla, executive pressure to meet launch dates, and finance teams wanting earlier revenue recognition.
Finance teams. Wanting earlier revenue recognition. Making decisions about when safety-critical vehicle software update systems get deployed to millions of vehicles on public roads.
These are people who look at a spreadsheet and see a Q3 number that needs to move, and they look at the engineering schedule and they say can’t we just ship it now and fix it later, and the answer they get is yes, we can, because there’s a legal framework that covers us and an accounting standard that rewards us and a consumer protection regime that hasn’t caught up yet and a four-word marketing phrase that makes it sound like a feature.
A ResearchGate paper from January 2026 documents the specific mechanisms by which these OTA deployments fail. State dependency failures: the update assumes the vehicle is in one condition, the vehicle is in a different condition, the verification gate doesn’t check, the update runs anyway on an incompatible system. ECU interdependency failures: you update one module, it changes its communication timing, adjacent modules start interpreting its messages as corrupted, cascading errors. Rollback failures: the update already wrote to non-volatile memory on a safety-critical module and there is no validated rollback path because nobody thought to build one, so the vehicle is now in a state it cannot get out of without a technician with a laptop.
These are not theoretical. These are the VW ID.5 that sat immobilized for ten days after a recall software update failed halfway through. These are the Silverado EV that required flatbed transport after an OTA bricked it. These are what “continuous improvement through software” looks like in the driveway of someone who thought they bought a finished product.
AQI GmbH, a German quality consultancy, had the intellectual honesty to write a paper examining the claims of their own previous paper. Their previous paper said OTA could reduce recall costs by up to seventy percent. Their new paper pointed out that the seventy percent figure was calculated against the wrong baseline. It was compared to a world with no OTA, not to a world where the product was built correctly and didn’t need fixing. Against the correct baseline — thorough pre-launch validation that catches the problem before the customer does — the OTA savings are not savings. They are the cost of deciding not to get it right the first time, laundered through an update server and described as a benefit to the consumer.
CHINA BUILT THE REAL THING AND DETROIT BUILT THE MARKETING DECK
While Western manufacturers were figuring out how to put “software-defined” on a vehicle running 1983 communication protocols, Chinese EV manufacturers were building the actual thing.
NIO and Xpeng and Li Auto and the Huawei-backed AITO brand had no legacy ECU architecture to preserve. No forty-year-old supplier contracts to honor. No union agreements written around hardware production processes. No corporate culture that treats software as something you add at the end like trim levels.
They hired software engineers at software industry salaries. They adopted continuous integration development practices. They designed the vehicle architecture around centralized compute from the first day of the first requirements document. Because they had never done it any other way there was nothing to unlearn.
S&P Global put a six-level SDV readiness framework together and assessed where everyone sits. Chinese EV-native manufacturers are consistently at Level 3 to 4. Genuine OTA capability for drivetrain and ADAS systems. Centralized domain architecture. Actually software-defined in the meaningful sense. Western legacy OEMs are predominantly Level 1 to 2. The navigation system gets updates. Some body control functions. That is the product.
S&P also projects that by 2028, the gap will be wider than it is today. Western modernization is moving slower than Chinese baseline advancement. The market is not waiting.
The 2026 Beijing Auto Show confirms the outcome. Chinese NEV market share hit fifty percent of all new vehicle sales in early 2026. The show floor featured virtually no new internal combustion engines. Volkswagen made a special effort and was still relegated to a corner. The market that Western manufacturers said needed ICE platforms for markets like China has eliminated itself from that argument within one decade.
The customer in Shanghai buying a BYD Seal is getting genuine over-the-air powertrain optimization. The customer in Detroit buying a Silverado EV is getting their BECM moisture detection thresholds adjusted for the second time while the enclosure that lets moisture in has not been redesigned.
THE LANGUAGE IS THE WEAPON
Here is the craftsmanship. This is where you have to appreciate what was actually built here, even if you hate it, because it is a genuinely impressive piece of engineering in the field of saying things that are technically true and completely misleading simultaneously.
When they say “over-the-air capable,” that is true. The vehicle has a cellular connection. It can receive data. What it cannot receive is meaningful updates to its safety-critical systems, because those systems are on sealed ECUs that were not designed to accept updates. But they did not say “over-the-air updateable in every system that matters.” They said “over-the-air capable.” And they are correct.
When they say “software-defined,” they are referring to the infotainment domain and some body control functions. The brakes, the steering, the powertrain, the battery management: hardware-defined, fixed at production, cannot be meaningfully updated without a dealer visit and a TSB. But they did not say “fully software-defined.” They said “software-defined.” And they are technically correct.
When they say “continuous improvement through software,” what they mean is: we will fix what we shipped broken by patching the systems we can actually patch, and we will describe those warranty repairs as enhancements. But they did not say “we will fix our mistakes.” They said “continuous improvement.” And they are correct that it is continuous.
When they say “we can always update it later,” what the engineering organization hears is: we don’t have to validate it now. The development schedule shrinks. Testing gets cut. The launch happens on time. The customer becomes the test fleet. The fix comes eighteen months later. The press release calls it an enhancement. The warranty reserve absorbs the cost. The quarterly earnings call mentions the improvement. Nobody connects the dots publicly.
Bruce Schneier, the security technologist, raised a point that the financial press is ignoring because it doesn’t fit in a six-month investment thesis. Automotive software must be supported for fifteen to twenty years of operational vehicle life. A smartphone manufacturer ends software support after five years and the customer buys a new phone. An automotive manufacturer that ends software support for a 2024 vehicle in 2034 is leaving safety-relevant systems unpatched on vehicles that are still being driven by people who spent sixty thousand dollars and have no way of knowing their vehicle’s security architecture was quietly discontinued because the product line was no longer profitable enough to maintain.
And if the manufacturer goes bankrupt, the vehicles they made that require a live server connection to authenticate their operating software become permanently inoperable. Not broken mechanically. Not worn out. Bricked by a bankruptcy filing. This has already happened. It will happen again at larger scale because the dependency has been engineered into the product and the product has been engineered to generate ongoing revenue from the dependency.
THE BOTTOM LINE, WHICH IS THAT YOU ARE THE TEST DRIVER
The software-defined vehicle is a real concept. It works when it is built by organizations that structured themselves around software from the beginning, with the architecture to support it, the engineering discipline to validate it, and the intellectual honesty not to ship something until it is finished. Tesla built this, mostly. BYD is building it. It is genuinely transformative when it is real.
When it is not real — when the architecture is 1983 CAN bus under the hood, when the organization cannot complete the transition to centralized software management that eighty-six percent of OEMs by their own admission have not done, when the financial incentives reward delivery over completeness and the legal frameworks have not been updated to hold anyone accountable for the gap — then “software-defined vehicle” is a mechanism for moving the cost of unfinished engineering from the manufacturer’s balance sheet into your driveway.
The person sitting on the highway shoulder in limp mode waiting for roadside assistance to come to their ninety-thousand-dollar truck is not experiencing the future of mobility. They are experiencing the financial model of an industry that figured out how to make incomplete work invisible on the income statement and unactionable in the courts, wrap it in four words that sound like innovation, and charge you for the privilege of being the first person to find the bugs.
The fifteen hundred euros you paid to unlock heated seats that are physically installed in the vehicle you already bought are not a software feature. They are a ransom note. The seats are there. The heat is there. The wire is run. The switch exists. You paid for the car. You paid for all of it. They just put a software lock on it and set a price for the key.
And that is not the future. That is a toll booth on a road you already paid for. Built by people who understood accounting better than engineering, surrounded by lawyers who understood terms of service better than product liability, and blessed by regulators who are still figuring out that the problem exists.
The engineers who built it know all of this. They said so. Anonymously. Because they cannot say it in their own name.
And that is why you should be furious.
If you’re enjoying the content on my blog and would like to dive deeper into exclusive insights, I invite you to check out my Patreon page. It’s a space where you can support my work and get access to behind-the-scenes articles, in-depth analyses, and more. Your support helps me keep creating high-quality content and allows me to explore even more exciting topics. Visit patreon.com/ChristianBaghai and join the community today! Thank you for being a part of this journey!
HERE’S WHAT THEY BUILT AND THEY’RE VERY PROUD OF IT | Patreon
RUE DE RIVOLI: HOW THEY TURNED A STREET INTO A SHOPPING MALL WITH BICYCLES | Patreon
THE PANIC MACHINE: HOW EIGHT SICK PEOPLE KEPT AN ENTIRE CONTINENT UP AT NIGHT | Patreon
How Ukraine Made the Russian Military Believe Its Own Bullshit | Patreon
The Invisible Fleet: How America Bailed on Bahrain Without Admitting It | Patreon
Ukraine at War: The Week That Changed the Battlefield | Patreon
Seven People Died on a Boat and the Whole Planet Lost Its Mind | Patreon
THE AMERICAN CORRUPTION THAT BUILT IRAN’S FINANCIAL EMPIRE IN IRAQ | Patreon
Holy Hustle: The Foreign Propaganda Machine Hiding Inside Your Megachurch | Patreon
The Accelerant: America Was Already on Fire Before They Bombed Iran | Patreon
The Market Is Having Its Quarterly Breakdown | Patreon
THE AMERICAN VIOLENCE PARADOX | Patreon
메타데이터
- post_id
- 46f62d442d36
- slug
- the-software-defined-vehicle-or-how-they-sold-you-a-half-built-car-and-called-it-the-future-46f62d442d36
- url
- https://medium.com/@christianbaghai/the-software-defined-vehicle-or-how-they-sold-you-a-half-built-car-and-called-it-the-future-46f62d442d36
- canonical_url
- https://medium.com/@christianbaghai/the-software-defined-vehicle-or-how-they-sold-you-a-half-built-car-and-called-it-the-future-46f62d442d36
- author_url
- https://medium.com/@christianbaghai
- status
- ok
- fetched_at
- 2026-06-09 15:37:30
