[dead]
Show HN: SPICE simulation → oscilloscope → verification with Claude Code
21–30 of 46 posts
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#22Beware. I had Claude code with opus building boards and using spice simulations. It completely hallucinated the capabilities of the board and made some pretty crazy claims like I had just stumbled onto the secret hardware billion dollar project that every home needed. None of the boards worked and I had to just do the project in codex. Opus seemed too busy congratulating itself to realize it produced gibberish.
It's because you are holding it wrong!
--courtesy for all the LLM pushers so they don't have to bother commenting on this one
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#23[dead]
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#24Beware. I had Claude code with opus building boards and using spice simulations. It completely hallucinated the capabilities of the board and made some pretty crazy claims like I had just stumbled onto the secret hardware billion dollar project that every home needed. None of the boards worked and I had to just do the project in codex. Opus seemed too busy congratulating itself to realize it produced gibberish.
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.
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#25Beware. I had Claude code with opus building boards and using spice simulations. It completely hallucinated the capabilities of the board and made some pretty crazy claims like I had just stumbled onto the secret hardware billion dollar project that every home needed. None of the boards worked and I had to just do the project in codex. Opus seemed too busy congratulating itself to realize it produced gibberish.
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. Th…
What throws me about this comment is the missing space between the period and the T in the last sentence.
Did the model itself do that? Was it a paste error?
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#26Beware. I had Claude code with opus building boards and using spice simulations. It completely hallucinated the capabilities of the board and made some pretty crazy claims like I had just stumbled onto the secret hardware billion dollar project that every home needed. None of the boards worked and I had to just do the project in codex. Opus seemed too busy congratulating itself to realize it produced gibberish.
This week I tried to use Opus to analyse output from an oscilloscope and it was impossible to complete, because Python scripts (Opus wrote itself) were flagged for cyber security risk. Baffling.
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#27This is an interesting use case with Claude. It sounds like you took away some tedious work with the checking of waveforms, and you are able to speed up your design loop because of it.
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#28Hit this exact wall six months back building Claude Code stuff for KiCad review[1]. First pass let Claude read .kicad_sch directly via grep/read. It happily invented pin numbers that didn't exist. Rewrote it with Python analyzers that spit out JSON, now Claude just reads the JSON, problem mostly went away. Curious how spicelib-mcp handles models that aren't in the bundled library. Do you pass the .lib path as a tool…
very cool, im working on a similar kicad tool for dong the fully schematic generation and pcb layout using python generated by AI. Not quite ready to publish it yet, but im glad im not the only one who sees the potential of AI generated code + kicad
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#29Nice scope!
I had a similar experience with using Claude to automate circuit design/simulation/optimization and found that they are not good at it.
They are surprisingly good at taking raw files and describing what is in them, but they fall apart when trying to do anything other than design the simplest circuit. I think it is because they have no concept of the physics behind a circuit, so they cannot make changes that a designer would make. For optimizing a circuit using, say, an EM simulator, they don't know what to tweak and how to tweak it. In the end, I had to write a script to talk to the simulator and create a config file that specified the bounds of the simulation: step size, optimization algorithm, min, max, etc. Only then could I use an agent to call the script to optimize the circuit.
Re: Show HN: SPICE simulation → oscilloscope → verification with Claude Code
#30Nice scope! I had a similar experience with using Claude to automate circuit design/simulation/optimization and found that they are not good at it. They are surprisingly good at taking raw files and describing what is in them, but they fall apart when trying to do anything other than design the simplest circuit. I think it is because they have no concept of the physics behind a circuit, so they cannot make changes th…
Yeah, taking the spice list as the starting point works much better, imo. I also prepopulate the CLAUDE.md file with some information like the pinout/pinmux of the MCU otherwise claude might run in circles trying targeting the wrong pin (to be fair that also happens to me, lol).