State of Charge with Director of Cost Engineering Corey Steuben

[erigion]

I am not a Tesla fan. That said, I do give Tesla/Elon a lot of credit for making the EV industry real with what they've done, EV vehicles and the charging infrastructure. Looking forward, I am not sure Tesla will be innovating with same passion as the past two decades.

Maybe, maybe not.

A Premium Model Y AWD costs $48k and comes with features like adaptive headlights, acoustic glass for basically every panel, ventilated seats, and much cheaper insurance costs for owners. And, of course, supervised FSD. They haven't needed to really innovate as the US market sputters along.

The equivalent Rivian R2 Premium will be $54k. Luxury brands like Volvo, BMW, and Mercedes will make you pay to upgrade seats to get ventilation if they even offer it upon release (the iX3 and GLC EV won't), acoustic glass, and a bunch of other features, and none of the European carmakers can legally offer their adaptive headlights in the US. Speculation is that the mid-range specs for these new Euro midsize EVs will be around 60k.

Considering the much more powerful CPUs in the Cosmos/Earth when compared to everything else in this segment, I would be impressed if the Cosmos/Earth Premium (or whatever they call the fully loaded trim) comes in at the same price as the R2 Premium. Here's hoping they aren't exaggerating about their much lower BOM while also being feature equivalent to Tesla and Rivian.

 

[BS8899]

In the places Lucid has service, it will beat all other luxury EV's. You cant expect Lucid to outsale countrywide when they dont have that many service centers. Point to note- Lucid Air sales were double that of Tesla model S in the US in 2025.....

The Model S is a 13-year-old car/model in 2025!! It was a pioneer in its early days. Father Time ticks for Lucid as well as well as Tesla!

 

[BS8899]

Being in the business for many ears, powerful CPUs DON'T fix software bugs.

Maybe, maybe not.

A Premium Model Y AWD costs $48k and comes with features like adaptive headlights, acoustic glass for basically every panel, ventilated seats, and much cheaper insurance costs for owners. And, of course, supervised FSD. They haven't needed to really innovate as the US market sputters along.

The equivalent Rivian R2 Premium will be $54k. Luxury brands like Volvo, BMW, and Mercedes will make you pay to upgrade seats to get ventilation if they even offer it upon release (the iX3 and GLC EV won't), acoustic glass, and a bunch of other features, and none of the European carmakers can legally offer their adaptive headlights in the US. Speculation is that the mid-range specs for these new Euro midsize EVs will be around 60k.

Considering the much more powerful CPUs in the Cosmos/Earth when compared to everything else in this segment, I would be impressed if the Cosmos/Earth Premium (or whatever they call the fully loaded trim) comes in at the same price as the R2 Premium. Here's hoping they aren't exaggerating about their much lower BOM while also being feature equivalent to Tesla and Rivian.

Being in the HW/SW business for many years, powerful CPUs don't mitigate bugs. Lucid's SW capability is below par! Faster hardware won't fix anything!

 

[borski]

Being in the business for many ears, powerful CPUs DON'T fix software bugs.

Being in the HW/SW business for many years, powerful CPUs don't mitigate bugs. Lucid's SW capability is below par! Faster hardware won't fix anything!

No, but they may enable you to do more with fewer constraints. Sometimes, rather than optimizing memory usage, for example, the solution is 'buy more memory.'

No, not the same thing, but you get my point.

It is of course true that a bug will still be a bug, unless the bug is purely resource constraints (which is definitely not most or all of them). But that kind of issue can be solved either by adding more physical resources or through cleverness. Both can be equally valid.

 

[BS8899]

No, but they may enable you to do more with fewer constraints. Sometimes, rather than optimizing memory usage, for example, the solution is 'buy more memory.'

No, not the same thing, but you get my point.

It is of course true that a bug will still be a bug, unless the bug is purely resource constraints (which is definitely not most or all of them). But that kind of issue can be solved either by adding more physical resources or through cleverness. Both can be equally valid.

To me, a logic bug is a logic flaw. We are not talking about a "race condition" per se. When a bug is "resource constrained", it is a logic design flaw, the SW engineer is expected to understand and comprehend the speed and race conditions. Otherwise, they are just "logic philosophers". The explanation you offer is an excuse to rationalize. SW engineers have to have a basic understanding of the HW constraints.

 

[borski]

To me, a logic bug is a logic flaw. We are not talking about a "race condition" per se. When a bug is "resource constrained", it is a logic design flaw, the SW engineer is expected to understand and comprehend the speed and race conditions. Otherwise, they are just "logic philosophers". The explanation you offer is an excuse to rationalize. SW engineers have to have a basic understanding of the HW constraints.

A bug is a bug, period.

Some bugs have more dire consequences than others. Security is one example. But a vulnerability cannot exist without a bug, and thus a security vulnerability is also a bug.

"Logic flaws" are bugs.

Your post said "software bugs" and that's what I was responding to.

My explanation is not an 'excuse to rationalize.' SW engineers can absolutely have a "basic understanding of the HW constraints" and still build in bugs. These are not mutually exclusive.

But, more importantly, you missed my point: there are two ways to solve a bug that is the result of resource constraints. You could: 1) get more clever, or 2) add more resources.

