Small caution from using agents here: the useful chart is the one generated from code, tests, or traces, not the one the model draws from its own explanation.
I've had models produce very reasonable Mermaid diagrams that matched the intended design but not the actual program. It felt helpful until I realized I was reviewing the plan twice and the implementation zero times.
For PRs I'd rather render the diagram from the executable state machine itself — at least then drift in the chart means drift in behavior, and you can't review one without the other.
+1 to the CI/isolation point. That is the part that makes these setups work for me too: make the failure cheap to reproduce, make stderr visible, make the agent rerun the same command after the patch. A lot of bad agent behavior is really just "it never got a clean signal".
The part that still bites me is across sessions. A tight loop fixes this run, but next week the agent can walk into the same rake again: same wrong import path, same misuse of an internal API, same CI-only dependency issue. After patching the same class of failure a few times, I started writing those down outside the chat context so the next run sees the failure pattern before it guesses.
Built a ROS 2 cycling helmet. IMU + GPS, but we didn't fuse them, on purpose.
Speed is just haversine between GPS fixes. IMU only does turn detection and crash/fall. No EKF. Under bridges or urban canyons I'd rather have speed go stale and drop to zero after a few seconds than have a filter keep extrapolating from IMU bias and tell the rider they're still doing 20 km/h.
Other thing: safety stays below ROS. Crash/fall runs on the MCU next to the IMU; ROS just subscribes to /safety/event. Pi reboots, helmet still alarms.
How does FusionCore handle long GPS outages: gate the output, or keep predicting?
Yeah, this is pretty common once a device has any real DSP in it. There's usually some stripped-down Linux on an ARM SoC underneath, and the vendor BSP just happens to ship with sshd on.
Not necessarily malice, more like nobody on the audio side really owns the rootfs.
The big question is whether it's only listening on the USB-side network, or on the actual LAN. First one is annoying. Second one would actually bother me.
I don't think SSH vs OpenTofu is the core issue here.
For agents, declarative plans are still valuable because they are reviewable. The interesting question is whether exe.dev changes the primitive: resource pools for many isolated VM-like processes, or just nicer VPS provisioning.
This matches what I've seen too — the hallucination gets much worse when the loop has no external verifier. "Does this board work?" has no ground truth inside the model, so it defaults to optimistic narration.
What OP is doing here is actually the mitigation: SPICE + scope readout is a verifier the model can't talk its way past. The netlist either simulates or it doesn't, the waveform either matches or it doesn't. That closes the feedback loop the same way tests close it for code.
The failure mode that remains, in my experience, is a layer down: when the verifier itself errors out (SPICE convergence failure, missing model card, wrong .include path), the agent burns turns "reasoning" about environment errors it has seen a hundred times.That's where most of the token budget actually goes, not the design work.
I've had models produce very reasonable Mermaid diagrams that matched the intended design but not the actual program. It felt helpful until I realized I was reviewing the plan twice and the implementation zero times.
For PRs I'd rather render the diagram from the executable state machine itself — at least then drift in the chart means drift in behavior, and you can't review one without the other.