One of our clients ran over 1,200 hours of hardware-in-the-loop testing in six weeks. Here's what happens when a hardware team stops rationing its testing.

In the last six weeks, one of our clients ran over 1,200 hours of hardware-in-the-loop (HIL) testing. That's more than half a year of an engineer's workdays doing nothing else. That's 2,700+ test runs and over 15,000 individual parameters checked, fully autonomously, on real hardware.
They're an established manufacturer with a great team and a real lab, but they've never been able to test anywhere near this much. Honestly, almost nobody can.
Testing gets rationed
Every hardware company we talk to wishes they tested more. The problem is that every hour at the bench is an hour not spent building the product, so you test hard right before a release and kind of hope for the best the rest of the time.
And pretty much everyone has that file - the one nobody wants to touch, because the only test it's ever had is "well, it worked when we shipped it," and nobody can justify a week at the bench to find out what else breaks if they change it. (Some teams have a whole folder.)
What happens when nobody has to sit at the bench
Once the tests didn't need someone standing next to them, they just kept running. Endurance soaks ran for days - one ran 21 days straight (nobody is sitting next to a bench for three weeks taking notes!). When soak time became the bottleneck, they added another bench and ran them in parallel.
On one of their boards, our agent rewrote the firmware stack from scratch. Then it put that firmware on the real hardware, wired into the bench with a power analyzer, and ran power load sweeps. It came back with changes that cut both sensing latency and power consumption - already tested, ready for production, and with those tests sitting in CI so every future change gets held to the same bar.
What this means for hardware
AI has made writing code almost free. Software teams get to cash in on that right away, because every change they make already gets tested automatically. Most hardware teams don't have that. Their testing is still an engineer at the bench following a checklist, so an agent writing code faster mostly just gives that engineer a bigger pile to check by hand.
That's why we built BootLoop Develop and BootLoop Test to work together. The agent writes and changes the firmware and suggests new tests, and BootLoop Test runs them as a fully deterministic framework on the real board - so the thing deciding whether a change passed is never the thing that wrote it.
Code is cheap now. Once validating it is cheap too, hardware teams finally get to iterate as fast as software teams. If you want to see what that looks like on your hardware, book a demo.