A Third Strike for Waymo on Failed Quick Fixes
A follow up to the Crazy Taxi construction zone story
You might have seen the story from May about a high-profile social media video alleging a Waymo being chased by police for driving on a closed construction roadway in a highway construction zone. Turns out that was the tip of the iceberg. And that iceberg is the third one they’ve hit.
Waymo just issued a recall for a problem that involves “enter and drive at speed in freeway construction zones.” This seems to correspond to driving on the closed road area in a construction zone, such as to get around backed up traffic.
It turns out this was not just a single incident. The recall report reveals a more concerning pattern:
April 11 -- One event; no apparent action taken immediately
April 19 -- Five events; Waymo Field Safety Committee meets
Freeway driving restrictions; then "operational mitigations" (e.g., don’t drive in mapped construction zones)
May 18 -- Seven events, including the one that got significant media attention
May 19 -- Safety Committee meets again; freeway driving halted
June 1-8 -- Waymo decided to do a recall (after 13 total events and high profile news stories)
June 17 -- Recall published; no remedy identified yet
A true “safety is our top priority” company would have been digging on April 11th and invoked a quick-turn triage/standdown process without waiting for more incidents a week later. Whether that happened or not, and whether that process needs to be improved in light of events, Waymo does not say.
The deeper issue is that this is the third attempt to do a quick fix that ultimately resulted in further incidents and eventual recalls. The two previous issues were entering flooded areas at speed, and improperly driving past stopped school buses (with stop sign/lights activated).
This is the third strike on Waymo’s quick fix process.
In all three cases Waymo chose to continue operations after a quick fix that they said handled the problem, only to see further problems emerge.
Moreover, for all three problems we only saw a recall after high-profile news stories despite multiple previous events spread across weeks or months. (Correlation is not causation, but at the very least this is a bad look for Waymo.)
The take-away for all companies should be that tactical operational restrictions are hard to pull off in practice. The world has a way of catching you by surprise. Maybe believing you can track all the hazards in the real world in real time is not a smart idea for the next quick fix.
The questions Waymo should be answering are:
What has changed that we should believe the next quick fix will work after three conspicuous quick-fix failures? At the very least this calls the credibility of their quick-fix validation process into question.
Why is it so hard to get these fixes to work? Is this a surprise downside to the switch to end-to-end machine learning?
What other incidents have already happened with a quick fix (but no big news story and no recall) that we don't know about? Will we have to wait for high-profile news stories before Waymo comes clean that they have yet another safety issue?
Why weren't those quick fixes turned into recalls from the start? Clearly in the end they were acknowledged as safety defects. What changed between the quick fix and the recall? Are the quick fixes at least being reported to NHTSA?
Recall summary: https://www.nhtsa.gov/?nhtsaId=26E035000
Part 573 Recall report: https://static.nhtsa.gov/odi/rcl/2026/RCLRPT-26E035-7637.pdf
Techcrunch recall story: https://techcrunch.com/2026/06/18/waymo-recalls-nearly-4000-robotaxis-to-stop-them-driving-into-highway-construction-zones/
CBS story about construction zone violation: https://www.cbsnews.com/sanfrancisco/news/san-francisco-waymo-rider-construction-zone-police-chase/
Mistakes (mishaps) must be corrected. But even more important is how you correct it and communicate that clearly to public. That's the first step.
One way to read three failed quick fixes: each carried an implicit answer to a question nobody measures. When a deployed system changes, some fraction of the safety case reopens: analysis, test, approval. A fix is "quick" precisely because the company set that fraction near zero, and the field then revealed what it actually was. As far as I can tell, that fraction has never been published for any program, in any domain. So adequacy gets litigated incident by incident, after the fact, because there is no norm to check a change class against before shipping. If the reopening fraction were measured and published, a quick fix would be an auditable engineering claim. Unpublished, it is a bet, and the public finds out at strike three. Which makes posts like this one of the few public datasets on the question, taken from the failure side.