It is fun to build something under significantly reduced resources / with significant constraints. But that doesn't inherently mean that sometimes the solution to resource constraints isn't simply to add more resources, aka 'throw money at the problem.'

But yes, it depends on the bug.

 

[BS8899]

In the places Lucid has service, it will beat all other luxury EV's. You cant expect Lucid to outsale countrywide when they dont have that many service centers. Point to note- Lucid Air sales were double that of Tesla model S in the US in 2025.....

I have two homes, one in Arizona, where I am about 6 miles from the Lucid Service Center. My other home is sin Sausalito, about 20+ miles from the Millbrae Service Center. I also own a Rivian R1S.

My experience.... I have great service from the Scottsdale Lucid Service Center. I usually just drive to the Scottsdale Service Center, talk to the advisors there, make an appointment when necessary, and I get my Lucid served. When I am in Sausalito, things get a bit more complicated. The Millbrae Service Center is 20+ miles away and Millbrae oven gets overwhelmed. The times I used it, they dispatch a mobile tech. The Mobile Tech I had was competent and good follow up.

With my Rivian, I can do simple service items (e.gg., tire rotation) at local shops (e.g., Discount Tires) at no cost. That's very convenient. Rivian also dispatches mobile techs to my home in AZ and CA for services. Also, very convenient.

So, FOR ME, both Lucid and Rivian services are adequate.

For Lucid to expand sales on their mid-range products, I think the existing service network might not be adequate. It might be their Archilles heel!

 

[BS8899]

A bug is a bug, period.

Some bugs have more dire consequences than others. Security is one example. But a vulnerability cannot exist without a bug, and thus a security vulnerability is also a bug.

"Logic flaws" are bugs.

Your post said "software bugs" and that's what I was responding to.

My explanation is not an 'excuse to rationalize.' SW engineers can absolutely have a "basic understanding of the HW constraints" and still build in bugs. These are not mutually exclusive.

But, more importantly, you missed my point: there are two ways to solve a bug that is the result of resource constraints. You could: 1) get more clever, or 2) add more resources.

It is fun to build something under significantly reduced resources / with significant constraints. But that doesn't inherently mean that sometimes the solution to resource constraints isn't simply to add more resources, aka 'throw money at the problem.'

But yes, it depends on the bug.

as a point of sanity check,

A few months ago, Lucid announced, Lucid announced an upgrade for a faster (HW) processor for the Air @ ~$950. How many were sold? How many "bugs" did it resolve?

