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.

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.

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?

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.

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.

When I let an agent write too much of the structure, the code may work, but a week later every small change starts with "where did it put that?"

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.