Claude Code for Hardware: Oscilloscope Feedback, SPICE, and a Smarter Workflow

What makes this demo interesting is not the circuit itself — it’s the workflow. Lucas Gerads is showing a more realistic way to use Claude Code for hardware: not as a magical circuit designer from a vague prompt, but as an agent with tools, immediate feedback, and structured access to real test equipment.

Instead of asking Claude to invent hardware from scratch in plain English, he connected it to an oscilloscope and a SPICE simulator, then used that loop to validate circuits, models, embedded code, and even data analysis.

Key Points

Gerads spent a few weeks experimenting with Claude Code for hardware development.
He found that prompting Claude in natural language to "write a circuit" works for trivial cases, but becomes awkward and unreliable for more complex designs.
His main insight: Claude Code works much better when it can get immediate feedback from tools.
He built a setup that gives Claude access to:
- a LeCroy oscilloscope
- a SPICE simulator
He says this is especially useful for:
- validating SPICE circuits and models
- embedded programming
- data analysis
The data-analysis use case was previously tedious for him, especially tasks like:
- normalizing time axes
- aligning measurement data
- comparing traces
The demo in the article is intentionally simple, because the point is the workflow, not the specific circuit.
He shares a few practical lessons:
- Claude cannot see your physical hardware setup, so don’t let it guess what is connected where.
- Keep Claude from using stale oscilloscope measurements.
- Don’t dump raw data directly into Claude’s context; store it in a file and let Claude access it indirectly.
For microcontroller work, he recommends:
- giving Claude an explicit pinout/pinmux map
- preparing a Makefile with clear commands like build, flash, ping, and erase
- making Claude rely on those commands instead of inventing them on the fly
He points to three repos related to the demo:
- lecroy-mcp for LeCroy oscilloscope control
- spicelib-mcp for wrapping spicelib
- rc-filter-demo-files for the demo setup

My Take

What strikes me is that this is a very Claude-native way to do hardware work: not “generate the answer,” but “close the loop quickly and let the model inspect outcomes.” I think that’s the real sweet spot for Claude Code in the physical world. Hardware is messy, stateful, and full of assumptions; tool access and verification matter more than elegant prompting.

I also like the honesty here. The article basically says: plain-English circuit design is limited, and guessing is dangerous. That feels right. I’d much rather give Claude a pin map, a build/flash workflow, and live measurements than hope it infers my lab setup correctly. In that sense, this is less about AI magic and more about disciplined automation — which is much more compelling.

The oscilloscope part is especially promising. I think there’s a lot of underrated value in letting Claude help with measurement interpretation, trace alignment, and repetitive analysis that humans tend to do by eye. That said, the warning about stale data is huge; if the tool chain isn’t strict, the model can confidently reason about the wrong measurement and waste your time. That’s not a Claude problem so much as a systems design problem.

What I’d actually try myself is the pattern, not necessarily this exact demo: expose hardware tools through MCP, keep the interfaces narrow, save raw data out of context, and make the model operate on files, commands, and verified outputs. I’d be curious whether this scales cleanly to more complex lab setups with multiple instruments and more failure modes. It probably does — but only if the tooling is as disciplined as the workflow Gerads describes.

The takeaway is simple: Claude Code becomes much more useful for hardware when it can measure, verify, and iterate. The interesting part is not replacing an engineer’s judgment — it’s making the tedious validation loop much faster and more reliable.