What should we test before flashing AI-generated firmware?

Start with the datasheet contract: device address, register widths, signed values, byte order and permitted bus speed. Test the conversion function with zero, full-scale and negative raw values where the sensor supports them. A plausible temperature is a weak test because swapped bytes can sometimes produce believable numbers. Mock the bus separately so a conversion test cannot hide an incorrect transaction sequence.

The failure path deserves its own tests. What happens if the address is not acknowledged, a read returns too few bytes, or the bus remains busy? Put a finite timeout around communication and carry an explicit validity flag alongside the reading. Reusing the last sample may be acceptable for a display, but an actuator needs a defined response to stale data.

For the output, inspect the reset state before application code runs. Firmware cannot guarantee an off state during boot if the circuit leaves the driver input floating. Check the schematic pull resistor, then observe the pin during power-up, watchdog reset and programming. Keep the actuator disconnected for the first tests and verify the control signal with a scope or logic analyzer.

Also pin the compiler and library versions and retain the tests with the driver. If an assistant rewrites a function later, rerun the same boundary and fault cases. Simulation is useful for repeatability, but it does not prove the real board has correct pull-ups, power integrity or voltage levels. The release documentation is useful context for the new tooling, not evidence that generated code has passed those checks.