Faster processors, with more and faster resources, might make things happen faster. As such, might give more alternatives to coding. But, I think you agree, faster HW do not resolve logic flaws and bugs, correct?! Many of the aberrations on my 2022 AGT are, I believe, logic and coding bugs. They don't/won't get resolved with faster hardware!

 

[tmichael]

Maybe, maybe not.

A Premium Model Y AWD costs $48k and comes with features like adaptive headlights, acoustic glass for basically every panel, ventilated seats, and much cheaper insurance costs for owners. And, of course, supervised FSD. They haven't needed to really innovate as the US market sputters along.

The equivalent Rivian R2 Premium will be $54k. Luxury brands like Volvo, BMW, and Mercedes will make you pay to upgrade seats to get ventilation if they even offer it upon release (the iX3 and GLC EV won't), acoustic glass, and a bunch of other features, and none of the European carmakers can legally offer their adaptive headlights in the US. Speculation is that the mid-range specs for these new Euro midsize EVs will be around 60k.

Considering the much more powerful CPUs in the Cosmos/Earth when compared to everything else in this segment, I would be impressed if the Cosmos/Earth Premium (or whatever they call the fully loaded trim) comes in at the same price as the R2 Premium. Here's hoping they aren't exaggerating about their much lower BOM while also being feature equivalent to Tesla and Rivian.

Pricing and feature equivalent are not the only reasons for buying a car. If so, Porsche and Audi wouldn't exist. I want the interior to be luxurious and stylish - something I can't give any credit to Tesla or Rivian. They are unimaginative, hard, scratchable surfaces - I'll go for creative, soft and curved surfaces all day long. It's subjective, to be sure - but if Midsize has the same attention to materials and design that Air and Gravity, many, many people will choose that. Macan is Lucid's target, not Model Y. I don't want to stop at a stop light and see 3 or 4 other people around me in the same car, with the same wheels. I like being different.

Just my opinion, not arguing!

 

[borski]

as a point of sanity check,

A few months ago, Lucid announced, Lucid announced an upgrade for a faster (HW) processor for the Air @ ~$950. How many were sold? How many "bugs" did it resolve?

Faster processors, with more and faster resources, might make things happen faster. As such, might give more alternatives to coding. But, I think you agree, faster HW do not resolve logic flaws and bugs, correct?! Many of the aberrations on my 2022 AGT are, I believe, logic and coding bugs. They don't/won't get resolved with faster hardware!

I didn't say it would resolve any, and certainly not all, bugs. I said it could. For example, I no longer notice any lag in my vehicle. I would argue lag was a bug, and it was resolved with the CCC upgrade. Also, v2 of the TCU resolved the need to semi-regularly reset the TCU, which was/is a regular problem on TCU v1. There was no 'software update' to do that, but rather a different piece of hardware.

So yes, upgraded hardware can resolve some bugs. I really don't understand why you seem to think this is a controversial statement.

And I have no idea how many CCC upgrade they've sold. I also do not think that statistic matters, as it is irrelevant to whether or not the concept holds.

 

[BS8899]

I didn't say it would resolve any, and certainly not all, bugs. I said it could. For example, I no longer notice any lag in my vehicle. I would argue lag was a bug, and it was resolved with the CCC upgrade. Also, v2 of the TCU resolved the need to semi-regularly reset the TCU, which was/is a regular problem on TCU v1. There was no 'software update' to do that, but rather a different piece of hardware.

So yes, upgraded hardware can resolve some bugs. I really don't understand why you seem to think this is a controversial statement.

And I have no idea how many CCC upgrade they've sold. I also do not think that statistic matters, as it is irrelevant to whether or not the concept holds.

I am certainly not an authority on what is a bug. Perhaps the link blow from Google AI helps to put things in perspective. The practice of relying on a faster computer (HW) to mask (SW) bugs is, in my opinion, a dangerous practice.

Google Search

 

[borski]

I am certainly not an authority on what is a bug. Perhaps the link blow from Google AI helps to put things in perspective. The practice of relying on a faster computer (HW) to mask (SW) bugs is, in my opinion, a dangerous practice.

Google Search

“Here, I googled it” is not a useful argument, fwiw.

But even if it were, your own link disagrees with you:

“Yes, if a program crashes on a slow computer but runs on a fast computer, it is
almost certainly buggy.
…
While slow hardware can exacerbate performance issues, a properly designed application should handle resource limitations gracefully—such as by slowing down or showing a loading spinner—rather than crashing. A crash on slower hardware usually indicates a failure to manage timing, memory, or resource contention properly.”

We were not discussing hardware crashes. I provided the example of the interface being laggy. Your own google search, along with its helpful “AI summary” states that rather than crashing, a properly designed application would slow down.

That is what lag is. Slowing down. Not crashing. Due to resource constraints. Which can be resolved, at least in part, by increasing resources so they are less constrained.

Again, I do not understand as none of what I am saying is controversial. I am mostly just defining words with what their definitions are.

 

[socktucker]

I do want to note that since Lucid is a new brand relative to the traditional auto companies, I'm not sure what other considerations actuaries and underwriters add when dealing with such a scenario.

We had been rating them like a model S or Y

…that’s going to change. Lucid repair costs are ureasonable and frequently months of downtime. From an insurance point of view, Lucid repairs are a money pit. I would expect rates to go way up, and some major carriers to just not insure them at all.

 

[BS8899]

“Here, I googled it” is not a useful argument, fwiw.

But even if it were, your own link disagrees with you:

“Yes, if a program crashes on a slow computer but runs on a fast computer, it is
almost certainly buggy.
…
While slow hardware can exacerbate performance issues, a properly designed application should handle resource limitations gracefully—such as by slowing down or showing a loading spinner—rather than crashing. A crash on slower hardware usually indicates a failure to manage timing, memory, or resource contention properly.”

We were not discussing hardware crashes. I provided the example of the interface being laggy. Your own google search, along with its helpful “AI summary” states that rather than crashing, a properly designed application would slow down.

That is what lag is. Slowing down. Not crashing. Due to resource constraints. Which can be resolved, at least in part, by increasing resources so they are less constrained.

Again, I do not understand as none of what I am saying is controversial. I am mostly just defining words with what their definitions are.

Well, you said (quoting you) " I would argue lag was a bug". But then you argue time-lag is not really a (logic) bug. I agree it depends. For example, if my door handles present themselves 1/2sec later with a slow computer, "perhaps" that's not a bug per se, just slow!.

In contrast (actual experience) if I use Lucid's native navigation, and missed a turn, by the time the time the navigation re-routes me and refreshes the screen, I'd already missed the re-routed turns. Is that a bug? To me, it is....because the SW/HW did not perform a time-sensitive, mission critical event in a timely manner. It is like a watch that has all the digits and/or hands but persistently has a multi second lag in telling the right time. Is that a bug or not?

If the time-lag, which you might/might not call a bug, is on DD-Pro/Self-drive! It can perform all the functions, so long as you drive less than 30mph! Is that useful? Did it meet the design objectives?

As you well know, faster computers might solve/mask some timing problems. But the coding algorithm that does not safe-guard the time-sensitive events are, in my mind, logic bugs.

 

[valentino]

I am certainly not an authority on what is a bug. Perhaps the link blow from Google AI helps to put things in perspective. The practice of relying on a faster computer (HW) to mask (SW) bugs is, in my opinion, a dangerous practice.

Google Search

I don't agree. Slower processor can absolutely introduce bugs. Modern computers no longer function like the 80s and 90s where you Do task A. Task A is finish now do Task B. Today its more like start tasks A and B simultaneously.
If then you also have a task C that is dependent on A and B being completed and your processor was overwhelmed and couldn't finish B and since it's overwhelmed, cannot tell task C that B is still ongoing your code will crash. You may encounter this 1 in 10,000 operations which is why sometimes you perceive a bug and sometimes you don't vs that bug always happens if you do xyz. But a faster something like processor, memory etc can ensure that never happens. It's one reason why companies like Samsung, Google, Apple refuses to provide support to very old phones. Newer code are too intensive for older processors. One reason besides marketing your seeing "pcs designed for AI".

 

[borski]

But then you argue time-lag is not really a (logic) bug.

I never said this. I said it wasn’t *crashing* due to lack of resources, and that the lag could be resolved by adding more resources, effectively resolving the buggy lag.

If it were crashing, that would be a much worse bug.

Lag is not a logic bug, but not all bugs are logic bugs.

I agree it depends. For example, if my door handles present themselves 1/2sec later with a slow computer, "perhaps" that's not a bug per se, just slow!.

Something can be both a bug and slow. And something can be slow and not a bug. And something can be a bug and fast.

Speed is orthogonal, but relevant.

In contrast (actual experience) if I use Lucid's native navigation, and missed a turn, by the time the time the navigation re-routes me and refreshes the screen, I'd already missed the re-routed turns. Is that a bug?

Could be. Could also be you lacked good cell service. Is that a bug? Or is that circumstantial?

To me, it is....because the SW/HW did not perform a time-sensitive, mission critical event in a timely manner. It is like a watch that has all the digits and/or hands but persistently has a multi second lag in telling the right time. Is that a bug or not?

You are attempting, it seems, to be pedantic, and missing my point.

If the time-lag, which you might/might not call a bug, is on DD-Pro/Self-drive! It can perform all the functions, so long as you drive less than 30mph! Is that useful? Did it meet the design objectives?

You made this up, and it is a strawman.

As you well know, faster computers might solve/mask some timing problems. But the coding algorithm that does not safe-guard the time-sensitive events are, in my mind, logic bugs.

Okay. I would recommend reading what I wrote with fresh eyes because you misunderstood me, but that’s up to you, and I’m going to agree to disagree.

 

[ke2]

To me, a logic bug is a logic flaw. We are not talking about a "race condition" per se. When a bug is "resource constrained", it is a logic design flaw, the SW engineer is expected to understand and comprehend the speed and race conditions. Otherwise, they are just "logic philosophers". The explanation you offer is an excuse to rationalize. SW engineers have to have a basic understanding of the HW constraints.

I'd say your assumption of SW engineers having a basic understanding of HW constraints is frequently not true and the mantra of "get a bigger "Blah" " is frequently the answer (or the SW engineer stares at you blankly when you tell them they've run out of resources)

 

