Despite LLMs being decent at generating text (which has loose, messy rules), applications like PCB layout and coding with clearly-defined constraints make much more sense.
Having well-established, unambiguous rules that must be followed for functionality seems to be a key predictor of AI success. The more constrained and rule bound the domain, the better LLMs perform.
While I think that AI tools can be quite useful for coding, PCB design, and other tasks like that, the setup of this experiment makes it really hard for the LLM to fail.
The author's prompt is basically already a meticulous specification of the PCB, even proactively telling the LLM to avoid certain pitfalls ("GPIO19 and GPIO20 on the ESP32-S3 module are USB D- and D+ respectively. Make sure these nets are labeled correctly so that differential routing works"). If you had no prior experience building that exact thing, writing that spec would be 95% of the work.
Anyway, I don't think the experiment is wrong, but it's also not exactly vibe-PCBing!
The blog post isn’t clear: Did the LLM actually do the routing? The only screenshot showing connected traces comes after the author says they added ground fills and “tidied up the layout”
It’s amazing that this worked at all, but to be clear this layout is actually very bad. Just look at that minimum width trace used to carry power across the entire board and into the ESP32. Using min width traces and wrapping them and min clearance to components is a classic mistake of people (or LLMs?) that have zero understanding of PCB layout techniques beyond “draw lines until everything is connected”
It would be interesting to see if you could feed the file into an LLM and get it to produce the feedback.
Awesome to see more people experimenting with AI-generated electronics. The main thing holding back physical world innovation is the labor cost of design- I’m always blown away that someone needs to raise $50m just to design a hardware AI-assistant or new robotics
Frameworks like atopile, tscircuit (disclaimer: I’m a tscircuit lead maintainer) and JITX are critical here because they enable the LLM to output the deep knowledge it already has. The author is missing a couple pieces to really get great output: 1) Context-friendly datasheets 2) DRC/Semantic review 3) LLM-compatible layout methods
The hardest to build is (3) and what I spend 90% of my time on. AI knows how do do spatial layout for things like flex or css grid but doesn’t have a layout method for PCBs. Our approach w/ tscircuit is to develop new layout systems that either match templates, new heuristic layouts (we are developing one called “pack”), or solve simple spatial constraints.
But tldr; it is only a matter of time before AI can output PCBs. It is not simple but we know what works with LLMs from witnessing the evolution of AI for website generation
This is a really poor experiment and conclusions do not mean much for teo reasons: 1- This PCB is extremely simple. Anyone can design this in no time. 2- This type of automation is as old as EDA tools (which means electronic design automation). Auto floorplanning and routing isn't new in the industry. Yet, LLMs do not perform well in this field. The successful implementations are using custom algorithms + RL. The bar to claim "design via LLMs" is very very high.
Co-author of atopile here – super excited to see this on HN!
Coincidentally, we just built an MCP server for atopile, and Claude seems to love it. It makes a big difference in usability, and also exposes our re-usable design library[0].
A bit about atopile[1]:
Our core idea is to capture design intent in a knowledge graph with constraints and high-level modeling of components and interfaces. This lets us do much more than just AI integrations: we’ve built an in-house constraint solver that can automatically pick passives (resistors, capacitors, etc) based on the values you've constrained in your design.
Currently, atopile directly generates KiCAD PCB files, so you can finish the layout (mainly the connections between reusable layout blocks). We're also generating artifacts like I2C bus trees and 3D models, with power trees and schematic generation on the roadmap.
Happy to answer questions or go into technical details!
I would be happy if an AI could read the datasheet, produce footprints and schematic symbols, and perhaps 3d models. And present the component characteristics in a unified way.
I mean, some people are claiming that LLMs can do scientific research, so the above isn't too much to ask.
> Initially, everything looked great. The build succeeded, all components were found and added. But when I opened KiCad… nothing was wired up.
Maybe this is pedantic, but I thought that the core point of "Vibe Coding" is that you do not look at the code. You "give in to the 'vibes'".
I don't know how to translate it into a physical hardware product exactly, but I think it would be manufacturing it without looking at it, plugging it in for your use-case and seeing if it works, then going back to the model, saying it didn't work, rinse, repeat.
While the author has very different aims and intended scope, I have been able to leverage both "traditional" (lol) LLMs and Cursor to design and program for novel device design. The results have been pretty incredible to me, and all of the salty comments about the utility of AI to assist with electronics are fully missing the mark.
It's been my direct and many-times-repeated experience that o3 is an incredible electronics engineering wingman, so long as you follow good LLM hygiene; basically, verify all important assumptions, actually read the datasheets, err on the side of too much detail.
The time spent crafting prompts is the time I would spend planning and iterating on designs anyhow. Unlike a human, I don't have to pay them by the hour to patiently explain the nuances of different diodes or suggest alternative parts. o3 is remarkably good at rapidly grokking intent and making suggestions that have unblocked me.
For the camp of armchair quarterbacks on this site who demand specific "evidence" that we're not all just hallucinating the value of these tools, here are two things that happened just this week:
I was blowing my brains out troubleshooting a touch IC, IS31SE5117A. No matter how good my reflow or how many units I tried, I could not bring up an I2C connection. Based only on the fact that Cref refused to rise above ~0.1V when it's supposed to be about 0.7V, it suggested that it seemed likely that I had units from a batch that had no firmware. After going back and forth with their lead engineer for a week, I ordered a few IS32SE5117A - automotive/medical spec, same chip - and it worked immediately, prompting a product recall.
I'd managed to implement galvanic isolation on my USB connection to eliminate audio hum, but it turns out that touching a capacitive pad on a device that has no outside ground connection means that static has nowhere to go but to reboot the microcontroller. I'd been chasing my tail on this for a while, but o3 suggested that instead of isolating my whole device, I could just isolate my MIDI OUT circuit. This is one of those facepalm moments that only seems obvious in hindsight. I told my partner that abandoning weeks of effort was first very hard, and then very easy.
Finally, last night I had Cursor generate both sides of an SPI connection between two ESP32-S3s, something I had never done before. I obviously could have figured it out in 2020, but it would have taken me 1-2 weeks and it wouldn't be nearly as clean or cover as many edge cases.
My hottest take is that LLMs are already (far?) more valuable for engineering tasks than coding. That's kind of unfair because by definition, these tasks involve coding. The speed at which I've been able to iterate has been kind of nuts.
Also: any claims that people who tackle complex domains from a cold start somehow aren't learning fundamentals from a mentor with infinite patience and awareness of every part and circuit design pattern are simply wrong.
In software we already let Copilot rough-draft code, run tests, then keep or toss the changes. We can do the same with hardware:
– keep the AI traces in a separate layer or revision
– run basic checks for clearance and width
– eyeball the diff, accept what looks right, fix the rest
22 comments
[ 3.3 ms ] story [ 62.6 ms ] threadHaving well-established, unambiguous rules that must be followed for functionality seems to be a key predictor of AI success. The more constrained and rule bound the domain, the better LLMs perform.
[1] https://github.com/devbisme/skidl
The author's prompt is basically already a meticulous specification of the PCB, even proactively telling the LLM to avoid certain pitfalls ("GPIO19 and GPIO20 on the ESP32-S3 module are USB D- and D+ respectively. Make sure these nets are labeled correctly so that differential routing works"). If you had no prior experience building that exact thing, writing that spec would be 95% of the work.
Anyway, I don't think the experiment is wrong, but it's also not exactly vibe-PCBing!
It’s amazing that this worked at all, but to be clear this layout is actually very bad. Just look at that minimum width trace used to carry power across the entire board and into the ESP32. Using min width traces and wrapping them and min clearance to components is a classic mistake of people (or LLMs?) that have zero understanding of PCB layout techniques beyond “draw lines until everything is connected”
It would be interesting to see if you could feed the file into an LLM and get it to produce the feedback.
Maybe _then_ we can trust LLMs to design stuff for us.
Except that:
Easily the two hardest / annoying steps in designing such a straightforward board.Frameworks like atopile, tscircuit (disclaimer: I’m a tscircuit lead maintainer) and JITX are critical here because they enable the LLM to output the deep knowledge it already has. The author is missing a couple pieces to really get great output: 1) Context-friendly datasheets 2) DRC/Semantic review 3) LLM-compatible layout methods
The hardest to build is (3) and what I spend 90% of my time on. AI knows how do do spatial layout for things like flex or css grid but doesn’t have a layout method for PCBs. Our approach w/ tscircuit is to develop new layout systems that either match templates, new heuristic layouts (we are developing one called “pack”), or solve simple spatial constraints.
But tldr; it is only a matter of time before AI can output PCBs. It is not simple but we know what works with LLMs from witnessing the evolution of AI for website generation
Coincidentally, we just built an MCP server for atopile, and Claude seems to love it. It makes a big difference in usability, and also exposes our re-usable design library[0].
A bit about atopile[1]: Our core idea is to capture design intent in a knowledge graph with constraints and high-level modeling of components and interfaces. This lets us do much more than just AI integrations: we’ve built an in-house constraint solver that can automatically pick passives (resistors, capacitors, etc) based on the values you've constrained in your design.
Currently, atopile directly generates KiCAD PCB files, so you can finish the layout (mainly the connections between reusable layout blocks). We're also generating artifacts like I2C bus trees and 3D models, with power trees and schematic generation on the roadmap.
Happy to answer questions or go into technical details!
[0] https://packages.atopile.io/ [1] https://atopile.io/
I mean, some people are claiming that LLMs can do scientific research, so the above isn't too much to ask.
Maybe this is pedantic, but I thought that the core point of "Vibe Coding" is that you do not look at the code. You "give in to the 'vibes'".
I don't know how to translate it into a physical hardware product exactly, but I think it would be manufacturing it without looking at it, plugging it in for your use-case and seeing if it works, then going back to the model, saying it didn't work, rinse, repeat.
It's been my direct and many-times-repeated experience that o3 is an incredible electronics engineering wingman, so long as you follow good LLM hygiene; basically, verify all important assumptions, actually read the datasheets, err on the side of too much detail.
The time spent crafting prompts is the time I would spend planning and iterating on designs anyhow. Unlike a human, I don't have to pay them by the hour to patiently explain the nuances of different diodes or suggest alternative parts. o3 is remarkably good at rapidly grokking intent and making suggestions that have unblocked me.
For the camp of armchair quarterbacks on this site who demand specific "evidence" that we're not all just hallucinating the value of these tools, here are two things that happened just this week:
I was blowing my brains out troubleshooting a touch IC, IS31SE5117A. No matter how good my reflow or how many units I tried, I could not bring up an I2C connection. Based only on the fact that Cref refused to rise above ~0.1V when it's supposed to be about 0.7V, it suggested that it seemed likely that I had units from a batch that had no firmware. After going back and forth with their lead engineer for a week, I ordered a few IS32SE5117A - automotive/medical spec, same chip - and it worked immediately, prompting a product recall.
I'd managed to implement galvanic isolation on my USB connection to eliminate audio hum, but it turns out that touching a capacitive pad on a device that has no outside ground connection means that static has nowhere to go but to reboot the microcontroller. I'd been chasing my tail on this for a while, but o3 suggested that instead of isolating my whole device, I could just isolate my MIDI OUT circuit. This is one of those facepalm moments that only seems obvious in hindsight. I told my partner that abandoning weeks of effort was first very hard, and then very easy.
Finally, last night I had Cursor generate both sides of an SPI connection between two ESP32-S3s, something I had never done before. I obviously could have figured it out in 2020, but it would have taken me 1-2 weeks and it wouldn't be nearly as clean or cover as many edge cases.
My hottest take is that LLMs are already (far?) more valuable for engineering tasks than coding. That's kind of unfair because by definition, these tasks involve coding. The speed at which I've been able to iterate has been kind of nuts.
Also: any claims that people who tackle complex domains from a cold start somehow aren't learning fundamentals from a mentor with infinite patience and awareness of every part and circuit design pattern are simply wrong.
Well, that beats the average human performance.
– keep the AI traces in a separate layer or revision – run basic checks for clearance and width – eyeball the diff, accept what looks right, fix the rest