Motor trend Lucid Gravity review with Kyle Conner

The state of software on the Gravity at this moment is a let down, like it had multiple problems in the hour I spent with mine setting it up, but the rest of the car is absolutely kick ass and I’m still excited about mine even though I won’t actually get it till later this week. Even though I’m mad at Lucid for totally blowing it on the fob/keycard thing so far and sketchy out of the gate reliability, I know they are very motivated and care about doing a great job so I’m fine being in the fray with them and I’ll live with it since the potential is there and 100% of the people who work for them are smart, enthusiastic, fast and highly capable. And this isn’t the EX90 debacle, so I’m not worried, but yeah they don’t need us to tell them there shouldn’t be this level of software wackiness which then ends up in the hands of reviewers.
 
Today's experience was less than ideal.

Car detected the fob, screens were on, but we could not hear any sound from Spotify / tidal / radio / audible alarms inside etc. I had to manually reboot while the family was in the car - kids literally said "this car sucks". Spouse said this car is too complicated (coming from a TM3).

This is getting too personal for me very quickly - we bought this car with the sole purpose of driving around with family and long trips, so Every little bug matters, and there just seem to be too many stupid ones that make the start of every drive miserable. We have gone from the "Oohs" and "Aaahs" to "do we need a reboot" within 48 hours.

Heart Breaking. (for me) 💔

Love the car but hate getting a TON of glitches when it matters. Made me stop and revaluate my decision to get this car for a second. We are coming from a much smaller "computer on wheels" where stuff worked, albeit ride quality sucked. But it worked like 99.999% of the time. Sincerely hoping Lucid delivers a better experience... like yesterday. For the moment, we may have to go back to the Model 3 for long rides just so there is less bitterness during the ride.

Perhaps we can all do a bake sale and raise money to hire better software / auto OS engineers or something.
 
Sorry but I am going to use the word everyone hates for people to use, but some people need to get off their “Fanboy” high horse and accept criticism from a very knowledgable reviewer. First, Kyle is a HUGE Lucid fan and in the end acknowledged that Gravity was his favorite EV SUV of the various choices they discussed. But he gave a very frank opinion of the current state of Gravity’s software development. It SUCKS and needs improvement. Fortunately faulty software is fixable. Faulty hardware is much harder to fix. I am confident that it will get fixed, but it will require patience from the early adopters. I am OK with going through these growing pains but I have a feeling it will be 6+ months before I will feel comfortable sending my wife off on a road trip by herself.
Yep, agree, Software software software……..this is what will make Lucid survive……they need to expedite fixes and make it a number one priority. Also , standardize software among all models- Air, Gravity, midsize….such a big waste of resources having different build for Air and Gravity
 
Today's experience was less than ideal.

Car detected the fob, screens were on, but we could not hear any sound from Spotify / tidal / radio / audible alarms inside etc. I had to manually reboot while the family was in the car - kids literally said "this car sucks". Spouse said this car is too complicated (coming from a TM3).

This is getting too personal for me very quickly - we bought this car with the sole purpose of driving around with family and long trips, so Every little bug matters, and there just seem to be too many stupid ones that make the start of every drive miserable. We have gone from the "Oohs" and "Aaahs" to "do we need a reboot" within 48 hours.

Heart Breaking. (for me) 💔

Love the car but hate getting a TON of glitches when it matters. Made me stop and revaluate my decision to get this car for a second. We are coming from a much smaller "computer on wheels" where stuff worked, albeit ride quality sucked. But it worked like 99.999% of the time. Sincerely hoping Lucid delivers a better experience... like yesterday. For the moment, we may have to go back to the Model 3 for long rides just so there is less bitterness during the ride.

Perhaps we can all do a bake sale and raise money to hire better software / auto OS engineers or something.
I would rather live with the software glitches than take a model 3 on a long trip. Gravity ride is that good. I mean, what’s a little glitch here or there vs all the road noise, cramp interiors and poor ride of a model 3.
 
I really like Kyle. I’ve learned a lot from his videos. He may act like he knows everything sometimes, but I would certainly consider him an expert because he knows and has seen first hand A LOT!

You have to look past his predilections for Rivians. 🙄
 
