Software that controls hardware is only as reliable as the conditions it was tested against. But comprehensive testing programs are usually time and labor intensive. When software updates or new adjustments need to be integrated on short notice, teams don’t always have the opportunity to anticipate or test every failure mode. Which makes the failures that surface where testing stopped hurt the most.

On October 4, Formula 1 ran into this issue as racers lined up in Sepang, Malaysia for the Bahrain Grand Prix. Heavy rain had already pushed the start back about 40 minutes. When the field finally rolled out behind the safety car, cars began to slow, bunch up and stop.

"I can't accelerate! It's not working, guys," Max Verstappen told his team. Lewis Hamilton's Ferrari similarly stalled: "I’m pressing the throttle and nothing’s happening!" Race control called off the start and sent the field back to the pit lane.

The cars themselves weren’t broken. But the software that runs them ran into a situation no one tested when F1 is becoming increasingly software-reliant. Catching these issues before the rubber quite literally meets the road takes a test regime that doesn’t force tradeoffs between speed or safety. This is a problem that is well understood in aerospace by the likes of SpaceX: software-defined vehicles require software-like testing routines to account for all edge cases.

Video: Why F1 Cars Suddenly Lost Power - What Really Happened In Sepang? by Through Goes Formula on YouTube.

What went wrong

2026 F1 cars draw much of their power from an electric motor. Software limits how much energy that motor can deploy. FIA single-seater director Nikolas Tombazis told The Race that "the software is developed by the FIA in collaboration with the teams." In the wet, the limit drops, and some sections of Sepang carry further limits.

Behind the safety car, some cars slowed almost to a standstill. With the turbo spooling down and the electric motor restricted, the software tripped a lockout where the neither the electric motor nor the internal combustion engine could deploy energy. As a result, multiple cars appeared to simply stall out on track. "That bug prevented the power from being redeployed, and for the cars to start again," Tombazis said.

The FIA wrote a fix in about 20 minutes, and teams installed it during the rain delay. Tombazis explained why the bug slipped through: "We didn't manage to test the software as extensively as we would have liked, because there's been very little wet running this year."

Photo: Rudy Carezzevoli/Getty Images

The failure case was never tested

While the incident is still under investigation, it is clear that unintended software behavior was the culprit. In its statement, the FIA blamed "an unprecedented combination of low engine speed, low-grip conditions, wet-weather energy management settings and the Sepang circuit's sector configuration." The same statement said the issue "had not been detected by the FIA or the teams during testing or during the laps to the grid."

That pattern is familiar. After two Boeing 737 MAX crashes, the US National Transportation Safety Board (NTSB) examined how the plane's MCAS flight-control software had been assessed. In their report, the NTSB found: "Neither Boeing's system safety assessment nor its simulator tests evaluated how the combined effect of alerts and indications might impact pilots' recognition of which procedure(s) to prioritize."

In both cases, the scenario that mattered most was the one testing left out.

The design assumed things would go to plan

Both systems were built around expected behavior. The lockout that stopped the cars at Sepang was a software safeguard against gaming the rules, such as artificially implementing traction control or implementing tricks to boost power output. The Race reported that it is a 60-second emergency lockdown that "had been imposed this year to prevent teams deliberately shutting down the MGU-K," the car's electric motor.

At Sepang, it caught cars that were simply crawling behind the safety car. Tombazis said the speeds were "far more low than you would normally do in such a test." The FIA called the result "an unintended loss of power for a number of cars."

Similarly, the 737 MAX was certified on the assumption that MCAS malfunction would be rare and that pilots would respond quickly to anomalies. Real crews, facing several alarms at once, did not. "We saw in these two accidents that the crews did not react in the ways Boeing and the FAA assumed they would," NTSB Chairman Robert Sumwalt said in the board's press release.

On the surface, a race car and an airliner don’t share terribly much in common. But in both cases, the interactions between hardware and software rested on assumptions the real world didn't follow. When the hardware met conditions outside previously defined bounds, the failure mode could not be anticipated by definition. Both the airplane and the car are vehicles on which people depend and in which people operate in the real world. Both are built on manufacturing and quality assurance practices that often concentrates testing into a distinct phase, which can’t always adapt well to new integrations or quick software updates.

Sepang got lucky

At Sepang, the cost was a delayed start. The two 737 MAX crashes killed 346 people. These events took place in unrelated industries, separated years apart, and with dramatically different outcomes. But both incidents share a familiar pattern: the failure surfaced where testing stopped.

The fix raises its own question. Motorsport commentator Gary Anderson put it this way: "what worries me more is that the regulation setter, the FIA, was able to come up with a software fix in a very short amount of time and install it in all cars without any depth of real-world testing. Then what other software gremlins are lurking in there, waiting to rear their ugly head?"

Aerospace has a name for closing that gap: test like you fly. As we've written before, the practice was "born from real mission failures where hardware encountered operational conditions for the first time in the field." In practice, it means writing down what the system should do as rules, then checking every test run, every vehicle, every new software update against them automatically. Such a paradigm refuses the tradeoff between speed and safety because every run is reviewed, including the ones no one had time to look at.

The lesson goes beyond aerospace

In any situation where software sits between an operator and a piece of hardware, this same risk is persistent. Closing that gap means testing across the full range of real conditions, not just the expected plan. It means testing like you fly: validating continuously against real telemetry, at every stage of development. We've written more about that approach in CI/CD for hardware: why the best teams never stop testing.

Consider what that could look like for a program like F1's. The behavior that failed at Sepang is simple to state. When a driver presses the throttle, the car should deliver power at all parts of the circuit and all portions of the race. The 60-second lockdown should fire only when a team deliberately shuts down the MGU-K. With Sift, engineers can codify expectations like these as Rules, in the language their team already uses, and check every test run against them automatically. A wet-weather run at walking pace that triggered a lockdown would be flagged as an anomaly, with the supporting telemetry attached, instead of waiting for someone to find it by hand.

The same rules apply to the fix. As we've written before, "Every hardware or software update is continuously evaluated against predefined rules." A patch written in 20 minutes could still be checked against every scenario the team has already codified before it goes onto the cars to make sure no further unintended consequences emerge.

Rules can't run a test nobody schedules. What they change is the cost of each test. When review is automatic, adding low-speed, wet-weather, and degraded-mode cases to the test plan no longer means more manual analysis. Teams can test closer to how they actually run.

If you're building hardware where software and the real world meet, we'd like to hear how you test it.