Waymo has restarted its San Antonio robotaxi service, five months after flash flooding in April 2026 left several of its cars stuck in waterlogged streets and swept one of them away. TechCrunch reported the restart on 17 September 2026, following the San Antonio Express-News.
The detail worth your attention isn't the restart. It's what Waymo changed to get there — and how little of it was about making the driving model smarter.
🌊 The car slowed down. It did not stop.
The failure description in the reporting is one sentence long and it is the most useful sentence in the story: as the robotaxis approached flooded areas, the vehicles slowed but did not stop.
That is not a perception system that saw nothing. That is a perception system that saw something, lowered its confidence, reduced speed, and then kept going anyway because "keep going, carefully" was the only behaviour available to it. There was no abstain path.
| Date | Event |
|---|---|
| April 2026 | Flash flooding; multiple Waymo vehicles stuck, one swept away |
| April 2026 | Service suspended in San Antonio; other Texas cities briefly paused |
| May 2026 | Waymo issues a recall |
| 17 Sep 2026 | Service resumes — dozens of vehicles, 60-mile area |
Key takeaway: A system that degrades gracefully into "proceed slowly" is still a system that proceeds. If your failure mode has no stop state, uncertainty just becomes a slower version of the same mistake.
🗺️ The fix was a boundary, not a breakthrough
Per TechCrunch, Waymo did two things before coming back:
- Restricted the robotaxis from driving in areas with elevated flood risk.
- Modified the software to better detect and avoid standing water.
Notice the order of difficulty. The second one is a hard machine-learning problem: standing water is reflective, shallow puddles and 60cm of moving flood look similar from a camera, and you cannot collect a clean training set of "street that will sweep your car away." The first one is a polygon on a map.
| Approach | What it costs | How fast it ships | Failure mode |
|---|---|---|---|
| Make the model handle it | Data collection, retraining, validation, recall | Months | Silent, until it isn't |
| Shrink the operating area | A geofence and a product decision | Days | Loud and obvious (service unavailable) |
Self-driving people call that boundary the operational design domain — the written-down set of conditions your system claims to work in. Waymo's restarted service is a narrower ODD than the one that failed: dozens of vehicles across a 60-mile area covering downtown San Antonio and the airport, with high-flood-risk zones carved out. It is now one of 15 US cities where Waymo operates.
Most of us shipping AI features have no written ODD at all. We have a prompt, a model, and hope.
🇱🇰 Why a Texas flood is a Sri Lankan engineering problem
Two reasons this lands differently from here.
First: the geography of training data. A vision stack tuned on American road conditions carries an implicit assumption about what a road looks like. Monsoon flooding, unlit rural stretches, a three-wheeler cutting across two lanes, cattle — these aren't exotic edge cases in Sri Lanka, they're Tuesday. Any model you import as a service inherits someone else's idea of "normal," and the gap between their normal and yours is exactly where your long tail lives.
Second: we flood too, on a schedule. Waymo was surprised by water in April. Nobody building for Sri Lanka gets to be surprised by water. If you're building anything that takes real-world input here — delivery routing, an insurance claim triage bot, a crop advisory tool — the seasonal failure case is knowable in advance, which means the geofence is writable in advance.
If you want a cheap intuition for how confidently a vision model misreads an unfamiliar scene, run a few of your own photos through our AI object detector and watch what it names, what it misses, and how sure it sounds about both.
🛠️ The pattern, in about ten lines
You do not need a robotaxi to apply this. Any system with a model in the loop can have three states instead of two:
type Decision<T> =
| { kind: "act"; value: T }
| { kind: "degrade"; value: T; note: string }
| { kind: "refuse"; reason: string }; // the state Waymo's cars didn't have
function decide<T>(r: { value: T; confidence: number }, inDomain: boolean): Decision<T> {
if (!inDomain) return { kind: "refuse", reason: "outside declared operating domain" };
if (r.confidence < 0.6) return { kind: "refuse", reason: "low confidence" };
if (r.confidence < 0.85) return { kind: "degrade", value: r.value, note: "human review" };
return { kind: "act", value: r.value };
}
The inDomain check is the geofence. It runs before the model, costs nothing, and is the part you can actually reason about at 2am.
A practical checklist for your next AI feature:
- Write the domain down. One paragraph: what inputs, what languages, what conditions. If you can't write it, you don't have one.
- Add a refuse state. "I can't handle this, here's a human" is a valid product outcome. Silent degradation isn't.
- Log every refusal. Refusals are your free edge-case dataset.
- Re-check the boundary seasonally. Conditions change on a calendar; your geofence should too.
- Make the boundary a config value, not a deploy. Waymo needed a recall. You should need an environment variable.
💡 What this means for you
One swept-away car cost Waymo an entire city for five months and forced a recall. The company that came back is not running a materially smarter driver — it's running the same driver inside tighter walls, with a water detector bolted on.
The cheapest reliability improvement available to a small team is almost never a better model. It's an honest, written, enforced statement of where your system refuses to operate.
If you're a student or a two-person team shipping something with a model inside it, you can't out-engineer Waymo on perception. You can absolutely out-engineer them on humility: declare your boundary, enforce it in code, and make "no" a first-class answer. That costs an afternoon. The alternative cost five months.
