My project (https://phaestus.app/blog) takes a different approach: pre-validated circuit blocks on a fixed 12.7mm grid with standardized bus structures. The LLM picks which blocks you need and where they go, but the actual circuit design was done by humans and tested. No hallucinated resistor values, no creative interpretations of datasheets.
It's the same insight that made software dependencies work. You don't ask ChatGPT to write you a JSON parser from scratch, you ask it which library to use. Hardware should work the same way.
Still WIP and the block library needs expanding, but the constraint-based approach means outputs are manufacturable by construction rather than "probably fine, let's see what catches fire."
I know Ben is having some fun, perhaps making a valid point, with the burning component on the breadboard. I think it does underscore a difference between software vibing and hardware vibing—crash vs. fire.
But in fact vibe-breadboarding has drawn me deeper into the electronics hobby. I have learned more about op-amps and analog computing in the past two months in large part thanks to Gemini and ChatGPT pointing the way.
I know now about BAT54S Schottky diodes and how they can protect ADC inputs. I have found better ADC chips than the ones that come pre-soldered on most EDP32 dev boards (and have breadboarded them up with success). These were often problems I didn't know I should solve. (Problems that, for example, YouTube tutorials will disregard because they're demonstrating a constrained environment and are trying to keep it simple for beginners, I suppose.)
To be sure I research what the LLMs propose, but now have the language and a better picture in my mind to know what to search for (how do I protect ADC inputs from over or under voltages?). (Hilariously too, I often end up on the EE Stack Exchange where there is often anything but a concise answer.)
5V USB power, through-hole op-amp chips… I'm not too worried about burning my house down.
Years ago, at Pumping Station One in Chicago, I watched someone struggle with the driving of multiple LEDs from an Arduino in his project. He wondered why the LEDs got dimmer when more than one was lit.
I looked at the original schematic, and what he had built, and noticed a difference. The original design had a resistor on each LED, but he had decided that was a redundancy and refactored it to use a single LED instead. In the case of current flow, this meant the circuit still worked, but that current limiting that resistor provided now was shared across every active LED, leading to the progressive dimming as more LEDs were active.
It turned out his background was in software, where the assumptions are much different as to what is important. Cutting out redundant code is an important skill.
I saw it as a cognitive impedance mismatch being played out in real life.
I assume the same is true for an LLM/AI attempting the same leap.
Other than that, it does useful circuit review, part selection (or suggestions for alternative parts you didn’t know existed), and is usually usefully skeptical. It’s also great at quick back of the napkin “can I just use a smt ceramic here?” Type calculations, especially handy for roughing out timings and that kind of thing.
The logical next step is to use metal, but that's outside of my hobby tools. I found that JLCPCB offered sheet metal fabrication but I had no experience with sheet metal designs. I went to ChatGPT and was actually really impressed by how well it was able to guide me from design to final model file. I received the adapters last week and was really impressed by how nice they turned out.
All of that to say, AI-assisted design is actually lowering the bar of entry for a whole lot of problems and I am quite happy about it.
This seems ~identical to the situation where we can use a compiler or parser to return syntax errors to the agent in a feedback loop.
I don't know exactly what the tool calling surface would look like, but I feel like this could work.
What is being said here is “I can give my model a high quality feedback loop”.
With good simulators and good access to info about latest products etc a novice can also give their model a high quality feedback loop! But they have to build it or source it from somewhere. I’m talking all the right tools to give the model a goal and let it rip.
Once that loop is built the human is out of the loop and the model has the grounding it needs to converge on a solution instead of needing constant prodding.
There’s immense opportunity for experts to create these grounding tools and productise them.
I wonder if a SPICE skill would make LLMs safer and more useful in this area. I’m a complete EE newbie, and I am slowly working through The Art of Electronics to learn more. Being able to feed the LLM a circuit diagram—or better yet, a photo of a real circuit!—and have it guess at what it does and then simulate the results to check its work could be a great boon to hands-on learning.
Reading and interpreting datasheets: A- (this has gotten a LOT better in the last year)
Give netlist to LLM and ask it to check for errors: C (hit or miss, but useful because catching ANY errors helps)
Give Image to LLM and ask it to check for errors: C (hit or miss)
Design of circuit from description: D- (hallucinates parts, suggests parts for wrong purpose. suggests obsolete parts. Cannot make diagrams. Not an F because its textual descriptions have gotten better. When describing what nodes connect to each other now its not always wrong. You will have to re-check EVERYTHING though, so its usefulness is doubtful)
> ...
> Ah - that makes sense, that's why it's on fire
oh how very relatable, I've had similar moments.
I knew about SEDs (smoke emitting diodes) and LERs (light emitting resistors), but what do you call the inductor version?
I've been 50/50 with vibe circuits recently. Gemini 2.5 gave me some really wrong designs of an advanced crowbar circuit I was playing with, but recently 3.0 Fast gave me excellent advice on an adjustable load with a hodgepodge of parts.
Previous discussion: https://news.ycombinator.com/item?id=44542880
I ve done all this by taking photos of the circuits and asking Gemini how to do it.
I know nothing...
WARNING: nerd snipe material.
The MVP was hand coded, leaned heavily on sympy, linear fits, and worked for simple circuits. The current PoC only falls back to sympy to invert equations, switches to GPR when convergence stalls, and use a robust differential evolution from scipy for combinatorial search. The MVP works, but now I have a mountain of slop to cleanup and some statistics homework to understand the limitations of these algorithms. It’s nice to validate ideas so quickly though.
The system is on fire