Hardware-in-loop dev with agents

The hardware gap

Claude Code can iterate on firmware at machine speed. It can debug a calibration algorithm, propose new sensor thresholds, and rewrite the HX711 ADC sampling routine faster than any human engineer working alone. What it can’t do is plug a bag into a board and throw it.

This asymmetry is the structural challenge of hardware-in-loop development. The agent can run Loop 2 — algorithm iteration on collected data — hundreds of times per hour. Loop 3 — ground-truth validation against physical hardware — requires a human hand, a physical board, and real sensor output. Teams that don’t separate these loops waste both: the agent sits idle waiting for hardware presence, or the human runs Loop 3 dozens of times on firmware that Loop 2 would have eliminated.

The Quantum Caddy smart board project makes this concrete. The scoring system targets 97–99% accuracy through triple-layer sensor fusion: RT-DETR-S v10 CoreML CV pipeline on the Jetson Orin Nano (vision layer), HX711 ADC with 4x 50kg load cells in a Wheatstone bridge configuration (pressure layer), and IR break beam (tertiary confirmation layer). Building and calibrating this stack required a structured approach to which parts AXIOM could iterate autonomously and which required physical hardware presence.

Three loops, one pipeline

Hardware-in-loop development has three loops that operate at different speeds and require different resources. The discipline is to run each loop as much as possible before escalating to the next.

The compound discipline: collect once (Loop 1), iterate many (Loop 2), validate gate-only (Loop 3). Every Loop 3 run that produces a failure should feed back into Loop 1 — collect more data for the failure condition — before returning to Loop 2 for further iteration. Loop 3 is not a debugging loop; it’s a gate.