Totally agree. Exactly the point that I was trying to make in my post above that got me scolded by Borski. People on this forum have been raving about Kyle’s reviews of the Gravity for the past 9+ months, but have him come up with one critique and he is suddenly a pompous know it all. I guess since you are a Gravity owner and I am still waiting patiently for mine, you can get away with critiques of the software and I can’t. So going forward I will keep all opinions of software to myself until I have my car. Hoping that by that time software is sorted out and my only comment is to apologize for my misguided opinions.
Good lord. Did you read what I wrote? I did not “scold” you for having an opinion.

I asked you to state your opinions without using terms like fanboi because they do not add to the conversation and detract from it instead. I do not know how I can make that more clear. It is unnecessary name-calling. That’s all.

Your opinions are fine and valid and you can state them until your fingers go numb lol. I literally ended with:

It just means you disagree. So just say you disagree.

Please, feel free to disagree. @HC_79 does. If he started calling people names, I’d ask him to stop too. It has nothing to do with your opinion, and everything to do with how you state it.

I hope that is clear, but please feel free to ask questions if you disagree or I am still not being clear.
 
Last edited:
I've been writing software for 45 years. In complex, interconnected systems you are going to have bugs. Often when fixing 10 bugs, it's not uncommon to introduce or uncover another.

As reports come in, you log them and prioritize them. Triaging bugs is a lot like medical triage in a busy ER. More serious bugs are going to get the focus. A bug that seems simple to the end user may be not so simple to fix.

I don't have any inside info on Lucid's software development team, but I can assure they are not loafing.
Also , standardize software among all models- Air, Gravity, midsize….such a big waste of resources having different build for Air and Gravity

Some things could be used across the models. But do you really want Mid-size being powered by the same systems as a 2022 Air?

Even bringing UX3.0 to air is a task that requires a lot of work.
 
Being an Air owner, with a few exceptions they made the Air software pretty stable and it’s rare I have an issue, so I’m not worried about the Gravity, it should get fixed quicker than Air issues. I’ve been in a Pure 2025 loaner since last Tuesday and have had not a single glitch in the car, everything works as advertised. So they’ll get there with the Gravity, it’s just irritating it’s not more stable given the 10 months the car has been on the road.
 
Just saw this pop up. Such a good, real review of the gravity with what really matters to consumers.

Motor trend Lucid Gravity Review
(Starts at 43 mins).

I sincerely hope Lucid Significantly prioritizes focus on the software. This is exactly what will make them successful.

Lucid is a car with software, versus Tesla- a computer on wheels.

Did they hit something at 1:19:19? It sure sounded like it. I'd hope that isn't a sound the car itself can make!
 
Did they hit something at 1:19:19? It sure sounded like it. I'd hope that isn't a sound the car itself can make!
They immediately switched to talking about “testing the car” etc. - speculating - definitely seems there was some external bump / impact.

These testing and loaner cars are taking a beating. Non stop launch modes, non stop bumping and scraping. The detailing, body repair shop and drivetrain engineers must be working overtime. 😊 good problem to have when it’s a popular product.
 
Being an Air owner, with a few exceptions they made the Air software pretty stable and it’s rare I have an issue, so I’m not worried about the Gravity, it should get fixed quicker than Air issues. I’ve been in a Pure 2025 loaner since last Tuesday and have had not a single glitch in the car, everything works as advertised. So they’ll get there with the Gravity, it’s just irritating it’s not more stable given the 10 months the car has been on the road.
Perhaps one way of thinking about this is - if someone upgraded from windows 7 to windows 10, should the same software issues that were found and fixed in windows 7, still exist in the new version?

And it’s really not just that. The pace of fixing them has also decreased and random new bugs have been added.

Does not “bring me joy”.
 
Just a note on this back and forth with software. At a high level, I believe people highly underestimate the effort and complexity of the Lucid's system. There are a lot of demands and juggling priorities being asked of the same "computer". As someone who expected to launch a database to market, built from the ground-up, 9 months ago vs still ironing out issues today, let me assure you the number of hidden gremlins, last minute architecture reworks due to bugs, and architecture cleanup due to performance requirements can and are unexpected and time consuming in these types of systems.

As an engineer observing from the outside Lucid's software, I suspect the following:

- Multithreading Is being used. This is one of, if not the single hardest piece to get correct. All those things you expect the car to do have to be coordinated and synchronized safely in the sheer chaos of any and/or all of them trying to do it at the exact same time. Fixing one bug, or even worse undefined behavior, often reveals a whole new set of bugs from previous incorrect assumptions.

