Autonomous Systems
Waymo vs Tesla: two autonomous driving architectures.
Waymo and Tesla are not simply choosing different sensors. They are choosing different operating models for autonomy.
Waymo behaves more like a bounded autonomous service: define the operating area, map it, instrument the vehicle heavily, validate releases, and publish driverless safety evidence. Tesla behaves more like a fleet-scale vision system: deploy camera-first software across consumer vehicles, learn from large volumes of supervised driving, and improve through software releases.
Both approaches are serious. Both use machine learning. The architecture question is not which brand sounds more ambitious. The question is where the system keeps knowledge, what can be inspected, and who or what validates the decision before the vehicle acts.
Practical Takeaway
The autonomy debate is really about evidence and control.
Sensor choice matters, but it is not the whole system. A vehicle also needs a world representation, prediction logic, planning controls, safety validation, logging, fleet learning, and a clear answer to responsibility. The more a system acts without a human backup, the more inspectability and release discipline matter.
Operating Model
Waymo and Tesla optimize for different deployment realities.
Waymo's public service is built around rider-only trips in defined operating areas. That changes the engineering posture. The system has to drive without a person in the driver's seat, so the safety case, remote operations, mapping process, and release controls become part of the product.
Tesla's broad production system is Full Self-Driving (Supervised). It can assist across a much wider consumer fleet, but the driver remains responsible. That changes what the safety evidence means. It is not the same claim as a driverless ride-hailing service.
This distinction is easy to miss. A supervised driver-assistance fleet can produce enormous data. A driverless service has to prove a narrower system can operate without immediate human control.
Do not compare the numbers without comparing the job.
Waymo's rider-only miles and Tesla's FSD (Supervised) miles describe different populations. One measures driverless service operation. The other measures a supervised assistance system across a large vehicle fleet.
Perception Inputs
Sensors decide how much of the world is measured directly.
A camera gives the system visual evidence. It can see lane markings, signs, lights, vehicle shapes, gestures, and road context. But distance and motion have to be inferred from image data, model outputs, history, and geometry.
Lidar and radar add different kinds of measurement. Lidar measures surface distance through returned light pulses. Radar helps with velocity and weather resilience. Audio receivers can detect signals the camera may not see, such as sirens.
Waymo's public material emphasizes multi-modal redundancy. Tesla's public material emphasizes camera-based vision and neural processing. The tradeoff is not purity versus intelligence. The tradeoff is measured redundancy versus a simpler, cheaper, more widely deployed sensor suite.
Camera-first approach
Lower hardware complexity and wide fleet compatibility, with more pressure on model inference and calibration.
Multi-sensor approach
More direct measurement and redundancy, with more hardware cost, maintenance, and integration complexity.
Vehicle design question
What needs to remain reliable when weather, glare, occlusion, grime, or sensor failure appears?
World Representation
The hard part is turning sensor data into a usable world state.
Raw pixels, radar returns, point clouds, and audio events are not enough. The vehicle needs a compact description of the world: lanes, vehicles, pedestrians, cyclists, traffic controls, road edges, emergency signals, and uncertainty.
Waymo's public architecture leans toward structured intermediate representations that can be logged, replayed, simulated, and checked. Tesla's public material describes networks that build a bird's-eye-view understanding from camera inputs and fleet-scale training.
For software teams, this is the important architecture lesson. A system that keeps an inspectable world state is easier to debug and validate. A system that relies more heavily on learned internal representations may capture nuance that is hard to define manually, but it can be harder to explain after a failure.
{
"frame_id": "vehicle_run_01842:30291",
"inputs": ["camera_front", "camera_left", "radar_front", "map_context"],
"world_state": {
"ego_lane": "mapped_lane_12",
"objects": [
{"type": "cyclist", "bearing": "front_right", "confidence": 0.91},
{"type": "vehicle", "bearing": "front", "confidence": 0.98}
],
"uncertainty": ["cyclist_intent", "occluded_crosswalk"]
},
"required_review": false
}Prediction And Planning
A safe vehicle plans for more than one possible future.
Traffic is not deterministic. A cyclist can stop, turn, drift, or continue straight. A pedestrian can hesitate. A driver can run a light. A construction worker can wave traffic into an unusual path.
A useful autonomy stack carries uncertainty forward. It should score multiple futures, choose a conservative trajectory, and reject plans that violate safety rules. The planning layer is where model output becomes physical action.
This is also where validation matters. A generated path may look reasonable to the model but still fail a rule about clearance, speed, comfort, legal behavior, or emergency response. Strong systems separate proposal from approval.
A model should propose. A safety layer should constrain.
This is the same pattern HerbDev uses in production AI workflows: let the model handle messy perception or judgment, then wrap it in deterministic checks, logging, escalation, and human ownership where needed.
Safety Evidence
The safety reports answer different questions.
Waymo's Safety Impact hub reports rider-only miles with no human driver and compares crash outcomes against human benchmarks in its operating areas. That is evidence about a driverless service inside specific geography and operating conditions.
Tesla's public safety report for FSD (Supervised) presents collision reductions for supervised operation and describes telemetry gathered across its connected vehicle fleet. That is evidence about a driver-assistance system used under driver responsibility.
Both can be useful. They should not be flattened into one leaderboard. The right question is: what was the system asked to do, under whose responsibility, in which operating environment, and with what measurement method?
HerbDev Connection
Organic Vision is the practical research bridge.
Organic Vision is HerbDev's documentation and research area for mobile and vehicle-oriented computer vision workflows. It is not an autonomous driving system, and it should not be treated as one.
The connection is architectural. Vehicle vision work still has to solve capture, annotation, object review, telemetry, uncertainty, model disagreement, dataset quality, and human validation. Those are the same kinds of problems that show up before any responsible vehicle AI system can be trusted.
If a product is intended for vehicles, drones, field review, or external-camera workflows, the Organic Vision documentation is the place to study how HerbDev thinks about evidence, labels, review loops, and practical computer vision implementation.
Use it for
Research workflows, dataset review, camera capture, annotation, and evidence management around vision systems.
Do not use it as
A substitute for an automotive safety case, certified autonomy stack, or production driver-assistance system.
Best next step
Review the Organic Vision documentation before designing a vehicle-facing AI workflow.
Organic Vision documentation
Use the Organic Vision documentation linked below as the practical follow-up for vehicle-oriented computer vision research, evidence handling, and review workflows.
Builder Lessons
Autonomous systems are release systems, not just models.
The practical lesson for AI developers and technical decision makers is simple: do not start with the model alone. Start with the full operating loop.
Define the input sources, the representation contract, the uncertainty model, the planner, the validation layer, the logging format, the replay process, the release gate, and the human responsibility boundary.
The more physical consequence the system has, the more the architecture needs boring discipline: clear constraints, measurable evidence, reproducible tests, documented limitations, and a way to stop the system when confidence is not high enough.
Inspectable state
Keep enough structure that decisions can be reviewed after the fact.
Scenario replay
Save hard cases and rerun them before model, prompt, or planning changes ship.
Responsibility boundary
Make it explicit whether the user, operator, safety driver, remote team, or system owns the next action.
Related Reading