[BS8899]

I'd say your assumption of SW engineers having a basic understanding of HW constraints is frequently not true and the mantra of "get a bigger "Blah" " is frequently the answer (or the SW engineer stares at you blankly when you tell them they've run out of resources)

Sad, but true!

 

[borski]

I'd say your assumption of SW engineers having a basic understanding of HW constraints is frequently not true and the mantra of "get a bigger "Blah" " is frequently the answer (or the SW engineer stares at you blankly when you tell them they've run out of resources)

This, right here, was my point. This isn't my preferred solution, but that doesn't make it not a solution.

Sometimes, it's about priorities. When you have a thousand things to do, sometimes "get a bigger 'blah'" is the right solution, especially in the short-term.

 

[Need4Sleep]

I'd say your assumption of SW engineers having a basic understanding of HW constraints is frequently not true and the mantra of "get a bigger "Blah" " is frequently the answer (or the SW engineer stares at you blankly when you tell them they've run out of resources)

Yeah, one great example of this is OpenAI. Previously, they found that by simply throwing more resources at the problem allowed them to improve ChatGPT, then came GPT-5, which didn't give back improvements despite getting so much more. I could go into deep lengths as to why, but long story short, it's the inherent problem with the architecture that they've hit such a point of diminishing returns.

Bringing it back towards automotive, you can only use "throw more things at it" for so long before you've hit a wall