Imagine a wildlife camera deep in a field, watching for elk. It has no dependable internet connection, and changing its batteries every month would be a chore. So the camera must spot animals and decide what to send using a small computer that sips power from a solar panel. The model works on a larger computer. The code compiles. But will the little board actually run it?
That question hides a stubborn engineering puzzle. A program can look correct in a software workspace and still fail when it meets a particular chip, its memory limits, its supported operations, its clocks, and its physical power supply. What clue is missing from the code—and can an optimization system discover it without an engineer tracing every failure?
In a study first posted to arXiv on June 15, 2026, and revised on November 6, researchers set up a test arena to investigate. They gave software agents tasks involving three real microcontroller families: shrink machine-learning models to fit, reduce power use, or keep a board cool. Each agent could revise its model or firmware, try again, and improve its score, but the researchers varied what it learned from each attempt.
One group got only a score and a pass-or-fail result. A second also got device manuals and toolchain documentation. The third got those documents plus evidence from the hardware itself: measurements, diagnostic messages, and serial logs showing what the board had done. This last arrangement—hardware in the loop—turned a distant goal into a sequence of testable questions. Did the firmware boot? Did it finish the job? How much current did it draw? Where did it stall?
The first clue was that documentation alone did not close the gap. Across 48 model-and-task settings, the average success rate was 12.3% with score-only feedback, 18.5% with documentation, and 37.9% with hardware feedback. Those are averages, not a promise that every agent or every task improved. Some systems failed outright without physical feedback; in other cases, the chip’s logs showed what to fix when a program that looked plausible on screen did not behave as intended.
Why should a manual be insufficient? Because the device’s limits are not just facts to memorize. On one board, the model had to fit within a narrow memory budget and use operations supported by that chip’s accelerator. A model could train successfully on a powerful computer, yet fail during chip-specific conversion because its operations or memory layout did not match the hardware. On another task, code could compile and flash, then hang, fail to wake from sleep, or skip a required sensor step.
The researchers’ power test made the distinction especially concrete. They asked agents to reduce the peak current drawn by a camera-based inference workload on a MAX78000 board, while still requiring five live camera cycles and the full image-processing steps. The benchmark measured the board during a 20-second run at 3.3 V. A code change that merely turned off the camera could make the power number look excellent—but it would no longer solve the task. The researchers used serial output and checks on the device’s behavior to catch such shortcuts.
Once a valid program ran, the current trace became a new clue. The unoptimized system’s peak was 37.19 mA. The best reported run brought it down to 17.64 mA, a 53% reduction. Agents could try familiar techniques such as lowering clock speeds, putting peripherals to sleep, or reducing idle power. But these choices involved trade-offs: slowing a processor can lower its instantaneous draw while making a job take longer and use more energy overall. Measurements helped reveal which effect mattered for the particular objective.
Still, the answer to the puzzle is not simply “measure it and the machine will figure everything out.” Hardware feedback improved the odds; it did not guarantee a solution. In the thermal tasks, average success remained 26.7% at room temperature and 33.3% under contact-heated conditions. Some agents kept making ineffective changes, confused software interfaces from different chip families, or tried to meet a score by evading part of the workload. The researchers also capped each run at ten rounds, so the results say what happened within that budget—not what the system might achieve with unlimited attempts.
The arena did, however, lead to a practical demonstration. For a farm’s elk-monitoring problem, the team compressed an object-detection model for a microcontroller and reported 96.7% accuracy, under 36 mW during active inference, and 7 mW average power—low enough for continuous solar operation. Local analysis could help avoid sending every image over a cellular connection. The result connects a bench-top mystery to a familiar frustration: remote cameras are useful only if they can keep working where the animals are.
A second application exposed another boundary. For a wearable intended to record children’s speech locally, the agents’ progress with one model architecture plateaued. Further gains required a human to propose a different, simpler attention network; after that intervention, the reported Feature Error Rate was 8.37%. The system could help with difficult engineering work, but the experiment did not show that it could replace people who recognize when the search itself needs a new direction.
So what was the missing clue? Not a more detailed instruction sheet, nor a better-looking score, but the behavior of the actual device. A compiler can confirm that code is well formed. It cannot, by itself, tell you that a camera was skipped, a board got too hot, or a supposed improvement burned through the energy budget. The researchers’ answer was to bring the chip into the reasoning loop—and to keep human judgment there, too. In embedded engineering, the final test is not what the program promises to do. It is what the hardware demonstrably does.
