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

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. 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.

Our T1-2 platform for our next-generation trucks is common between brands. Where you’ll see us differentiate is in the feature set, the aesthetics, and interaction patterns we effectively skin segment by segment. Sales has dedicated brand channels, but engineering is all one organization. That ensures we don’t ship heterogeneous, suboptimal cars for different brands just because a team that was slightly worse was assigned to one brand or another. I want our engineering team focusing all of their effort on what is the absolute best suspension, powertrain, or drive unit, and then we scale it across the portfolio.

Speaking of autonomy, we have autonomous vehicles on the road today — Waymo, Zoox, and Tesla Cybercabs. What are the challenges GM still needs to solve to get to a point where someone can take their eyes off the road comfortably and safely?

When you say “eyes off,” you mean autonomous?

Autonomously, yes. Hands off, mind off, eyes off. But at the same time, you wouldn’t be recommending people go to sleep in their vehicles yet?

We are designing them such that should they fall asleep, it won’t be unsafe, because we don’t have the luxury of ensuring that they’re paying attention. The reason you won’t hear me use terms like “eyes off” is because I hear people use those terms in reference to nonsensical levels of automation. What do you think your mind is doing when your eyes are on your phone? Where’s your mind? Let’s not draw these nonsensical distinctions. If you believe that your driver assistance system is super capable, you are already at risk of complacency — at risk of treating it like it’s an autonomous system. Our philosophy is: If we’re going to design an autonomous system, we’re going to actually design an autonomous system. The path of incrementalism that we’ll take will work for personal ownership, not the one that worked for robotaxis. Instead of regionally specific, speed-limited settings, we’re going to go toward road-type specific settings and expand outward from there. They both converge in the same place — self-driving everywhere at all times — but take different paths to get there.

With robotaxis today, we see problems around nuisance situations — like blocking intersections or emergency vehicles. Do you feel personal autonomy, as GM defines it, solves some of that because the driver remains an option to fall back on?

The form of the fallback matters. We will not fall back in a safety-critical dynamic situation. It’s just not reasonable to do that. What we can do in a non-safety-critical situation — where the vehicle is stopped and something odd is happening — is hand it back to the driver once we’ve reached a safe place. Having a human in the loop is very useful for that.

How do you structure that handoff to avoid driver complacency?

We’re not handing back dynamically. This is not an exchange of “you drive, now I’ll drive, oops, I don’t recognize this.” This is not Level 3. In the same way you put a robotaxi in a bounded region, we will put personally owned autonomous vehicles on a particular road.

When on that road, we will take the human to their destination and give a graceful countdown — like, “Hey, you’ve got 10 minutes left in this ride.” If they take over preemptively, great. Should they not take over, the system brings the vehicle to a safe state off the off-ramp and says, “I told you 10 minutes ago to take over. We’re stopped, and I’m not going any further.”

You have to operate under the assumption that bad actors will try to abuse the system — sitting in the back seat, like we’ve seen with Tesla users.

I get far more nervous when misuse happens in the context of a driver-assist system that wasn’t designed to handle every situation. If the vehicle accepts control, our system is designed to deal with more situations that can be thrown at it in that circumstance. So my anxiety level declines dramatically.

Features like OnStar AI ask for access to calendars, emails, and personal data. Given past FTC orders regarding GM selling customer data to third-party brokers without permission, how do you ensure customers can trust you with this data?

Privacy has to be designed in. With end-to-end encryption, we don’t see your data; you grant permission to an assistant that performs better with context. Data is only available to us at an aggregate, anonymized level. At an individual level, it is encrypted and under your control.

When you buy a car, going through dozens of terms and conditions leads to “click, click, click” without reading, which does a disservice to trust. We have dramatically simplified these authorizations down to a couple of clear choices that explain why the car needs data — like reading your calendar for smart routing. You can revoke permission, delete your data, or port it out at any time. You alluded to trust, which is foundational. Decisions made in the past by people who no longer work for this company have an overhang, but that’s not the company we are today. We earn that trust back by designing the architecture so that even if someone made a bad decision internally, the system technically wouldn’t allow them to access raw user data.

And the way we do that is by designing it. Look, even if we had someone stupid work for us again and do something like this, they couldn’t. They wouldn’t be able to access it.

AI is cutting vehicle development times, but we’re also seeing hype around factory automation and humanoid robots from companies like Tesla and Rivian. Is GM heading in that direction?

If you want to be perceived as a robotics player these days, it seems you have to have a humanoid robot that does backflips. It’s weird. Advocacy for humanoids often comes from people who historically advocate for first-principles engineering, but humanoids are not born from first principles. They put form over function. The logic assumes the human form factor is optimal for a factory floor, but this form factor evolved to run away from lions on the African savanna! Production environments weren’t built for human forms any more than roads built for horses meant cars should have four legs. The most valuable real estate in a factory is the floor. Having bumbling humanoid robots clamoring in and out of vehicles is not where you start. You start with form factors that look alien — like an octopus hanging from a gantry that reaches into a moving vehicle line. We’re ignoring the “religion” of humanoids and focusing on underlying AI intelligence that can operate various specialized robot form factors for specific tasks.

Is GM building these robotics systems itself?

We already are. We actively work with heavy machinery suppliers like Fanuc, but we are actively developing many of our own solutions.

People are excited about cars getting smarter, but they also want them to be cheaper. How do these announcements lead to more affordable options?

LMR (lithium manganese rich) battery chemistry is a huge part of this. It delivers a range close to high-nickel packs at a cost closer to LFP. On a per-range basis, a customer will be able to buy a fourth-gen GM EV for less money than a competitor’s profitable model without relying on subsidies.

Additionally, commonizing our electrical architecture reduces wiring length and vehicle mass dramatically, making cars inherently more affordable. Virtualizing development cuts prototype costs, allowing vehicle business cases to clear at lower retail prices. This applies to ICE vehicles and hybrids as well, not just EVs.

Will this intelligence lead to higher subscriptions and paywalls?

Capability advances inevitably over time without raising financial costs — the device in your lap does far more than computers years ago for less money. Regarding subscriptions: I’m here to build great products. If customers like paying for services like a lease, let them; if not, don’t force them.

[GM spokesperson Chaiti Sen: For immediate features like OnStar AI, it will be included in our basic package. We aren’t going to paywall core baseline experiences or hand customers a bare “tin shell.”]

For your sensor suite, you’re using cameras, radar, and lidar. Do you see that remaining in perpetuity, or could you eventually scale back to a vision-only approach like Tesla?

If you scale back to vision-only, physics suggests you’ll be in trouble in certain situations. Radar is so cheap that dropping it doesn’t make sense — dropping it is a weird religious stance that ignores physics. Lidar operates on a similar wavelength to visible light and helps co-train camera systems to get better faster. Cameras can’t see through dense fog or measure instantaneous velocity like radar can. Having a multisensor suite provides obvious safety advantages that physics simply demands.