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 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".
Not trying to be a smart ass here, I’ve been keeping an eye out for years.
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!
Module based design is cool for getting the prototype going but once you get into production you want to optimize everything so it falls apart quickly when you need to move the parts (not blocks, parts) to fit the least possible amount of space, cut components that could be shared (do 8 blocks on one board each with its own decoupling caps need entire set of them? Probably not). Fine for prototyping/hobby stuff/one off but falls apart quickly in production.
Still, having working prototype quickly that can then be optimized in more traditional way can still be very valuable.
> 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.
hardware optimising gets you far more money faster than software, because the cost of software not being optimal is mostly cost on the consumer (burning more CPU than it would if it was optimized), while for hardware each chip less is more money left in your pocket and there are actual size constraints that can be pretty hard edged vs software's "well the user will have to download extra MB more"
However, I wanted to say that for a lot of common parts I find the Adafruit open source schematics to be at least as useful as the application layout suggestions in many datasheets. When it comes to regulators etc it's nice to see how they did it, because like your project, you really can approach it like a block.
For example a part like the ADS7953 ADC comes with layout recommendations, including the design of the ground plane underneath the chip and the placement of the decoupling caps. A more extreme example would be an esp32 and all of it's supporting parts, including the keepout area on the PCB for wifi transmission.
I really want to assemble circuits out of higher level primitives like that, drag and drop a chip and all of its supporting parts, including their layout and power connections.
I'm targeting sub 5mins from first prompt to manufacturing exports, stl files for enclosure, gerbers for pcb manuf, bin file for firmware, bom for pcba.
E.g. if you wanted something that doesn't exist, but don't have the time, the skills or it's just not worth it. One silly example I had was a colour e-ink selfie fridge magnet. As far as I know, that doesn't exist, I could make it, but I can't be arsed. (so I could suprise my partner with a selfie, a picture of our dog, or anything, just a little treat for her for putting up with me).
With this, it'll pull in a ESP32-S3 Sense Xiao board, an e-ink module, a battery connector and a usb c charge connector. glue it all together, and there we go.
Should work if you wanted a rudimentary zigbee mesh communicator, pulls in a C6, a touchscreen, battery, probably a physical button or two. Once that block library starts filling up, it'll become more and more capable.
However, what I suspect you're after is more aligned with https://www.circuitsnips.com
I built circuitsnips to be the 'thingiverse' for electronics schematics.
Unfortunately it's been a bit neglected since so much of my free time has gone into phaestus, I did have great intentions to kicad up some official reference designs, so I can get rid of the github scraped bootstrap data as that was the sticky point both ethically and for the quality of the schematics, but there are only so many hours in a day.
My intent for phaestus isn't to design pcb's, it's to design entire products, and also to be friendly to non technical users who don't know what a PCB is, let alone do layout themselves.
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.
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.
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.
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.
My first guess would be the fast switching time of the Schottky makes them appear useful for responding to transient events.
"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).
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.
It's enough that I've now moved to KiCad layout and will wait for the boards to come back to see if the actual ADC data I am getting is more or less linear, noiseless…
Modern coding agents have a remarkable grasp of circuit design and the net result is that they keep pushing me to learn more, faster.
I do find that I often have to specify that I only want parts that are "active on Digikey" because otherwise it will recommend obsolete parts. However, I consider this just like reviewing code generated by an LLM. You don't get a pass on reading datasheets or verifying statements.
I recently had GPT 5.2 spit out a progression of circuits that can amplify a dynamic mic signal to line level, simple to complex, with the intention of finally learning how good amplifiers work. Adding transformers and gain stages with the different OPA family parts and hearing the hum disappear and noise floor drop is the best kind of education.
A tip: BAT54SW specifically is the best part for protecting your pins.
Exactly. I'm a life-long software guy, but I've dabbled in electronics at various times. But typically I'd hit walls that I just didn't know how to get past, and it wasn't easy to find solutions. If I'd had an LLM to help, I'm pretty sure I'd have become much more deeply involved in electronics.
Irrespective, "letting the magic smoke out" has been a part of the electronic hobbyist's vernacular long before vibe-breadboarding. (Been there many times.)
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.
It would catch any case where the stove is drawing power, irrespective of possible failure modes of the stove itself.
Your idea would be a hard sell to anyone paranoid enough, since they won't trust your monitor.
An alternative would be to install a safety key switch or a magnetic safety key. The paranoid can then check they have the key on them when they leave the home (like the lady worried about her hair dryer - see below).
Or perhaps a camera facing the oven switch?
Scott Alexander wrote https://slatestarcodex.com/2014/11/21/the-categories-were-ma...
The Hair Dryer Incident was probably the biggest dispute I’ve seen in the mental hospital where I work.
Basically, this one obsessive compulsive woman would drive to work every morning and worry she had left the hair dryer on and it was going to burn down her house. So she’d drive back home to check that the hair dryer was off, then drive back to work, then worry that maybe she hadn’t really checked well enough, then drive back, and so on ten or twenty times a day.
It’s a pretty typical case of obsessive-compulsive disorder, but it was really interfering with her life. She worked some high-powered job – I think a lawyer – and she was constantly late to everything because of this driving back and forth, to the point where her career was in a downspin and she thought she would have to quit and go on disability. She wasn’t able to go out with friends, she wasn’t even able to go to restaurants because she would keep fretting she left the hair dryer on at home and have to rush back. She’d seen countless psychiatrists, psychologists, and counselors, she’d done all sorts of therapy, she’d taken every medication in the book, and none of them had helped.
So she came to my hospital and was seen by a colleague of mine, who told her “Hey, have you thought about just bringing the hair dryer with you?”
And it worked.
She would be driving to work in the morning, and she’d start worrying she’d left the hair dryer on and it was going to burn down her house, and so she’d look at the seat next to her, and there would be the hair dryer, right there. And she only had the one hair dryer, which was now accounted for. So she would let out a sigh of relief and keep driving to work.
And approximately half the psychiatrists at my hospital thought this was absolutely scandalous, and This Is Not How One Treats Obsessive Compulsive Disorder, and what if it got out to the broader psychiatric community that instead of giving all of these high-tech medications and sophisticated therapies we were just telling people to put their hair dryers on the front seat of their car?
But I think the guy deserved a medal. Here’s someone who was totally untreatable by the normal methods, with a debilitating condition, and a drop-dead simple intervention that nobody else had thought of gave her her life back.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.
I didn't happen to need this particular advice, but it stuck in my head as something that would potentially save someone learning a lot of pain.
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.
I am now more of a hobbyist than a professional and LLM's allow me to get results quicker, for example over Christmas I replaced my Pioneer stereo with a new custom motherboard, re-using the class AB analog parts and all the switches and the VFD Display. LLM helped me do it a lot quicker and gave me a couple of novel options, write up here => https://rodyne.com/?p=3380
maybe not in the best way, but from a post here last week or so, somebody has written an altium mcp, from which i assume a bunch of the timing and capacitor checks could be run.
maybe not anything particularly high tech, but enough to let mechanical engineers put together test boards without needing to get too far into the electrical discipline
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.
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.
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 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.
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?
"Who did your electricals?"
"My nephew Thomas!"
"Oh, so when did his house burn down?"
"Last ye.... wait how do you know his house burnt down?"
...only know what an inductor is from watching a video one the youtubes where they were talking about using them on the suspensions of F1 cars and they explained their relationship to electronic circuits, forget what their actual name is.
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'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.
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