What if the hardest dependency in an autonomous vehicle system isn’t the perception model, the sensor fusion pipeline, or the fallback controller, but a state legislature?
That question stopped feeling rhetorical to me when the news broke that Waymo doubled its lobbying spending as it squares off with Uber in the robotaxi market. Uber and Waymo have together spent more than $15 million this year lobbying New York politicians alone. Not on lidar. Not on compute. On persuasion.
I build bots for a living. Smaller ones, mostly software agents that talk to APIs and occasionally embarrass me in production. But the architectural lesson translates upward, and I think a lot of us who write code for autonomous systems have been quietly ignoring it.
The layer we keep leaving out of the diagram
When I sketch an architecture for a bot, I draw the usual boxes. Inputs. Processing. Decision logic. Outputs. Monitoring. Somewhere off to the side, if I am being honest with myself, there’s a box labeled “constraints” that I fill in with rate limits and terms of service.
For a robotaxi, that constraints box is the entire ballgame. A vehicle that drives flawlessly in San Francisco is a very expensive paperweight in a city that hasn’t authorized driverless operation. The model doesn’t care. The regulation does. And unlike an API rate limit, this constraint is not a fixed number you design around. It moves, and both Waymo and Uber are spending millions to move it in their preferred direction.
That reframes what the spending actually is. Reporting frames it as a lobbying battle, which it is. From a systems view it’s something more specific: two companies investing in mutable infrastructure. Waymo doubling down suggests they concluded the regulatory layer has higher marginal return per dollar right now than another increment of engineering. That’s a striking judgment call from a company with Google’s technical resources behind it.
What this means if you build automation of any size
Most of us aren’t fielding fleets. But the pattern generalizes, and I’ve watched smaller versions of it play out in bot projects.
- Your permission surface is a real component. Whether it’s a platform’s automation policy, a scraping rule, or a jurisdiction’s vehicle code, the rules that let your system run deserve a box in the diagram and an owner on the team.
- Rules change faster than architectures. A regulation can flip in a legislative session. A refactor takes quarters. Build for the possibility that your operating envelope shrinks or shifts, not just that traffic grows.
- Compliance is a feature with a test suite. If your bot must behave differently in different jurisdictions or on different platforms, that’s configuration and coverage, not a footnote in the README.
- Someone else may be funding the rules you inherit. This is the uncomfortable part. If the biggest players are spending to shape policy, the environment your small project operates in gets shaped by budgets you can’t match.
The asymmetry problem
That last point is the one I keep chewing on. Critics have accused Uber of pushing for regulatory outcomes that suit its own model, and Waymo’s response has been to spend more. Two well-capitalized companies bidding on the same policy outcomes produces rules written in the shape of their business models.
Anyone building autonomy outside those two companies inherits that shape. If licensing regimes assume fleet-scale operations, a research group or a startup with six vehicles gets priced out of the road, not because their stack is worse but because the compliance floor was set by companies who wanted a high floor. I’ve seen the software equivalent when platforms tighten automation policies in ways that large partners can absorb and independent builders cannot.
A more useful way to read the news
The easy read is cynical. Big tech buys influence, nothing new. I think the more interesting read for builders is diagnostic. Waymo’s spending increase is a signal about where the bottleneck actually sits in autonomous deployment right now, and it’s not the driving.
The technical problem is far from finished. Edge cases are hard, and any engineer working on perception will tell you the tail is long. But if the company arguably furthest along on the technical side is doubling its policy budget, the implied claim is that permission has become the binding constraint on growth.
So here’s what I’m changing in my own practice. When I plan a bot that touches the physical or legal world in any way, the operating rules get documented alongside the interfaces, with a note on how fast each one can change and who has the power to change it. It’s a small habit. It also means the next time the ground shifts, I’ll know which parts of the system were resting on it.
The robotaxi race is being run on two tracks at once. Only one of them has code.
🕒 Published: