The auto industry is trying to run two clocks at once, and they are badly out of sync. A new vehicle still takes years to design, engineer, test, and bring to market. The code running inside it can change in weeks. Every OEM racing toward electrification, AI, connectivity, and autonomy is, at some level, still bound by a production rhythm built for a different era, one where the engine and the chassis were the product, and everything else was an accessory. A recent McKinsey analysis puts a number on that mismatch: the global automotive software and electronics market is set to grow more than four times faster than the vehicle market itself through 2035.
A timeline problem disguised as a technology problem
Here’s why the mismatch matters in practice. Software has gone from introducing something new every few years to shipping updates every few weeks. Hardware hasn’t made that same jump. After decades of vehicles being built hardware-first, catching up means letting software set the pace and having physical design decisions follow it, a reversal of how the industry has always worked. Most new capabilities must be engineered into a vehicle from the ground up, which usually means waiting for the next full model launch. A smaller number can be added to an existing design through a minor mid-cycle refresh if the hardware and compute underneath can support it without a redesign. Either way, the vehicle’s release calendar determines when a driver gets access to something new, regardless of how quickly that capability keeps improving in the world.
LiDAR shows how wide that gap can get. Sensing range and resolution improve on a timeline measured in months. A vehicle program, by contrast, locks its sensor specification three to five years before launch, then lives with that choice for years of production after that. By the time a new model reaches showrooms, the LiDAR inside it may already trail what a supplier can ship, and every new capability demands its own round of testing and validation, so a program chasing the latest hardware never catches it.
Software alone can’t solve this. An over-the-air update can teach a car new tricks with the sensor it already has, but it can’t give that car a sensor it doesn’t have. Getting there takes two more pieces alongside the software update: hardware designed so an old sensor can be swapped out directly, and a reason for drivers to bring their car in for that swap.
Putting software at the center
AI provides a useful comparison. Companies that added AI as a feature on top of an existing product usually got underwhelming results. The ones that got real value rebuilt their products, teams, and decision-making with the AI model itself as a core design input. Automotive is heading toward the same choice. A software-defined vehicle needs more than a better infotainment screen. Its operating system, data pipeline, and update mechanism must carry the same design weight as the drivetrain and the chassis, built in from the earliest stage of engineering.
Zonal and central architectures give a vehicle the physical foundation to support this kind of software-first design. Consolidating dozens of distributed control units into a smaller number of computing zones gives an OEM a foundation that can absorb new software without a full hardware redesign every time. But there’s a caveat. Once zonal architecture becomes standard across a model lineup, its advantage levels off, and growth eventually returns to the pace of the broader vehicle market. The near-term opportunity is real, but it belongs to the transition itself, not to a trend that keeps paying off indefinitely.
Tesla, Rivian, and Lucid are the clearest proof this works, and it’s not a coincidence that all three built their engineering organizations around software from the outset. They never had to unwind a legacy computing architecture or retrain teams that spent a career thinking about the vehicle as a mechanical product first. Established OEMs are doing exactly that work right now, and it’s a harder transformation than any single product launch, because it touches how the company is organized, not just what the car can do.
Borrowing a page from consumer electronics
There’s a useful precedent sitting in almost everyone’s pocket. For years, every phone, laptop, and accessory manufacturer used its own proprietary charging connector, locking customers into closed ecosystems and forcing them to keep a drawer full of mismatched cables just to charge their own devices. USB-C changed that by standardizing the physical interface, letting the technology inside continue to evolve without forcing a redesign of the connection itself.
Automotive needs its own version of that idea, and the LiDAR example points to what it would really take. Sensors, compute modules, and connectivity hardware are currently welded into a vehicle’s design in ways that make later upgrades expensive or impossible. A car purchased today is, in effect, frozen at the technology level available when it left the factory. If sensor mounts, wiring harnesses, and compute interfaces were standardized and modular the way charging ports became, a driver could bring a car in for a sensor swap the same way they’d bring it in for new tires today, and leave with hardware that matches whatever the latest software update expects.
Pair that with an over-the-air update on the software side and a dealer network that can explain why the visit is worth making, and a sensor choice locked in years ago stops setting the ceiling on what the car can do. That’s the same principle behind swappable batteries: designing the physical layer so the fast-changing parts can be replaced without touching the parts built to last.
Who owns what, and why it matters
Getting the architecture right is only the first step. Someone still must build it, maintain it, and keep it current, and that’s where ownership gets complicated. OEMs are simultaneously trying to pull more software capability in-house to protect margin and control the customer experience, while also needing new categories of partners for architecture, integration, and verification work that didn’t exist a decade ago. Those two instincts pull against each other unless ownership and expertise are mapped out clearly from the start. Tier-one suppliers face their own version of this shift, moving from selling components to shaping architecture decisions alongside the OEM.
What comes next
None of this gets solved by one team finishing its piece and passing it along to the next. The architecture group decides what the software team can build, the software team decides what the supplier relationships need to look like, and those supplier relationships determine how quickly any of it reaches the vehicle. Running those three conversations together, starting at the beginning of a program instead of after the architecture is already locked, gives a vehicle a real path to keep improving well past the day it leaves the factory.
