For most of the past decade, a self-driving car was built like a relay race. One module saw the world, another predicted what other road users would do, another planned a path, and another turned that plan into steering and braking. Engineers wrote rules for each handoff. It worked well enough to produce impressive demos and deeply frustrating edge cases. Now several teams are reconsidering the whole design, and a robotaxi rebuild around a single model has become a serious option.
The modular stack
In the classic setup, perception software identifies objects such as cars, cyclists and traffic cones from camera, radar and lidar data. Prediction estimates where they are headed. Planning chooses a route and speed. Each stage hands a cleaned-up summary to the next one.
The strength of this design is that you can inspect each piece. If a car brakes for no reason, engineers can check whether perception hallucinated an obstacle or planning was too cautious. The weakness is that information gets squeezed at every handoff. Subtle cues that don’t fit the predefined categories, like a driver’s slight lean toward a lane change, are discarded. And the long tail of unusual situations keeps demanding new hand-written rules.
The learned approach to a robotaxi rebuild
An AI-centered stack uses large neural networks trained on driving data to map sensor input more directly to driving decisions. Instead of encoding what a double-parked delivery van means, the system learns from many examples how skilled drivers handle one. Some designs are fully end-to-end, going from raw sensor data to controls. Others keep a modular shape but replace the components with learned models trained together.
The appeal is scaling. More data and compute tend to improve neural networks in a fairly predictable way, whereas adding hand-coded rules runs into diminishing returns and tangled interactions. The same trend lifted language and image models, and driving teams hope it applies to the road.
A simple scenario shows the difference. A cyclist signals a turn while a delivery truck blocks half the lane. In a modular system, one engineer might add a rule for cyclists and another for double-parked trucks, and the combination still surprises them. A learned system has seen thousands of similar scenes and responds as a whole. That does not guarantee the right answer, but it removes the seams where rules collide.
The catch: proving it is safe
A learned system is harder to explain. If it makes an odd decision, you cannot always point to a line of code. That matters for regulators, insurers and the public. Safety teams answer this with layers: large-scale simulation, closed-course testing, monitored road trials, and often a separate rule-based safety checker that can override the model in dangerous situations.
Data quality is another issue. A model trained mostly on sunny highways will struggle in snow or dense downtown traffic. Getting enough rare, hard examples is expensive, which is why companies use simulation to generate difficult scenarios and why they value time on real streets so highly.
Why a company might attempt a robotaxi rebuild
A robotaxi rebuild is a heavy decision. It means admitting the original architecture hit a ceiling, and it risks throwing away years of work. But if a team believes the field’s best results now come from learned systems, keeping the old design may be riskier than starting again. Sometimes a reset also follows a change in funding, partnership or strategy, which forces a company to be clear about what it is building and who it is building it for.
Reboots also tend to shorten the timeline to a commercial launch in a narrow area. Rather than promising to drive anywhere, a team can aim at a specific city or district, learn it thoroughly, and expand outward.
Safety is the benchmark that matters most, and the habit of looking at records applies to every autonomy story. Our piece on why carmakers embrace hybrids shows how industry hedges look when plans are uncertain, while the look at buying an e-bike covers a very different kind of mobility choice. The basics of the field are summarised in the article on a self-driving car.
Another practical point is compute. Training a large driving model takes a great deal of processing power, and running it in the car needs a dedicated onboard computer. A robotaxi rebuild therefore touches hardware plans, not just software, which is one reason such moves take longer than their announcements suggest. Teams must also decide how much of the old code to keep as a safety net. A careful robotaxi rebuild keeps rule-based checks running alongside the learned model for exactly this reason.
For riders, little changes on day one. The car still pulls up, opens the door and drives. The difference, if the bet pays off, shows up later as fewer awkward hesitations and a wider range of streets it can handle.
What to watch for in a robotaxi rebuild
- Driverless without a safety operator: a real milestone, which differs sharply from a test car with someone behind the wheel.
- Operational design domain: where and in what weather the service runs.
- Remote assistance: how often humans step in to help the vehicle, and how that is disclosed.
- Unit economics: vehicle cost, cleaning, charging, insurance, and the number of rides per day.
Target dates in this industry have slipped many times, so treat any promise of a launch year with healthy caution. The more valuable evidence is a steady record of miles, incident reports and expanding service areas.
The shift toward learned driving is real, and it may well prove the right bet. Just remember that a better driver on paper still has to earn trust one uneventful ride at a time.
Image: Grendelkhan / Wikimedia Commons, CC BY-SA 4.0.
