Every autonomous driving system has two sets of parameters. The first set lives in the model weights, tuned by gradient descent against millions of miles of driving data. The second set lives in municipal code, state statute, and permit conditions, and it gets tuned by lawyers and lobbyists. The first set decides what the car can do. The second decides what counts as a legal maneuver, a legal vehicle, and a legal absence of a human being in the driver’s seat. Only one of those sets can be updated with a training run.
That is the frame I keep coming back to with the news that Waymo has doubled its lobbying spend as it squares off against Uber, with the two companies together spending more than $15 million this year lobbying New York politicians. Read as a business story, it is a familiar tale of two well-funded rivals buying influence. Read as an engineering story, it is something more interesting: an admission that the hardest constraint on a driving agent right now is not perception or planning. It is the specification.
The operational design domain is a legal object
Anyone who has built an autonomous system knows the operational design domain, the ODD, is where the real work hides. It is the declared envelope in which the system is claimed to be competent: which roads, which speeds, which weather, which times of day, which failure modes trigger which fallback. Everything downstream flows from it. Your validation plan is an ODD coverage argument. Your data collection strategy is an ODD sampling strategy. Your remote assistance policy is an ODD escape hatch.
What engineers sometimes miss is that the ODD is not purely a technical artifact. Its outer boundary is drawn by regulators. A rule about whether a vehicle may operate without a safety driver, or on which classes of street, or under what reporting obligations, does not merely permit or forbid a deployment. It reshapes the distribution of data the fleet will ever see, which reshapes what the model learns, which reshapes where the system is competent next year. Policy sits upstream of the training loop. Money spent influencing policy is money spent editing the spec that everything else is validated against.
Seen that way, a doubled lobbying budget is not a distraction from the technical program. It is a line item in it.
Two architectures, two very different asks
The reason this particular fight is worth studying is that Waymo and Uber are not symmetric competitors wanting the same rule written slightly differently. They are different architectures, and architecture determines what you want from a regulator.
Waymo owns the whole stack: sensors, compute, driving policy, fleet operations, depots, remote support. That vertical integration is expensive and slow to scale geographically, because each new city is a new engineering and operations commitment. What a vertically integrated operator needs from policy is permission with specificity. A clear pathway to driverless operation in a defined area, with defined reporting, that it can plan capital against. Ambiguity is the enemy, because ambiguity cannot be validated.
Uber is a marketplace. Its core asset is demand aggregation and dispatch, and its strategy in autonomy has been to sit above the driving stack rather than build the whole thing itself. What an aggregator needs from policy is interchangeability: rules that treat autonomous supply as another category of supply that can be routed on a network. Critics have accused Uber of pushing for regulatory outcomes that serve its own position, which is roughly what you would predict from the structure. If your value comes from being the layer that matches riders to whatever vehicles exist, you want the layer beneath you to be a commodity with low switching costs.
Those are not the same bill. One party benefits from rules keyed to a specific validated system in a specific area. The other benefits from rules keyed to the network. $15 million in a single state is what it costs to argue about which abstraction the law should recognize.
What this tells us about the state of the technology
Here is the read I find most useful. Companies do not spend heavily to influence rules for capabilities they cannot yet ship. Lobbying intensity is a lagging indicator of technical readiness and a leading indicator of scaling intent. When the binding constraint was the driving policy itself, the money went into sensors, simulation, and headcount. When the money starts moving toward legislatures, it suggests the teams involved believe their systems clear the bar in at least some ODDs and that the next unit of growth comes from expanding the legal envelope rather than the technical one.
For those of us who care about agent architecture, that is a shift worth tracking. It means the interesting design questions are moving to the boundary between the agent and its governing rules: how you write a spec a regulator can audit, how you demonstrate competence inside a declared envelope, how you handle the edge where the envelope ends. Those are engineering problems dressed as policy problems. The companies spending the most seem to understand that. The rest of the field should catch up.
🕒 Published: