Well, I'm not sure that statement applies anymore in the Fire! Aim! Ready! world that is Agile Development. The entire premise is based on shipping something that's not done & let letting the users tell you what to fix, so you don't "waste time" fixing "the wrong things". As if.
Actually, that's not quite the purpose of agile development. The purpose of agile development is prioritized development in an environment with rapidly changing or unknown priorities. That may be churn from customers or from other sources (such as a rapidly changing new market). The theory is that of X items, some subset of those are core to your business and you can focus in on those and narrow the field of later features as time goes by. There are pros and cons, but generally it's good for greenfield development where the trail has not been well blazed with products to copy.
Which is not to be confused with iterative development, which is about incremental development. Agile is a form of iterative development and is an umbrella term that covers a number of methodologies, while iterative development is more of a core best practice. Agile is an iterative variant specifically for environments with high requirements churn or uncertainty. It's also for an environment where being wrong isn't game over as you can pull it and try again.
Extreme programming (and some other ultra-agile), which some often confuse with the more generic agile movement, is an agile methodology, but very specifically tailored originally to development where the customer is co-located. It's this particular situation where the early customer feedback is a central part of the methodology because, in theory, the customer is co-located with the development group nearly 100% of the time. I'm not a fan and almost no one does pure XP because it's almost academic in it's purity of requirements. Kent beck states you have to do XP in all it's specifics or it doesn't work, but it's all but impossible to fulfill each criteria that Beck lays out.
While most agile methodologies encourage customer feedback, it's by releasing minimal initial sets of core business functionality. That is _not_ software that's "not done", it's software that's feature poor. However, you need tolerant customers that believe in your potential to give feedback on initial release that aren't, frankly, competitive at that point. Telsa's very initial software release would qualify. For example, they didn't even have per-driver settings in their first release. They also got to use Roadster owners for very early, almost proof-of-concept, software.
We won't even discuss Waterfall, which is all but discredited at this point. Though, interestingly, Winston Royce's vision of it wasn't as anti-iterative as it's adoption became (see my article at
Software History: Waterfall – The Process That Wasn’t Meant To Be | Online Business Systems).
In an environment like Tesla, I'd guess they are definite strong iterative, focusing on core business values first (hence, why the damn music system still doesn't have a shuffle). They probably have adopted various Agile practices which fit well with most organizations, but they do not have frequent updates (daily or weekly), so they are likely on a large-chunk delivery schedule that coordinates across multiple groups. Such coordinated releases require a non-trivial lead time, which means things like A/B pack software changes are incredibly unlikely to have snuck in and surprised anyone.
. 
