Been working on this exact problem for a while now. The core issue isn't that LLMs are bad at circuits, it's that we're asking them to do novel design when they should be doing selection and integration.
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."
> The core issue isn't that LLMs are bad at circuits, it's that we're asking them to do novel design when they should be doing selection and integration.
I don't want to detract from what you're building, but I'm puzzled by this sentence. It very much sounds like the problem is that they're bad at circuits and that you're working around this problem by making them choose from a catalog.
Try that for code. "The problem isn't that LLMs are bad at coding, it's that we're asking them to write new programs when they should be doing selection and integration".
Sorry, could have been more clear, LLM's are great at architecting high level design decisions, but terrible at the nitty gritty - without better tooling (with the right tooling, such as https://flux.ai, they are capable!).
I even had Gemini hallucinate a QFN version of the TPS2596 last night, it was so confident that the *RGER variant existed. In an automated pipeline, this would break things, but giving it a list of parts to use, it becomes a lot more useful!
That’s exactly how it has been working for me in code. I have a bunch of different components and patterns that the LLMs mix and match. Has been working wonderfully over the past few months.
I’m curious why you don’t target an HDL, which seems like it should match very well to llm capabilities, and rely on existing layout solvers for describing the last physical layout step?
Thanks, as a concept it has potential, I've leveraged some of my previous projects www.circuitsnips.com for inspiration for the subcircuit blocks, TOKN for more accurate parsing of schematics, and to a lesser extent even my datasheet MCP server and kicad-netlist tool, more info at https://www.mikeayles.com/
For the time being, I'm erring away from feature creep, even though I really, really want to though! For the sorts of products I would like this to make for the time being, simple I2C, SPI and GPIO driven peripherals are the limit. I only have 2 more weeks, and then I want to have a working, battery powered device on my desk. PCB, Enclosure, Firmware, everything.
Similarly, I haven't got a framework for anything mechatronic in the MCAD pipeline, so no moving parts (besides clickable buttons). Fixed devices are fine, like screens and connectors though.
Is there a way to stay up to date with what you are doing?
It very much aligns with how I've approached hardware since I was 15 and had a massive stack of functional blocks of electronics circuitry that I would combine in all kinds of ways. I've lost the 3x5's, but I still work that way, build a simple block, test it, build another block, test that, hook the one to the other etc.
There's a limited sign up currently on the site, which currently goes to an approval page. I don't think I'm quite ready for it to be fully open yet, as i'm paying all the inference, but I should be starting to populate the gallery soon with generated projects.
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.
Both Gemini and ChatGPT have a pretty comically wrong knowledge of op-amps. They usually recommend outdated chips and are confused about circuit topologies. I was looking at this last week and it hasn't changed. I asked them to suggest and evaluate microphone circuits and they were just bad. I would really, really recommend reading some human-written text if you're learning about that.
I can't think of any reason why you'd want to use Schottky diodes to protect op-amp inputs. They have high leakage currents and poor surge capabilities. Most op-amps have internal protection diodes, and if you need some extra ESD or overvoltage protection, a Schottky diode probably isn't the way.
I'm not taking an anti-LLM view here. I think they are useful in some fields and are getting better. But in this particular instance, there's a breadth of excellent learning resources and the one you've chosen isn't good.
Thanks, I have read a lot of human-written text (and actual books from the day). Again though, had I ignored LLMs altogether I would have barely progressed in the past two months. I think.
"Schottky diodes to protect op-amp inputs…" Not op-amp inputs, ADC inputs (which may well come from an op-amp output though—I am playing with analog computing after all).
> 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).
Depending on your setup: beware of your ground and realize that breadboards are an extremely bad fit for this sort of application. It's hard enough to get maximum performance out of a good DAC on a custom designed PCB, on a breadboard it can be a nightmare.
Irrespective, "letting the magic smoke out" has been a part of the electronic hobbyist's vernacular long before vibe-breadboarding. (Been there many times.)
If you know what you're doing with electronics design, I've found that leveraging an LLM to help come up with ideas, layout block diagrams, and find parts can be super useful. Integrating Digi-Key or Mouser API support for finding parts pricing and inventory is also super handy. Using the distributor APIs can also allow you to perform natural language search which isn't possible (or isn't easy) through the distributor websites as the LLM can quickly download the datasheet and read it as part of its searching operation to verify if a part should be considered given your requirements.
I haven't had much success yet with this. My ratings follow.
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)
As an AI skeptic, I’ve been brought around to using Claude Code to understand a codebase, like when I need to quickly find where something happens through a tower of abstractions. Crucially, this relies on Claude actually searching my codebase using grep. It’s effectively automated guess and check.
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.
I don't trust an LLM to write software for me without human verification, but it's not like it's that hard to verify what it writes if you understand how to write code yourself. I expect even when an LLM can layout a high voltage circuit or design a bridge that most organizations who carry liability would still be sure to audit the design with a set or two of intelligent and trained human eyes.
Semi related: what are your guys workflow to PCB design? I need to build an AFE + BLE MCU for a BCI, and having no EE background, my workflow is KiCAD -> buy components -> breadboard testing -> done?? -> order fully manufactured PCB?
I have been working on a tool that aids in circuit tuning: model circuit equations as python functions, the solution space is discrete component values, auto solve for a target specs, build the circuits, record measurements, fit error, repeat until the experiment matches predictions. It adjusts nearly every parameter between tests and converges surprisingly fast. (25% to 2% error in 3 tests for an active band pass filter)
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.
Been working on this exact problem for a while now. The core issue isn't that LLMs are bad at circuits, it's that we're asking them to do novel design when they should be doing selection and integration.
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."
> The core issue isn't that LLMs are bad at circuits, it's that we're asking them to do novel design when they should be doing selection and integration.
I don't want to detract from what you're building, but I'm puzzled by this sentence. It very much sounds like the problem is that they're bad at circuits and that you're working around this problem by making them choose from a catalog.
Try that for code. "The problem isn't that LLMs are bad at coding, it's that we're asking them to write new programs when they should be doing selection and integration".
Sorry, could have been more clear, LLM's are great at architecting high level design decisions, but terrible at the nitty gritty - without better tooling (with the right tooling, such as https://flux.ai, they are capable!).
I even had Gemini hallucinate a QFN version of the TPS2596 last night, it was so confident that the *RGER variant existed. In an automated pipeline, this would break things, but giving it a list of parts to use, it becomes a lot more useful!
That’s exactly how it has been working for me in code. I have a bunch of different components and patterns that the LLMs mix and match. Has been working wonderfully over the past few months.
That is exactly what LLMs are good at for code
I’m curious why you don’t target an HDL, which seems like it should match very well to llm capabilities, and rely on existing layout solvers for describing the last physical layout step?
This seems to be a discussion about board level circuits. HDLs are for chip design.
So far the language models aren’t great at HDL but I assume it’s just a training priority thing and not some characteristic of HDLs.
This sounds very interesting, especially if you combine it for instance with an FPGA for logic blocks.
Thanks, as a concept it has potential, I've leveraged some of my previous projects www.circuitsnips.com for inspiration for the subcircuit blocks, TOKN for more accurate parsing of schematics, and to a lesser extent even my datasheet MCP server and kicad-netlist tool, more info at https://www.mikeayles.com/
For the time being, I'm erring away from feature creep, even though I really, really want to though! For the sorts of products I would like this to make for the time being, simple I2C, SPI and GPIO driven peripherals are the limit. I only have 2 more weeks, and then I want to have a working, battery powered device on my desk. PCB, Enclosure, Firmware, everything.
Similarly, I haven't got a framework for anything mechatronic in the MCAD pipeline, so no moving parts (besides clickable buttons). Fixed devices are fine, like screens and connectors though.
Is there a way to stay up to date with what you are doing?
It very much aligns with how I've approached hardware since I was 15 and had a massive stack of functional blocks of electronics circuitry that I would combine in all kinds of ways. I've lost the 3x5's, but I still work that way, build a simple block, test it, build another block, test that, hook the one to the other etc.
Feel free to star/watch the repo for the project at: https://github.com/MichaelAyles/heph
I may be able to set up an RSS feed for the blog if that interests you? edit: https://phaestus.app/feed.xml
There's a limited sign up currently on the site, which currently goes to an approval page. I don't think I'm quite ready for it to be fully open yet, as i'm paying all the inference, but I should be starting to populate the gallery soon with generated projects.
RSS feed would be helpful.
Done, https://phaestus.app/feed.xml. If there's any issues i'd appreciate the feedback, I haven't used an RSS feed in a while!
Why, yes I am.
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.
Both Gemini and ChatGPT have a pretty comically wrong knowledge of op-amps. They usually recommend outdated chips and are confused about circuit topologies. I was looking at this last week and it hasn't changed. I asked them to suggest and evaluate microphone circuits and they were just bad. I would really, really recommend reading some human-written text if you're learning about that.
I can't think of any reason why you'd want to use Schottky diodes to protect op-amp inputs. They have high leakage currents and poor surge capabilities. Most op-amps have internal protection diodes, and if you need some extra ESD or overvoltage protection, a Schottky diode probably isn't the way.
I'm not taking an anti-LLM view here. I think they are useful in some fields and are getting better. But in this particular instance, there's a breadth of excellent learning resources and the one you've chosen isn't good.
Thanks, I have read a lot of human-written text (and actual books from the day). Again though, had I ignored LLMs altogether I would have barely progressed in the past two months. I think.
"Schottky diodes to protect op-amp inputs…" Not op-amp inputs, ADC inputs (which may well come from an op-amp output though—I am playing with analog computing after all).
> 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).
Depending on your setup: beware of your ground and realize that breadboards are an extremely bad fit for this sort of application. It's hard enough to get maximum performance out of a good DAC on a custom designed PCB, on a breadboard it can be a nightmare.
Just this morning I was vibing with Gemini to make a battery-powered stove monitor to sell that I might call "Yes I turned off the stupid stove" :-)
Gemini was suggesting the circuit design and of course I'd do the final work myself, but I find vibe-circuit-building to be quite valuable.
Know the risks, prepare for them, get a little burned now and then, have fun... sounds like a recipe for learning to me.
Sometimes sarcasm is so subtle…
Irrespective, "letting the magic smoke out" has been a part of the electronic hobbyist's vernacular long before vibe-breadboarding. (Been there many times.)
If you know what you're doing with electronics design, I've found that leveraging an LLM to help come up with ideas, layout block diagrams, and find parts can be super useful. Integrating Digi-Key or Mouser API support for finding parts pricing and inventory is also super handy. Using the distributor APIs can also allow you to perform natural language search which isn't possible (or isn't easy) through the distributor websites as the LLM can quickly download the datasheet and read it as part of its searching operation to verify if a part should be considered given your requirements.
> Thought for 37s
> ...
> 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 haven't had much success yet with this. My ratings follow.
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)
As an AI skeptic, I’ve been brought around to using Claude Code to understand a codebase, like when I need to quickly find where something happens through a tower of abstractions. Crucially, this relies on Claude actually searching my codebase using grep. It’s effectively automated guess and check.
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.
What would stop us from using something like LTspice to validate the circuit before risking physical components?
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.
Ah, the elusive light emitting inductor
Probably works pretty well with atopile.
Previous discussion: https://news.ycombinator.com/item?id=44542880
In the real world where parts have costs and mistakes have consequences, the GenAI "YOLO" mode doesn't work as well.
This brings up a much larger discussion. How bad are LLMs at engineering? Would you trust one to build a high voltage circuit? How about a bridge?
I don't trust an LLM to write software for me without human verification, but it's not like it's that hard to verify what it writes if you understand how to write code yourself. I expect even when an LLM can layout a high voltage circuit or design a bridge that most organizations who carry liability would still be sure to audit the design with a set or two of intelligent and trained human eyes.
I wonder how many shots he made to get this perfect one.
Semi related: what are your guys workflow to PCB design? I need to build an AFE + BLE MCU for a BCI, and having no EE background, my workflow is KiCAD -> buy components -> breadboard testing -> done?? -> order fully manufactured PCB?
I know nothing...
Hire someone competent?
I have been working on a tool that aids in circuit tuning: model circuit equations as python functions, the solution space is discrete component values, auto solve for a target specs, build the circuits, record measurements, fit error, repeat until the experiment matches predictions. It adjusts nearly every parameter between tests and converges surprisingly fast. (25% to 2% error in 3 tests for an active band pass filter)
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.
MCP Server for KiCAD:
https://github.com/mixelpixx/KiCAD-MCP-Server
yes. but it is not smooth sailing.
Good metaphor for 2026..
The system is on fire
If you know Ben Eater, you know he built that circuit on purpose lol.
Not so sure—just as likely a fan shared it and he is re-posting to make a point.
I mean, he absolutely knew it was going to burn up. But I have no trouble believing that such a circuit was designed by AI.