Edward Viaene

The through-line

Across these sources, Edward Viaene is building a hardware-in-the-loop testing platform, BenchPod, and treating AI agents as active participants in that build rather than as code-completion tools. Early posts focus on getting the hardware itself right, chip selection, PCB bring-up fixes, cost tradeoffs, and by mid-2026 the emphasis shifts to letting Claude Code and MCP-connected agents actually flash firmware, configure ADC/DAC, drive the FPGA and run end-to-end hardware tests through BenchPod's own API [2][12]. The recurring preoccupation is repeatability: capturing real failure modes (a stalling step motor, a solar panel's I-V curve, a fault waveform) so they can be replayed and tested against firmware behavior on command [5][1][3].

Over time the framing hardens from "AI helps me code" toward "AI operates the bench": by July 2026 he logs 167 hours of Claude Code pairing directly with hardware, building the test device and then using it to test the device under test [2], and describes this explicitly as "Building The Machine That Builds Machines" [2].

On AI operating the hardware

Viaene's clearest claim is that agentic AI has moved past generating smarter test cases into physically controlling test equipment: "'AI-assisted testing' used to mean smarter test case generation. Now it means an agent that can physically control your device under test" [12]. BenchPod exists to make that possible, exposing "a hardware control API over MCP, which means any MCP-compatible agent (including Claude) can drive it directly" [12], and in his own account it "built the test device (BenchPod) and then used it to test the Device Under Test: flashing firmware, configuring the ADC/DAC, driving the FPGA, and running end-to-end hardware tests, all via tool calls" [2]. He is also candid that this isn't magic: a Claude MCP session on the v1 board "didn't finish in one go because I had to tell it not to use the NRST pin" [12].

He extends the same trust to AI for pure software problems outside hardware control, describing a Linux/GPIB driver failure where Claude Opus kept blaming the hardware until he asked it to write a fresh implementation instead: "20 minutes later, it started to read the measurements over USB from the Multimeter using pure Python and pyusb. Took me less time to write a driver than to get the actual driver working somehow" [7].

On repeatable failure-mode testing

A second theme is that hardware bugs are only useful if they can be captured and rerun. Talking through step-motor stalls, he asks "How fast can the software respond to a failure?" and notes that once a firmware fix exists, "we could now test whether the timing of the firmware was as expected, and whether it stays like that, by writing a CI test that covers this" [5]. Some failures are nearly invisible in the field: "a stall that only shows as a small current increase, but wasn't captured by the firmware," and his answer is to save and replay the capture [5]. This depends on hardware that can sample multiple domains on one clock and stay attached indefinitely: "digital + analog captured together, on hardware cheap enough to leave permanently wired to your target" [6], and BenchPod is pitched as running "DAC, ADC, and Logic Analyzer at the same time within ±20ns (with only a $100 BOM...)" [3].

On cost and tradeoffs in hardware design

Viaene repeatedly justifies component choices by total system cost rather than sticker price. Moving the orchestrator MCU, he writes: "The chip price looks like a big jump, but once you factor in the external flash, external crystal, SMPS inductor, and the W5500 you'd need for Ethernet, the real difference is smaller than it appears" [9]. On routing constraints from a large MCU package, he still concludes "To keep it affordable, it's still better than going to more layers or a bigger board, though" [11]. He's also self-critical about last-minute changes: "most of my mistakes come from quickly adding something just before sending it for manufacturing," citing a wrongly-oriented TVS diode and a boot button placed too close to SWD on the v2 board [8].

On simulating real-world inputs

For EPS testing he takes the position that if the right stimulus source doesn't exist, build it: "I don't have a current source, so I'm building one" [4], using an op-amp and MOSFET to emulate a solar panel's voltage and current behavior, including sunrise, clouds, and shadows [4]. He treats component failures in this rig as data, not just setbacks: "went through 2x OPA2192s, likely killed by feedback-loop spikes outside spec" before swapping to a TLV9151 [1], and frames the payoff as closing the loop entirely in software: "we now have enough to build an I-V control loop in software. We'll drop voltage as current approaches the I-V knee" [1].

From the stage

In the demo material, separate from the BenchPod/EmbeddedCI posts, Viaene teaches Go networking fundamentals rather than hardware testing. He walks through Go 1.22's net/http wildcard routing, showing that developers can now "extract wildcard values using request.PathValue()" without third-party packages like Gorilla Mux or Gin [13]. He also goes underneath the standard library entirely, building an HTTP server with net/http and then "constructing HTTP requests manually using raw TCP sockets to understand the underlying protocol mechanics," using telnet to craft a GET request by hand [14]. A third demo shows him using Go to launch containers directly via the containerd API on Lima [15], again favoring working with an API at a low level over reaching for a higher-level tool.

Takeaways

• BenchPod is built so pytest, ChatGPT, or Claude can control test hardware directly via API/MCP/SDK, not just generate test code [11][12].
• When agentic AI hits a wall (an unsupported GPIB driver), the fix that worked was asking it to reimplement the protocol from scratch in Python/pyusb rather than chase the vendor driver [7].
• Captured hardware failures (step-motor stalls, power loss events) should be saved and replayed so firmware timing can be checked repeatedly in CI [5].
• When picking an MCU, compare total system cost including external flash, crystal, and Ethernet chip, not just the chip's sticker price [9].
• Last-minute board changes before manufacturing are a recurring source of bugs (misoriented TVS diode, boot button placement) [8].
• To simulate real-world power sources for EPS testing, build the current source yourself with an op-amp/MOSFET feedback loop and monitor it with a shunt resistor and INA282 [4][1].