- Event driven architecture. A system, including user interaction, gets triggered in one part of the code to be queued and processed in a completely different part of the code. This is the defacto design for most UI/UX systems with heavy backend processing (eg. audio, dream drive, hardware sensors, Lucid Assistant, etc.). Complex and hard to replicate as you have several things firing essentially random with random timings (eg. hard to consistently pinpoint and replicate the source of a bug).

- 3 known complete rewrites. Major versions of 1 and 2 for the Air. 3 for the Gravity. All of these rewrites take a ton of time of "stalling out" in the hopes, not guarantee, of addressing technical issues, bugs, and features not currently possible. This often means all new code that needs all new testing and equally long periods to find and iron out the "wrinkles" aka bugs.

- Technical Direction and Prioritization. Lucid has cycled through a number of "captains" directing the efforts and even associated "crews" for the software development. An organization must prioritize performance and long-term sustainability while equally compensating and rewarding employees to do so. Given the churn and overall focus on the driving experience (eg. the physical experience), I suspect a ton of resources have been allocated and prioritized to the in-house traction control systems and other hardware systems. The focus on long-term sustainability and performance of the user facing software only a more recent focus (post mad dash to get Gravity and UI/UX 3.0 out the door). Meaning all the sub-optimal decisions will plague the current software until addressed costing time and resources at some factor larger than "just doing it right" the first time.

While I would hope Lucid would have highly talented software engineers designing the best system from the get go, the entire industry has been plagued with indoctrination of Object Oriented Programming. This has led to abstraction hellscapes in code, bloated code, highly tangled and coupled monstrosities unable to be properly tested except with mock testing (eg. not real tests), and ultimately code that is not performant. We see this in the requirements for faster hardware nearly every year to make our phones feel "snappy" again. Old computers unable to use modern OS systems for Web browsing, watching videos, and document based work.

All of this to say that these same practices are almost certainly present in Lucid's codebase despite best intentions because that is the indoctrinated practices with excellent engineers who know nothing better (and every manufacturer's codebase including Tesla who required hardware upgrades for software updates due to bloat).

If you can't live with the current bugs for some period of time, get a different car whose bugs you can deal with for an extended period of time. If software is that important, prioritize a legacy manufacturer who is unlikely to update or address bugs in their cars because that means stable and known bugs vs. potentially having bugs fixed + new features for the trade-off of potentially new bugs.
 
Just a note on this back and forth with software. At a high level, I believe people highly underestimate the effort and complexity of the Lucid's system. There are a lot of demands and juggling priorities being asked of the same "computer". As someone who expected to launch a database to market, built from the ground-up, 9 months ago vs still ironing out issues today, let me assure you the number of hidden gremlins, last minute architecture reworks due to bugs, and architecture cleanup due to performance requirements can and are unexpected and time consuming in these types of systems.

As an engineer observing from the outside Lucid's software, I suspect the following:

- Multithreading Is being used. This is one of, if not the single hardest piece to get correct. All those things you expect the car to do have to be coordinated and synchronized safely in the sheer chaos of any and/or all of them trying to do it at the exact same time. Fixing one bug, or even worse undefined behavior, often reveals a whole new set of bugs from previous incorrect assumptions.

- Event driven architecture. A system, including user interaction, gets triggered in one part of the code to be queued and processed in a completely different part of the code. This is the defacto design for most UI/UX systems with heavy backend processing (eg. audio, dream drive, hardware sensors, Lucid Assistant, etc.). Complex and hard to replicate as you have several things firing essentially random with random timings (eg. hard to consistently pinpoint and replicate the source of a bug).

- 3 known complete rewrites. Major versions of 1 and 2 for the Air. 3 for the Gravity. All of these rewrites take a ton of time of "stalling out" in the hopes, not guarantee, of addressing technical issues, bugs, and features not currently possible. This often means all new code that needs all new testing and equally long periods to find and iron out the "wrinkles" aka bugs.

- Technical Direction and Prioritization. Lucid has cycled through a number of "captains" directing the efforts and even associated "crews" for the software development. An organization must prioritize performance and long-term sustainability while equally compensating and rewarding employees to do so. Given the churn and overall focus on the driving experience (eg. the physical experience), I suspect a ton of resources have been allocated and prioritized to the in-house traction control systems and other hardware systems. The focus on long-term sustainability and performance of the user facing software only a more recent focus (post mad dash to get Gravity and UI/UX 3.0 out the door). Meaning all the sub-optimal decisions will plague the current software until addressed costing time and resources at some factor larger than "just doing it right" the first time.

