Meng Xing on Tesla FSD, End-to-End Models and Driverless Cars

Zhang Xiaojun and Meng Xing discuss the automated-driving industry, Tesla FSD and end-to-end models. Meng previously worked in autonomous driving and invested in the sector; his experience and judgments reflect the interview date.

Meng recalls studying, founding companies and investing in China and the United States. Moving from investment to operations changed both the breadth and detail of his perspective.

He compares entrepreneurial and work experience across settings, saying organization, markets and resources affect how companies develop.

Automated driving appears accessible because people can see a car move and feel the ride, but the underlying system connects vehicles, hardware, software, data, testing and regulation.

He says a single public demonstration cannot represent overall capability, and industry insiders may not know competitors’ details, creating information gaps.

He distinguishes driver-assistance products from driverless services operating in specified conditions. Their product goals, responsibilities and operating requirements differ substantially.

He discusses Waymo’s gradual operations in Phoenix and says people who have not experienced them may underestimate incremental progress.

Meng attributes gaps in public awareness to geography, preconceptions and company promotion strategies. This is his observation, not evidence of internal decisions.

He cites gradual expansion of driverless services in China and says public attention can lag pilots; years of iteration should not be mistaken for an overnight breakthrough.

In his view, driver assistance must combine system capability with human supervision, whereas a driverless service must address vehicle operation and safety without an onboard driver in its operating domain.

The discussion turns to Tesla FSD. He tried versions including V11.3.6, V12.3 and V12.4, stressing that his assessment comes from limited hands-on testing rather than comprehensive safety statistics.

V12 drew attention for its end-to-end architecture. Meng says avoiding a major regression after a large architectural change was an engineering achievement, but it did not solve every scenario.

He recalls an intervention in a public demonstration and says its significance depends on the product goal. Driver assistance and driverless services cannot be judged by the same simple standard.

He says V12.3 handled many situations but still failed or required intervention in some complex merges and parking areas. This is his experience, not a performance measurement across all vehicles.

He compares later versions with publicly claimed improvements and says experiences must be interpreted with the scenarios, test methods and definition of intervention in mind.

He explains why driverless and driver-assistance developers may assess the same performance differently: operation without a driver imposes different reliability and exception-handling demands.

He discusses tension between intervention frequency and driver attention: smoother use may make people less vigilant, so products requiring drivers need clear supervision and handoff design.

In his view, driver assistance seeks a better shared-driving experience, while driverless service targets mobility and operating cost within a defined area.

On levels L1–L5, he emphasizes distinguishing system capability, operating conditions and driver responsibilities. A level does not mean a vehicle can drive itself on every road.

Automation levels describe responsibility for the dynamic driving task, while legal liability depends on applicable law and facts and cannot be determined from a level label alone.

He discusses L4 systems handling the driving task within their operating domain and using appropriate fallback or remote assistance when limited. Actual remote-support methods vary by system.

Compared with a product supervised by an onboard driver, driverless operations may require remote support, fleet dispatch and a different safety-validation system; the engineering problems are not identical.

Asked why V12 renewed industry interest, Meng says the reason was not only immediate user experience but the possible long-term room to improve after an architectural change.

Traditional architectures often separate perception, prediction, planning and control; end-to-end approaches try to optimize more of the chain jointly from data. Companies use the term with different boundaries.

He says changing architecture carries risk: even a system with greater long-term potential may initially lose established capabilities. Continued testing is needed to identify regressions.

Compared with hand-written rules, data-driven methods may learn complex behavior from many examples, but still need rare-scenario coverage and verifiable performance.

The host asks how outsiders can study a system that is not fully public. Meng says demonstrations, papers and test drives provide only partial information, so internal details remain uncertain.

He compares V12 to an early milestone in driver assistance rather than a finished endpoint. The analogy conveys potential but cannot predict actual capability or commercial outcomes.

He recalls behaviors that were not explicitly programmed appearing in data-driven systems, but says these are often incidental observations that require systematic testing.

A surprising single performance does not prove consistent reliability in similar situations. Evaluation must also cover different roads, weather and road users.

They discuss the size and history of Tesla’s team. Meng cites information available at the time; staffing and organization can change and should not be treated as current figures.

He considers data processing, model training, engineering infrastructure and validation essential investments. A small model team does not imply the entire product chain requires few people.

The technical history turns to bird’s-eye-view representations and Transformers. Meng says these approaches help combine camera information, track objects across time and connect perception with prediction.

He describes combining perception and prediction before passing results to planning. Several neural-network modules do not necessarily mean the entire driving system is trained end to end.

If intermediate outputs are human-readable detection boxes or trajectories, optimization across modules may be interrupted; implementations can use different representations and training methods.

Asked about Tesla’s exact implementation, Meng acknowledges that public information does not reveal every internal detail, so the architectural comparison includes inference.

They turn to sensor choice: cameras provide rich images, while lidar and radar provide different information. Each approach must address noise, cost and failure cases.

Meng recounts reasons given for Tesla’s vision-focused approach and says the industry disagrees. Sensor safety must be assessed using the complete system and evidence.

He argues active ranging and radar can complement vision in some distance, weather or visibility conditions; every sensor also has blind spots and limits and cannot guarantee risk elimination.

Asked whether end-to-end methods apply to both L2 and L4, he says they can share tools but differ in safety goals, operations and fallback requirements.

He discusses data coverage and rare events: large driving datasets are valuable, but volume alone does not cover every hazardous case or replace safety validation.

Camera data may be easier to gather from large fleets or public video; other sensors’ coverage can be limited by fleet configuration and cost. Collection still requires appropriate authorization and terms.

He says V12 showed that experience could survive an architectural shift, encouraging teams to explore a potential ceiling. His claim of a higher ceiling is a technical judgment, not proven by the interview.

On cost, he discusses training compute, data systems, staffing and testing. Actual expense varies by company, model and scale; interview estimates do not apply to every project.

He observes that several Chinese companies were exploring end-to-end approaches, but teams may retain different degrees of rules and safeguards; their products should not be treated as identical.

Team size may change through exploration. Meng says models, data and safeguards all need people, but the right staffing cannot be inferred from an architecture name alone.

The host compares automakers’ descriptions of models, vision-language systems and validation tools. Meng says public terminology is insufficient to determine exact internal differences.

Deploying a system across countries also involves local roads, regulation, data security and operating conditions. Replication needs local data and validation, not just software transfer.

The interview ends by emphasizing ongoing iteration. Drivers should use the applicable product instructions and local rules to understand their responsibilities; a historical interview does not establish current capability.