China now builds roughly half the world’s electric vehicles. It got there in about ten years. BYD ships a car in 18 months while Volkswagen works to compress its MEB cycle toward 40. The reflex in Europe is to explain this away with cheap labor and state subsidies. That explanation is comfortable and incomplete.
Michael Jastram spoke with Yuchao Luo, who has worked on both sides of this divide. He has been inside a legacy OEM running a Volkswagen joint venture and inside one of China’s first new EV players. His account is not a victory lap for “China speed.” It is a more uncomfortable argument about process, proof, and what compliance is actually for.
Yuchao Luo
Yuchao Luo studied automotive engineering in China and moved to Germany in 2013 to pursue a master’s degree in automotive engineering. During his studies, he interned at Bosch in Bamberg for about six months. In 2017, he returned to China and joined NIO, one of the early Chinese EV pioneers, where he worked for around three years. He later joined Z-One Software, a wholly owned subsidiary of SAIC, where he worked on the next-generation software foundation for SAIC’s premium vehicle brands.
That sequence meant that Luo saw the new-player culture and the legacy culture from the inside, and he watched both camps insist they were right. In 2021 he founded Mapping Space, his own company to integrate Agile and ASPICE in automotive development. It now has dozens of paying customers in China and works in the AI-Powered ALM space, application lifecycle and requirements tooling. He describes himself as a traditional auto guy. That self-description is the point of most of what follows.
LinkedIn Post: Every car company has a voice assistant now.
Why legacy OEMs struggle with the software-defined vehicle
Luo dates the shift to 2017 and 2018, when China filled with new EV players. BYD was the early outlier, having bet on electric roughly two decades earlier. Around 2014 and 2015 the Chinese government pushed resources toward EVs, partly as industrial strategy and partly because the country lacks oil. Founders from the internet and consumer-electronics world entered the car business with, in Luo’s framing, low burden. No legacy standards to defend. No old documents to start from. They could begin from scratch.
The legacy OEMs initially did not believe the internet players could change anything. They watched from the outside to see who would survive. Meanwhile the new players iterated fast, because their engineers came from mobile phones and the internet, and they had learned from Tesla that over-the-air updates were a good way to iterate a car. A ship-then-fix mindset moved from phones into vehicles.
The second difference was infrastructure, and this is the part European discussions tend to skip. Legacy OEMs wanted customer feedback too. They could not act on it quickly because they had no OTA or CI/CD infrastructure to push changes back out. Hearing the user and being able to respond to the user are different capabilities. One without the other is theater.
The new players also sold differently. Instead of dealerships, auto houses, and media branding, they went directly to user groups, gathered feedback, and let customers see their input reflected in the vehicle within a quarter or two.
“If you have a mobile phone and you can see that your mobile phone can iterate every day, that is a different kind of feeling.”
Yuchao Luo
This was not a smooth ascent. Around 2020 and 2021, NIO and XPeng came close to dying. NIO’s share price collapsed toward a dollar. Luo attributes the near-death to a tangle of causes, among them supply chains, COVID, and individual incidents. They held on. The legacy OEMs, watching the survivors, finally started to learn from them.
The platform and the role of government
Confidence in OTA did not arrive for free. In the early years many users distrusted it, and the fear was specific and reasonable. An OEM could use a silent OTA to patch a safety problem without acknowledging it. Experts and users pushed back. The Chinese government responded with guidance rather than a ban.
Under that guidance, an OEM that wants to push an OTA must report it to the relevant authority first, including the features and bug fixes in the release. The authority can take a month, three months, or longer to clear it, and it controls both the frequency and the content of updates. The effect is deliberate. It removes the option of using OTA as a quiet channel for safety-critical fixes, while keeping the iteration mechanism itself intact.
This is worth sitting with. The Chinese answer to “fast iteration is dangerous” was not to slow iteration down. It was to make the iteration channel visible and accountable. The capability survived. Only the abuse path was closed.
What “quality” actually means
The strongest idea in the interview came from a Bosch China executive Luo once spoke with about quality, compliance, and Agile. The executive’s claim, in Luo’s retelling, was blunt. If you have only sold a hundred units, you have no right to claim quality, because your sample is too small. Even if all hundred are perfect, the statement carries no weight.
“Even though you set your process for a lot of compliance, for the very strict standards, you have no proof.”
Yuchao Luo, recounting a Bosch China executive
The point is not that customers should be treated as test subjects. The point is that volume in the market is a result, not a process input. You do not intend to sell more and therefore sell more. You build something good and selling more follows. The numbers are the evidence, produced after the fact.
From this Luo draws a clean distinction. There are two ways to defend your work. The first is to prove the process is good and refuse to discuss outcomes. The second is to care about the process and also care about the outcome, on the argument that without an outcome there is no way to show the process was right. He is explicit that the goal is both. He is equally explicit that both at once is the ideal case, not the normal case, especially in a fast-iterating market.
It’s important to remember that this conclusion does not apply to every industry. The volume argument is an automotive and consumer-electronics argument. An aircraft manufacturer cannot sell millions of units; the market does not demand them. The framework is sharpest where volumes are high and weakest where they are not. That qualification belongs in any honest reading of the idea. Within its domain, the challenge stands: a wall of certifications behind ten real users is a weaker quality claim than a million cars in the field.
MBSE, direct code, and timing
Luo’s view on model-based systems engineering (MBSE) is more interesting than a simple for-or-against. He uses Agile and DevOps heavily. He uses MBSE less, while still calling it important for safety-critical and legacy components, where a model can yield code already proven safe, faster than writing it by hand.
His objection is about timing. In the software-defined vehicle, many features were never implemented in combustion cars. No system or software model exists for them, so they have to be coded from scratch. Direct coding therefore matters more in this phase. He expects that in ten or twenty years these features will stabilize into standard components, and at that point they can become model-based. Not yet. Move to models when the thing being modeled has stopped moving.
This reframes why MBSE adoption struggles. The problem may not be tooling or training. It may be that organizations are trying to model a domain that has not held still long enough to be worth modeling.
He adds a tech-stack observation. Traditional automotive engineers trained on MATLAB and Simulink alongside C and C++. Engineers in software and digital-cockpit teams find far fewer ready modules to reuse. The two groups do not share a toolbox, which makes a shared method harder than the method debate admits.
Industrial DevOps has limits set by the product
Industrial DevOps is the concept of applying DevOps principles to hardware. Some organizations outside automotive already apply this successfully. SpaceX, for example, redesigns and rebuilds engines on roughly two-day cycles.
Luo’s response was a clear boundary. Software in the system can move fast with DevOps. Hardware, in his view, cannot, and the reason is the nature of the product. A rocket is a limited, controlled environment, and an exploded prototype costs more rockets, not stranded customers. A redesign every two days drags a long tail of surrounding tooling and budget with it. No OEM can afford that across a fleet of millions of configured vehicles. The constraint is not ambition or method. It is the product itself and the scale it ships at.
This is a healthy correction to method evangelism. A practice that works brilliantly for a hundred rocket engines under one roof does not automatically transfer to millions of cars in customers’ hands. The transfer has to be argued, not assumed.
CI/CD for Automotive: Scaling HIL Test Clusters to Accelerate Software-Defined Vehicle Development
The Changing Landscape of Automotive Development
Culture and the order of the questions
Luo’s clearest cultural observation is about reflexes. When something new appears, one culture’s first question is whether it is compliant and safe. The other culture accepts that government and standards always lag industry, so at the start of a genuine innovation there is no compliance to satisfy yet, because none exists.
He applies this directly to AI. European engineers, hearing that AI can generate requirements or support the development process, often ask first how safety-critical correctness can be proven. The Chinese stance he describes is different in posture, not in awareness. Everyone knows AI is not 100 percent correct. They use it anyway, because it can produce 70 to 80 percent of the output, and humans check and correct the rest.
Sometimes critics forget that humans also make mistakes, and the industry already runs reviews and processes precisely to catch human error. Holding AI to a standard of zero error that humans were never held to is not caution. It is a category mistake.
“If at the beginning of one innovation you directly talk about compliance, the government is normally slower than the industry. At that time there is no compliance for this new innovation.”
Yuchao Luo
Neither man treated China speed as automatically correct. Luo named BYD battery incidents and customer-compliance issues from the fast camp. The argument is not that one culture is right. It is that the order of the questions changes what gets built.
Where AI actually helps engineering today
Luo named vibe coding first, as the obvious case, the Cursor and Claude Code category. His more specific interest, from five years in ALM tooling, is integrating AI into the development process itself rather than just the code.
Two scenarios he finds genuinely useful. First, document review against compliance. Tell the AI it must hold the document against ISO 26262, ASPICE, and cybersecurity standards, hand it the document, and ask where something is missing. The AI carries the standards in a way no single reviewer reliably does. Second, traceability. Give it a requirements document and a test-case document and ask it to propose the trace links. The engineer reviews and corrects the suggestion rather than building the matrix by hand.
He attached a sharp aside to the second case. Traceability gives users the feeling that a system is safe. Whether the system is actually safe is not determined by traceability. It is a format for recording, nothing more. That is a useful warning against confusing the artifact with the property it is supposed to evidence.
His scope advice was equally direct. Do not push a new capability to a large, general deployment first. An AI feature that claims to do everything ends up tailored to nothing and serves no one well. Start narrow, prove it, then generalize. One more note from his side that European buyers will recognize: Chinese enterprises strongly prefer on-premise software so data stays local, and that preference carries straight into how they deploy AI agents internally.
Conclusion
Luo’s closing advice to a European executive was not a list of methods. It was respect for what Volkswagen has actually done, and a warning about how to learn from it.
He credits VW for continuing to invest in China through the geopolitical friction, and for changing the kind of investment. The money no longer goes only into manufacturing plants. It now goes into R&D talent and into joint ventures with local companies such as Horizon Robotics and XPeng, learning from competitors how to build software fast while still meeting both Chinese and European compliance. From that he draws two priorities. Invest, and stay engaged. Then he adds a blunter instruction. Do not just listen to interviews like this one. Watch what the fast players actually do, on the task, not in the telling.
That is the real takeaway, and it cuts against the format this article is written in. The interesting question is not whether China is faster. It is which question an organization asks first when something new arrives. Ask “is it compliant?” before anything exists to be compliant with, and the innovation never reaches the point where the question would have an answer. Ask “does it work, and can we prove it at scale?” and compliance becomes a constraint to integrate rather than a gate to hide behind. The European instinct to raise concerns is a strength in a mature product line and a liability at the start of a new one. Knowing which situation you are in is the whole job. The German strength is finding reasons a thing should not be done. The market is no longer waiting for those reasons to be resolved.
Yuchao Luo consults with German companies on automotive process activities. His LinkedIn profile: https://www.linkedin.com/in/yuchao-luo/