While I would hope Lucid would have highly talented software engineers designing the best system from the get go, the entire industry has been plagued with indoctrination of Object Oriented Programming. This has led to abstraction hellscapes in code, bloated code, highly tangled and coupled monstrosities unable to be properly tested except with mock testing (eg. not real tests), and ultimately code that is not performant. We see this in the requirements for faster hardware nearly every year to make our phones feel "snappy" again. Old computers unable to use modern OS systems for Web browsing, watching videos, and document based work.

All of this to say that these same practices are almost certainly present in Lucid's codebase despite best intentions because that is the indoctrinated practices with excellent engineers who know nothing better (and every manufacturer's codebase including Tesla who required hardware upgrades for software updates due to bloat).

If you can't live with the current bugs for some period of time, get a different car whose bugs you can deal with for an extended period of time. If software is that important, prioritize a legacy manufacturer who is unlikely to update or address bugs in their cars because that means stable and known bugs vs. potentially having bugs fixed + new features for the trade-off of potentially new bugs.
No idea what any of that means but sounds plausible. That said, also sounds like what Tesla and Rivian have to go through. Tesla has had FAR longer, Rivian launched around when the Air launched.

I am sure Lucid is all over it. But it’s extremely challenging and I get that. I am fine being an early adopter with Lucid.
 
Good lord. Did you read what I wrote? I did not “scold” you for having an opinion.

I asked you to state your opinions without using terms like fanboi because they do not add to the conversation and detract from it instead. I do not know how I can make that more clear. It is unnecessary name-calling. That’s all.

Your opinions are fine and valid and you can state them until your fingers go numb lol. I literally ended with:



Please, feel free to disagree. @HC_79 does. If he started calling people names, I’d ask him to stop too. It has nothing to do with your opinion, and everything to do with how you state it.

I hope that is clear, but please feel free to ask questions if you disagree or I am still not being clear.
Will avoid using the term Fanboy in the future. To be fair, my son calls me a Lucid Fanboy because I am constantly talking about Lucid and my pending Gravity.
 
- 3 known complete rewrites. Major versions of 1 and 2 for the Air. 3 for the Gravity. All of these rewrites take a ton of time of "stalling out" in the hopes, not guarantee, of addressing technical issues, bugs, and features not currently possible. This often means all new code that needs all new testing and equally long periods to find and iron out the "wrinkles" aka bugs.

- Technical Direction and Prioritization. Lucid has cycled through a number of "captains" directing the efforts and even associated "crews" for the software development. An organization must prioritize performance and long-term sustainability while equally compensating and rewarding employees to do so. Given the churn and overall focus on the driving experience (eg. the physical experience), I suspect a ton of resources have been allocated and prioritized to the in-house traction control systems and other hardware systems. The focus on long-term sustainability and performance of the user facing software only a more recent focus (post mad dash to get Gravity and UI/UX 3.0 out the door). Meaning all the sub-optimal decisions will plague the current software until addressed costing time and resources at some factor larger than "just doing it right" the first time.

While I would hope Lucid would have highly talented software engineers designing the best system from the get go, the entire industry has been plagued with indoctrination of Object Oriented Programming. This has led to abstraction hellscapes in code, bloated code, highly tangled and coupled monstrosities unable to be properly tested except with mock testing (eg. not real tests), and ultimately code that is not performant. We see this in the requirements for faster hardware nearly every year to make our phones feel "snappy" again. Old computers unable to use modern OS systems for Web browsing, watching videos, and document based work.

All of this to say that these same practices are almost certainly present in Lucid's codebase despite best intentions because that is the indoctrinated practices with excellent engineers who know nothing better (and every manufacturer's codebase including Tesla who required hardware upgrades for software updates due to bloat).
I i’m not disagreeing with the complexity, and perhaps that’s not where this discussion should go.

If you can't live with the current bugs for some period of time, get a different car whose bugs you can deal with for an extended period of time. If software is that important, prioritize a legacy manufacturer who is unlikely to update or address bugs in their cars because that means stable and known bugs vs. potentially having bugs fixed + new features for the trade-off of potentially new bugs.
The fact that we’ve all bought or are in the process of owning the Gravity means we are all fascinated, and impressed by it. This feedback is supposed to be constructive.

