Anders Bell points to his grey hair and laughs. “Three years ago, it was still blond and curly,” says Volvo’s chief engineering and technology officer. The remark is more than self-deprecating. It captures what Volvo has been through: five years of building a software-defined vehicle (SDV) from scratch, as a traditional carmaker, with no blueprint to follow and no supplier to call for the hard parts.
The EX60 (pictured above) is a mid-size all-electric SUV, unveiled in Stockholm in January 2026 and built on SPA3, Volvo’s new electric vehicle architecture. In April, the first customer production car rolled off the line at the Torslanda plant in Gothenburg. It is the first built entirely on HuginCore, the company’s own computing platform.
S&P Global Mobility rates Volvo at Level 5, the highest category of software-defined vehicle capability, and it is the only manufacturer in the world to reach that level. Bell describes the journey with a vivid metaphor: “Take a piece of charcoal, pressure test it enough until it becomes a diamond. Now we are polishing the diamond.”
At the heart of HuginCore is a single software master: one codebase, configured per vehicle, shared across every model on the platform. A developer working on a door locking function does not release code to the EX60. The code goes to the master. From there, it is configured for every car.
The EX60 is the third Volvo to run on that master, following the EX90 and ES90. Each one hardened the codebase further. “This is basically what Apple does. This is what Microsoft does. If you want to be great at software, you should only have one.”
Hard lessons learned from real-world customer experience
The EX90, the first car on the platform, had a rough introduction. Problems that automated testing had not caught emerged in the real world, and customers experienced them directly. “It’s been a hard and painful journey,” Bell says. “I don’t mind if it’s hard and painful inside the company. It’s very unfortunate when it spills over to customers.”
Developing its own computing platform also changed how Volvo works with suppliers. Traditional tier-one suppliers deliver complete electronic control units (ECUs), hardware and software as a single package. With HuginCore, Volvo developed its own zone controllers and integrates supplier software itself.
“We don’t just take an ECU from Bosch that is ready,” says Bell. “We have to work with them, integrate their software on our zone controllers, so their system works and integrates through the car.”
“I would never dare to press the button on 2.2 million cars and just go. A failed update that can simply be retried: fine. An update that means you can no longer start the car: catastrophic”
Anders Bell, Volvo
That shift gives Volvo control over the integration layer, and that control has consequences that run deeper than architecture diagrams suggest.
Bell illustrates it with a concrete example. At extreme cold, around -25°C, the battery needs protection from freezing. The standard solution is a separate electric heater costing around €150. Volvo asked a different question: could the electric motor produce heat intentionally, by running slightly less efficiently in extreme cold?
The answer was yes. The separate heater was eliminated. “We calculated that for €8 of additional components in the motor, we could remove a €150 part elsewhere,” says Bell.
That kind of cross-system optimisation only becomes possible when different engineering disciplines sit at the same table and treat the vehicle as one integrated system rather than a collection of separate modules. In the old organisational structure, Bell says, that conversation would never have happened.
Product releases must be nothing less than awesome
The practical reach of the single software master becomes clear in deployment. Volvo is currently rolling out a one human-machine interface update to 2.2 million cars built as far back as 2020, bringing a standardised interface and Google Gemini conversational AI to vehicles that left the factory before large language models (LLMs) existed.
“We had no idea in 2020 when we built those cars that we would, in 2026, roll out conversational AI on the same car, on the same hardware,” says Bell. “We didn’t know what an LLM was in 2020.”
A software-defined product is never finished. There is always more to integrate, more functionality to add. But there is a moment when you decide it is good enough to release. Bell’s criterion is pragmatic: “When you launch it, it must be freaking awesome.” And at that moment, it is.
But development continues, and what feels groundbreaking today will feel dated in five years. That, Bell argues, is not a problem. It is the point. The goal is not just to satisfy customers at the moment of purchase, but to keep surprising them afterwards. The conversational AI now rolling out to cars built in 2020 is exactly that.
The engineering behind those deployments is equally instructive. Volvo builds 20 complete software versions per day. Every four hours, the best candidate goes through full automated vehicle testing on rigs, around the clock. Customers receive one meaningful release per quarter.
The required success rate across 2.2 million vehicles is 99.9% or better. Bell is precise about what that means: 0.1% of 2.2 million is still more than two thousand cars.
“I would never dare to press the button on 2.2 million cars and just go,” he says. Bell does not watch the 99.9%. He watches the 0.1%. And even within that fraction, there is a hard distinction. “A failed update that can simply be retried: fine. An update that means you can no longer start the car: catastrophic.”
When monitoring data shows failures clustering around a specific market or vehicle variant, the roll-out stops for that group while the rest continue. The problem is fixed before that segment receives the update. Every deployment, Bell says, is a precision operation. And precision, at this scale, requires people who understand exactly what they are building.
Automotive coding skills hard to come by
The talent problem is structural, and Bell does not soften it. “Automotive software engineering that we do now is basically a five-year-old discipline at scale. Everybody’s looking to hire leaders in software-defined vehicles. Well, there aren’t any.”
That is not a complaint about the labour market. It is a description of a discipline that barely exists yet. Writing safety-critical code for a two-and-a-half-tonne vehicle under ISO 26262 functional safety standards is not the same as building consumer applications.
The context is different, the constraints are different, and the consequences of getting it wrong are different. “It’s not just like hiring software people into a car company. It’s not about knowing how to code. It’s about coding in the automotive context.”
Volvo built that context itself. The toolchain, the testing infrastructure, the repository structure, the process for configuring one codebase across eight silicon generations and four factories: none of it came off the shelf. “There was absolutely nothing when we started,” Bell says. “There’s no tier one that you can call and buy a solution. We had to create all of it ourselves.”
This explains the level of internal investment that most organisations would struggle to justify. Volvo’s software test centre in Gothenburg covers 25,000 square metres and cost around €26m. And even then, Bell’s most important lesson from the past five years is simply this: “Start earlier. Do not underestimate how big this job is.”
HuginCore is the centrepiece of that investment, but it does not make Volvo independent. The platform runs on Nvidia’s Drive AGX Orin system-on-chip and Qualcomm’s Snapdragon Cockpit Platform, and integrates Google for AI.
Bell acknowledges the tension without pretending it away. “It’s never comfortable being dependent.” Long-term agreements and contingency planning are the answer, not vertical integration all the way down. “Technology evolves, and we will evolve with the technology.”
The harder question is where to draw the line between proprietary and shared. Bell believes the lower layers of the stack, cyber security, update management and base infrastructure, will eventually become commodities.
“Do you need to do everything yourself, or do you buy larger chunks of it and share that investment across several car makers? I think that would make sense,” he says. That question has not been settled in automotive, and it is not settled in enterprise IT either.
Focus on project pace and preparation
For technology leaders outside the automotive sector, Bell’s core lesson is not technical. It is about pace and preparation. “Breathe deep before you go in. Don’t try to do too much too quickly. Don’t put your project on an aggressive timeline for job one. Do the fundamental proof of concept before you commit to the product plan.”
He also points to organisational size as a factor that is rarely discussed honestly. Volvo is, in Bell’s description, probably the smallest independent car development operation in the Western world. “We’re big enough to understand the scaling you need. But we’re small enough not to be institutional, not to get stuck in committees.”
That balance is difficult to replicate, but the underlying principle applies in any organisation where software transformation has to happen at speed, under hard constraints, with consequences that extend beyond the screen.
In financial services, healthcare and critical infrastructure, the discipline is the same. “We can’t look at anybody and say, ‘Hey, we should do that’,” Bell says. “We need to follow our own path and walk the path that nobody walked on before.”
The diamond is not finished, but it is being polished.
