Tesla FSD v14 swerved and try to drive me into a ditch for no reason

Introduction: When an Autonomy Stack Decides Twice

At 110 km/h on an empty, well-marked highway at night, a Tesla running FSD v14. 3. 6 supposedly attempted to take a highway exit it had already passed. The driver corrected before leaving the roadway, but the event raises questions that go far beyond a single software bug. This is a systems failure with predictive, planning, and Control implications.

When a production autonomy stack attempts a late highway exit at 110 km/h, the failure mode is rarely a single sensor error - it's a distributed systems breakdown across prediction, planning, and control that deserves a postmortem-grade analysis. that's exactly what I want to walk through here. We will treat the incident report as an unstructured bug ticket and apply the same rigor a senior platform engineer would bring to a production outage.

The driver's environment removed many variables that usually explain autonomy failures: no traffic, no adverse weather, and clear lane markings. Under those conditions, a system with cleaner inputs than 95 percent of real-world driving still made a decision that contradicts the geometry of the road. That inversion - high confidence on clean data producing an unsafe maneuver - is the most instructive part of this event. It tells us the bottleneck isn't perception, and it's decision arbitration

The Incident Sequence and the Empty-Road Paradox

The reported sequence is short and specific. The driver activates FSD v14. 3, and 6 on a divided highway at nightThe road is empty, and lane markings are clear. As the vehicle approaches an exit at 110 km/h, it crosses the exit point without signaling. Moments later - after the exit is behind the vehicle - the steering system begins a lateral movement toward the exit path, as if the planner had just then committed to the maneuver. The driver intervenes, the system disengages, and the car continues straight.

Software engineers should immediately recognize this signature as a replanning anomaly, not a perception failure. The car did not misidentify the exit, and it mis-timed the decisionIn a deterministic, rule-based control system, that timing error would be nearly impossible because the map data would have stamped the exit's location in absolute coordinates. In a learned, end-to-end planning stack, however, timing is emergent. It depends on how the network interprets temporal context, not on a hard-coded "exit approaching" flag.

The empty-road condition is important because most autonomy training data contains traffic. And vehicles follow other vehiclesGaps between cars define merge windows. When traffic disappears, the model loses those cues. An empty highway isn't easier for an end-to-end system; it's distributionally stranger. The model has fewer motion-anchor features from surrounding agents and must rely on static geometry alone - which, for a network trained predominantly on flowing traffic, can be the harder case.

FSD v14 Architecture Changes Under the Hood

Tesla has publicly framed FSD v14 as a major architectural revision. While the company doesn't publish detailed design documents, external reporting and Tesla's own software update notes point to a more unified vector-space representation, reduced reliance on explicit C++ rule modules. And a larger end-to-end neural planner. The v14, and 36 point release specifically touched highway stack behavior. Which aligns with the incident being reported in a highway context rather than city driving.

For engineers, the relevant architectural question is whether the planner operates on a receding horizon with explicit map priors or on a fully implicit plan generated by a transformer. If the former, a late exit command would suggest the horizon window or the map's timestamp was corrupted. If the latter, the failure is more subtle: the network's attention mechanism may have associated the visual exit sign with a maneuver that was no longer geometrically reachable, effectively "remembering" the exit too late. Both are plausible. Neither is a simple fix,

This distinction matters for debuggingAn explicit planner can be patched with a guard clause: suppress exit maneuvers when the vehicle's longitudinal position is past the gore point by more than X meters. An implicit planner cannot be patched that way. You have to retrain or add a separate verifier module - which itself creates a hybrid architecture, undoing some of the simplicity that attracted Tesla to end-to-end learning in the first place. That tension between purity and safety is a recurring theme in autonomy engineering.

Why Late Exit Decisions Happen in Production Systems

A late exit decision isn't unique to Tesla. Any autonomous system that combines perception, prediction. And planning can exhibit temporal lag between the moment an action becomes necessary and the moment the planner commits. In classical robotics stacks using tools like ROS 2 and model predictive control (MPC), the lag is often a fixed pipeline latency: frame capture, object detection, tracking, planning, control command. If any stage is delayed, the plan reflects a stale world state.

MPC operates on a receding horizon, typically 5 to 10 seconds. At 110 km/h, a 5-second horizon covers roughly 153 meters. If the planner's internal representation lags by even one second, the vehicle's committed trajectory can be 30 meters behind reality. An exit that was ahead in the stale world model is now behind in the real world. The planner still believes the maneuver is feasible and sends the steering command, and this is a classic