Uber and Waymo spent more than $15 million combined this year lobbying New York politicians. That’s for one state. Not one line of that budget went toward perception models, sensor fusion, or path planning.
I build bots. Small ones, mostly — automation agents, scrapers, task runners, the occasional autonomous system that has to make decisions without me watching. So when I read that Waymo doubled its federal lobbying spending to push US regulators toward clearing a path for fully autonomous taxi services, my first reaction wasn’t about Uber or Alphabet or market share. It was recognition. That’s the wall. Every builder who takes an autonomous system past the demo stage eventually hits it, and it isn’t a technical wall.
The part of the stack nobody puts in the architecture diagram
When you sketch out an autonomous system, you draw boxes. Sensors feed perception. Perception feeds a world model. The world model feeds a planner. The planner feeds actuators. There’s a feedback loop, some monitoring, maybe a human-in-the-loop escape hatch. Clean.
What the diagram never shows is the box labeled “permission to operate.” For a chatbot, that box is nearly empty — maybe some content policy and a rate limit. For a trading bot, it’s dense. For a two-ton vehicle moving through a city with no driver, it’s the largest box on the page, and it’s the one Waymo is now spending double to redraw.
Waymo has called for a federal framework to ease the rollout of robotaxis. Read that as an engineering requirement, not a press release. Right now the company is shipping into a patchwork where approval logic varies by jurisdiction. A single federal framework would collapse dozens of conditional branches into one. Any developer who has maintained per-region configuration files understands the appeal immediately.
Regulatory compliance as a system dependency
Waymo’s increased spending points at its focus on regulatory compliance, and I’d argue compliance deserves a spot in your dependency list alongside your ML framework and your message queue. It has versions. It has breaking changes. It has a maintainer you don’t control.
Here’s how I’ve started thinking about it when designing anything that acts without direct supervision:
- Treat the rules as a config layer, not hardcoded logic. If your bot’s allowed behaviors are scattered through your codebase, a rule change becomes a refactor. Pull them into a policy module you can swap.
- Log for auditors, not just for yourself. Debug logs answer “why did it break.” Audit logs answer “why did it decide.” Those are different questions, and only one of them gets asked by someone with subpoena power.
- Build a kill switch before you build the feature. The ability to stop cleanly is what makes deployment defensible.
- Assume geographic fragmentation. Design for the possibility that the same code must behave differently in two places. Waymo is spending millions to avoid this problem. You probably can’t, so plan for it.
Two companies, two theories of the same problem
The Waymo-Uber rivalry is interesting to me less as business drama and more as competing bets on where the hard part lives. Waymo built the driving stack from the ground up and now spends heavily to get regulators aligned with what it built. Uber built the demand layer, the marketplace, the app people already have on their phones. Both are converging on robotaxis from opposite ends, and both are now writing very large checks to policymakers.
What that tells a builder is that the technology question and the deployment question are separate problems with separate costs. You can solve one and remain completely blocked on the other. The doubled lobbying budget is Waymo saying, in the loudest available language, that the second problem is worth spending real money on.
What this means for the rest of us
Most of us aren’t putting cars on public roads. But the pattern generalizes down the scale. If you’re building an agent that sends emails on someone’s behalf, touches financial data, handles health information, or takes actions with consequences a person didn’t individually approve, you’re in a smaller version of the same situation. The technical build is the part you control. The permission to run is negotiated elsewhere, often by people who will never read your code.
This broader push to establish operational frameworks for autonomous vehicles will produce precedents. How those frameworks define responsibility, testing thresholds, and disclosure requirements will echo into how we’re expected to document and constrain autonomous software generally — including the far less dramatic bots I spend my days on.
So my practical takeaway is unglamorous. Write the audit trail. Isolate the policy logic. Build the stop button first. The engineering that survives contact with regulation isn’t the flashiest engineering — it’s the kind that can explain itself. Waymo can afford to spend its way toward a friendlier rulebook. Most of us just have to be ready for whichever rulebook shows up.
🕒 Published: