Sterling Anderson doesn’t think humanoid robots should be building cars

• Transportation
• Autonomous Cars
• Electric Cars

General Motors’ product chief breaks down the company’s software evolution, the physics of multisensor vehicle safety, and why personally owned autonomous vehicles beat robotaxis.

by Andrew J. HawkinsOct 27, 2026, 11:00 AM UTC

• Transportation
• Autonomous Cars
• Electric Cars

General Motors’ product chief breaks down the company’s software evolution, the physics of multisensor vehicle safety, and why personally owned autonomous vehicles beat robotaxis.

by Andrew J. HawkinsOct 27, 2026, 11:00 AM UTC Andrew J. Hawkins is transportation editor with 10+ years of experience who covers EVs, public transportation, and aviation. His work has appeared in The New York Daily News and City & State.

At a splashy event in New York City last week, General Motors unveiled its new tech roadmap centered on AI-driven vehicle development, advanced battery tech, high-powered car computers, and autonomous driving.

Some of this was old news: We already knew the automaker was developing hands-free, eyes-off driving automation and had been prototyping new battery chemistries. In a sense, the real purpose of the event was to showcase how all these pieces fit together. With its new “intelligence-defined vehicle” paradigm, GM is banking on artificial intelligence, centralized computing, and virtualized engineering to cut vehicle development timelines in half, aiming to compress a typical four- to five-year process down to just over two.

Yet, this high-tech overhaul arrives against a backdrop of steep industry headwinds and razor-thin margins for error. GM’s aggressive pivot comes as the automaker faces a wave of hyperefficient Chinese EV makers that are aggressively expanding globally. At the same time, softening EV demand in the US has forced GM to recalibrate its electrification hopes, balancing multibillion-dollar investments in next-generation battery plants with the ongoing costs of software development.

To be sure, for GM to bet its future on unproven software architectures and autonomous technology is a high-stakes gamble: If these complex AI systems falter or if development hits delays, GM risks burning through massive amounts of money while falling further behind agile rivals (like Tesla) that were built as software-first companies from day one.

After the event, I sat down with Sterling Anderson, GM’s chief product officer, to talk about the company’s risky new ventures as well as how he plans to steer a century-old Detroit giant through an increasingly fast, software-driven world.

This interview has been lightly edited for length and clarity.

So this was quite the massive announcement — just lots of disparate pieces. Is there a unifying theme here, would you say? And if so, what do you think it is?

The car’s getting smarter.

That’s it?

That’s it. I think so. Your vehicle is becoming a trusted, intelligent companion, and we’re doing that in a variety of ways. I think I might be one of the only guys who gets as excited as I do about what we’re doing in the development process and making that faster and better.

I don’t know how many people are going to come away with that takeaway in quite the spirit that I think it merits, but the level of tests and performance optimality that we can achieve when we can spin design decisions hundreds of times — that previously would have accommodated one — is huge. It’s really huge. I’ve been asked now by two folks I’ve met afterwards, “Hey, what about safety, and does speed come at the cost of safety?” The way we are getting speed is by virtualizing tests in a way that allows us to improve safety. Historically, I would have been able to afford X prototypes that I could send to crash tests, and it took me six months. Now, I kick off thousands of tests in the virtual world that give me feedback much quicker. So I get speed, and I get safety, better coverage, and better understanding. There’s a lot of cake being eaten, too, in this process.

What kind of AI models are you using? I know you talked about how data is sort of the currency here, so obviously there’s a lot that you’re pulling from your own customers, but there’s a range of products out there. What’s the dividing line between what to look for outside the company versus what to pull from inside?

It’s a good question. It depends on what we’re doing with it. In many cases, the transformer-based foundation models enable some of the generative design stuff I was talking about — we have enough data in-house based on decades of design files, analyses, etc., that we can get a pretty well-trained system to express our data well. But we have access to — and anybody has access in many cases to — a lot of data that informs us. The co-training of these models with data that exists beyond GM’s walls tends to make them better. So we do it with all of them.

You’ve talked about moving from deterministic code to probabilistic AI that learns from the structure of the world and from the data. How are you specifically embedding these models into the vehicles? How much is run locally versus pulling from the cloud?

For any safety-critical functionality, the inference is done onboard because we can’t deal with latency, possible dropouts, or whatever else. Some of these examples you saw from the team earlier today, like the OnStar AI interactions, aren’t safety-critical. You probably noticed, given the latency, that you had some round-tripping happening there because we don’t need to run those all onboard. Now, we’re thinking about distilling them down into onboard models just to deal with the latency, but that’s an on-the-edge user experience element, not a core safety consideration.

You talked a little bit during your presentation about how big GM is, which gives you advantages with data, but also a lot of inertia. Back in 2019, GM President Mark Reuss talked about moving toward the “digital brain” of the vehicle, and in 2021 you talked about Ultifi. Have things sped up now? Are you on the glide path at this point?

Yeah, and a big enabler of it is that common electrical system, including centralized compute. Historically, I know of very few killers to software speed quite like complexity. The moment a software team has a very large set of deployment targets that don’t share a common baseline is the moment you slow that team down enormously.

Rolling this out across our entire portfolio is specifically to enable software speed so we don’t have to continue to support vehicles of various configurations. As that hardware set rolls out, software engineers will suddenly be able to operate like they would if they were in a company with two models in production, which they just haven’t been able to in history.

GM is unique in having this huge portfolio of brands with distinct identities. How do you decide what to standardize across every vehicle versus ensuring a Buick remains a Buick and a GMC Sierra remains unique?

It’s a combination of things. First, the essence of each brand tends to manifest in aesthetics and interaction models. Aesthetics is something you can effectively skin via design, both in digital interfaces and physical sheet metal. We already do a fairly good job of commonizing the under-the-skin componentry because why wouldn’t we? For a given segment of vehicle, there’s a particular ride quality that tends to be best received by everybody.

<a href="https://gmauthority.com/blog/gm/gm-platforms/t1/" rel=

Source: www.theverge.com — article syndicated from the publisher’s feed; all rights remain with the original publisher.