Every team flying PX4 or ArduPilot has software-in-the-loop simulation available. Very few use it for more than confirming that a build starts and the aircraft takes off. That gap is one of the cheapest wins available in flight software.
The manual sanity check
The common pattern: an engineer changes a controller gain or a mission behaviour, launches SITL, flies a short sortie, watches it look approximately right, and ships. The test exercised whatever that engineer thought to try, on that day, in the conditions the simulator happened to default to.
Nothing about that is unreasonable. It is simply not a test. It has no coverage definition, produces no record, and cannot detect that a change broke something fixed eight months ago by someone who has since left.
Regressions are found in the air
The consequence is that regressions surface during flight testing, which is the most expensive place to find them. A flight test day costs a crew, a site, a weather window and an airframe at risk. Discovering there that a previously-solved link-loss behaviour has returned is an expensive way to learn something a machine could have told you in ninety seconds.
The frustrating part is that the fix requires no new technology. The simulator is already there.
Scenarios as assets
What changes things is treating scenarios as versioned artefacts rather than as whatever was on screen. A scenario specifies the conditions: wind and gust profile, turbulence, sensor degradation, GNSS quality, link availability, terrain, payload state, and the expected outcome.
Once scenarios exist as files, three things follow. They run unattended, so the whole library executes on every change instead of the one case someone remembered. They accumulate, so every incident and every near-miss becomes a permanent scenario that can never silently regress. And they are reviewable, so an engineer can argue about whether coverage is adequate by reading it rather than guessing.
Diff against known-good, not against pass/fail
Flight software rarely fails a simulation outright. It usually degrades: the approach is a little less stable, the altitude hold wanders slightly more, recovery takes another second and a half. A binary pass/fail hides exactly the signal you want.
Reporting the run as a difference against the last known-good result surfaces degradation while it is still small. A gain change that costs half a second of settling time is worth a conversation. It is not worth an incident report six months later.
The awkward part
Simulation is only as good as the vehicle model, and a model that does not match the aircraft produces confident nonsense. This is the legitimate objection, and it is why simulation should draw its model from the same definition the design was sized against rather than from parameters typed in separately.
Even an imperfect model catches the class of failure that matters most here: logic errors, state-machine holes, and behaviour under conditions nobody thought to fly. Those do not require aerodynamic fidelity. They require the scenario to have been run at all.