Loading today’s stories
Build1 distinct publisher3 min readPublished
An embedded loop stalls wherever a human has to press power and read serial, so this build puts an Orange Pi in that seat and gives the agent one flash command that boots over USB and writes the eMMC.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A build artifact says nothing about a board until somebody sets the boot mode pin, powers it on, and reads the serial console [11]. In this rig an Orange Pi 3 LTS does the first two through two small transistor circuits, and holds the USB link and the console on the other side [3][4]. That is the whole trick. Everything else is packaging.
The packaging matters, though, because of where these sequences break. cm5lab's flash command boots the CM5 through USB, exposes the eMMC, writes the image, and restarts the board from the new image [6]. Four operations behind one call [7]. Split them across a human and a shell and every intermediate state becomes a place the loop can stall until someone notices. Bundled, a failed attempt is a non-zero exit and a log, which is the same shape of result an agent already knows how to iterate on [5].
What makes this more than a flashing station is the read path: a progress endpoint on port 12368, container listings, per-container logs, and arbitrary commands run on the device [9]. The author's first agent-posted revision failed even though the source looked fine and the container ran on the development machine [12]. On the CM5 the application started and then stopped, because an assumption in the init script was not true there [13]. The agent read the container log, edited the init script, rebuilt the export, and posted again [14]. Sometimes it chose a cold boot, and sometimes a full reflash, because state left by the previous test was not trustworthy [15]. That decision, whether the environment under test is still worth believing, is the one you normally keep for yourself.
The BLE WiFi provisioning bug is the clearest evidence for the design. The CLI asked D-Bus for the wrong ConnMan bus name, the request failed, and the error was swallowed [21]. It did not appear on the development machine, and it did not appear on a board that had already connected to WiFi [20]. No amount of source reading finds that. It is defined by device state.
For the pattern to transfer, your target needs a recovery boot path you can select electrically, storage a host can write while the board is held there, and a console you can read during boot. The CM5 has all three [3][6]. A microcontroller with no USB recovery mode does not, and the fixture becomes a bigger project than the feature.
The account also carries no timings. There are no durations for build, flash, or boot, only that a reflash "was slower" and was still just another command [16][23]. So you cannot price attempts per hour from this, and attempts per hour is what decides whether an agent grinding through several tries in one session [17] is cheaper than you doing two carefully. One rig drives one board, and the author is candid that it is not a pretty lab, with wires and a separate power supply behind the command interface [22].
In my context, shipping an OS image plus containers to a fleet, the marginal wire is cheap next to sitting at the bench for each iteration. The alternative ending, in the author's words, is "The change is ready. Please flash the board and tell me what happens," which he calls code generation rather than a development loop [18].
Ranked by verification strength, evidence, and original report placement.
The author built a small lab around a Raspberry Pi Compute Module 5 with the purpose of giving an AI coding agent a feedback loop that included the real hardware, not a better flashing station.
The setup has a CM5 on its IO board and an Orange Pi 3 LTS connected to it.
The Orange Pi controls the CM5's power button and boot mode pin through two small transistor circuits.
The Orange Pi also connects to the CM5 USB port and the serial console.
The software side is cm5lab, which turns the physical actions into commands: the agent can ask the lab to power cycle the board, put it in USB boot mode, or flash a new image.
The flash command does all the steps together: boot the CM5 through USB, expose the eMMC, write the image, and restart the board from the new image.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Thirteen tasks green, then "give up (Recommended)" on the one that needed understanding1 distinct publisher
build
Green pipeline, wrong product: the checks proved the PDF rendered, not that anyone wanted it1 distinct publisher
build
Grill the plan first: a narrow interrogation step for agent-assisted builds1 distinct publisher
build
The laptop the agent replaced was a CI runner: an Android release driven from a phone browser1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One bench, one witness
The technical specificity is real — you do not invent "the CLI asked D-Bus for the wrong ConnMan bus name and the error was swallowed" — and that kind of detail is the strongest thing this reporting has going for it. But nothing is checkable. There is no repository to open, no log excerpt, no timing, and no second pair of eyes on the board; the whole account is one engineer describing his own desk after the fact.
A single desk
Credit where it is due: the rig was pointed at shipping features, not a demo — BLE provisioning, ConnMan scan behaviour, reconnection after reboot, then the hub agent. That is genuine use. It is also exactly one board, one author, and one project, with no other team, fork, or user named anywhere.
Restrained, and still unproven
Almost nothing is oversold. The author volunteers that the lab is ugly, that the agent missed fixes, and that reflashing is slow. The small overhang is one line doing a lot of work: that without the bench the session would have been "code generation, not a development loop." No unassisted session is shown for comparison, and with no cycle times at all, the reader cannot tell whether the loop is fast enough to matter or merely possible.
His own stack on the bench
Read the tooling and the interest is visible without anyone hiding it: cm5lab is the author's own, and the loop runs on meta-pantavisor, Pantavisor revisions, pvr, and a hub with an API — a stack he writes about as "we." That is a builder showcasing what he works on, which shapes which bugs get told as triumphs. Set against that, there is no pricing, no product pitch, no call to adopt anything, and the failures are told plainly.
Enough to copy, not to cite
We are fairly sure what the author built and moderately sure it worked as described — the details are too particular and too unflattering to be decoration. We are much less sure the loop generalises past this desk, and with a lone self-published account, no measurements, and no second observer, that is as far as the material lets anyone go.