It’s not a bad thing to get emotional about a big purchase. Saying ”buy something else” doesn’t add to the conversation IMO.

Lucid had made tradeoffs - excellent hardware. Stuff that matters. The issue, if we may point out, is that none of the systems are easy to begin with. But other folks have done it. Yes it’s complex, but perhaps it needs more pushing and prioritizing to get right.
I don’t agree with Elmo’s approach but when he says all hands on deck, he shows up to get stuff done. Of course having unlimited made up money helps.
 
Just a note on this back and forth with software. At a high level, I believe people highly underestimate the effort and complexity of the Lucid's system. There are a lot of demands and juggling priorities being asked of the same "computer". As someone who expected to launch a database to market, built from the ground-up, 9 months ago vs still ironing out issues today, let me assure you the number of hidden gremlins, last minute architecture reworks due to bugs, and architecture cleanup due to performance requirements can and are unexpected and time consuming in these types of systems.

As an engineer observing from the outside Lucid's software, I suspect the following:

- Multithreading Is being used. This is one of, if not the single hardest piece to get correct. All those things you expect the car to do have to be coordinated and synchronized safely in the sheer chaos of any and/or all of them trying to do it at the exact same time. Fixing one bug, or even worse undefined behavior, often reveals a whole new set of bugs from previous incorrect assumptions.

- Event driven architecture. A system, including user interaction, gets triggered in one part of the code to be queued and processed in a completely different part of the code. This is the defacto design for most UI/UX systems with heavy backend processing (eg. audio, dream drive, hardware sensors, Lucid Assistant, etc.). Complex and hard to replicate as you have several things firing essentially random with random timings (eg. hard to consistently pinpoint and replicate the source of a bug).

- 3 known complete rewrites. Major versions of 1 and 2 for the Air. 3 for the Gravity. All of these rewrites take a ton of time of "stalling out" in the hopes, not guarantee, of addressing technical issues, bugs, and features not currently possible. This often means all new code that needs all new testing and equally long periods to find and iron out the "wrinkles" aka bugs.

- Technical Direction and Prioritization. Lucid has cycled through a number of "captains" directing the efforts and even associated "crews" for the software development. An organization must prioritize performance and long-term sustainability while equally compensating and rewarding employees to do so. Given the churn and overall focus on the driving experience (eg. the physical experience), I suspect a ton of resources have been allocated and prioritized to the in-house traction control systems and other hardware systems. The focus on long-term sustainability and performance of the user facing software only a more recent focus (post mad dash to get Gravity and UI/UX 3.0 out the door). Meaning all the sub-optimal decisions will plague the current software until addressed costing time and resources at some factor larger than "just doing it right" the first time.

While I would hope Lucid would have highly talented software engineers designing the best system from the get go, the entire industry has been plagued with indoctrination of Object Oriented Programming. This has led to abstraction hellscapes in code, bloated code, highly tangled and coupled monstrosities unable to be properly tested except with mock testing (eg. not real tests), and ultimately code that is not performant. We see this in the requirements for faster hardware nearly every year to make our phones feel "snappy" again. Old computers unable to use modern OS systems for Web browsing, watching videos, and document based work.

All of this to say that these same practices are almost certainly present in Lucid's codebase despite best intentions because that is the indoctrinated practices with excellent engineers who know nothing better (and every manufacturer's codebase including Tesla who required hardware upgrades for software updates due to bloat).

If you can't live with the current bugs for some period of time, get a different car whose bugs you can deal with for an extended period of time. If software is that important, prioritize a legacy manufacturer who is unlikely to update or address bugs in their cars because that means stable and known bugs vs. potentially having bugs fixed + new features for the trade-off of potentially new bugs.
hi, can we be friends
 
Will avoid using the term Fanboy in the future. To be fair, my son calls me a Lucid Fanboy because I am constantly talking about Lucid and my pending Gravity.
Thanks. It’s not about the opinions. Between your son and you, that term isn’t loaded with malice. My wife is allowed to call me plenty of things I’d never call another human being.

Fanboy isn’t a dirty word or something; it’s just wholly unnecessary and some people take offense to it and it becomes the entire conversation, rather than what was being talked about in the first place.

That’s all I’m advocating for. Charitable, polite, even angry disagreement - but without additional distraction or malice.
 
1759676832219.gif
 
Back
Top