Vibe-Coding a PCB – surprisingly good

I could be wrong, but that looks like autoroute to me just based on the aesthetics of it, autoroute has a bit of a "smell" that you can recognize if you pay attention. For example see the via and traces to the left of SW2. No human I know, even a total noob designing their first ever PCB, would do that.

Also, it certainly wasn't the LLM; atopile doesn't allow you to specify routing as far as I'm aware, their docs seem to tell you to route in KiCad.

> Did the LLM actually do the routing?

Good question. KiCAD once had a router, built in, or sort of built in, but it was taken out for licensing reasons. So who's doing that?

> 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”

Is it really so implausible that these constraints could be built into the process/algorithm/agentic workflow?

The video seems more clear. The LLM generated the BOM and netlist using atopile, a tool for specifying the equivalent of a schematic in code. He did the placement and routing in KiCad in the usual way, presumably by hand.

ETA: Other commenters suspect a traditional autorouter based on the poor layout quality. I agree that's also possible, and nothing in the video excludes that. It definitely wasn't the LLM, though.

I'm not saying you're wrong, or that I know better.

Yet I have to say that if you are correct, the term is no different than eating tide pods or dry swallowing cinnamon. Why tf would anyone impose such an absurd artificial constraint on themselves, on the tool, or on whatever they are trying to build? Good faith question, I promise.

Constructing detailed prompts to ultimately pair program impressive, complex outcomes is what I assumed vibe coding was. After 35 years of not being able to tell a computer to write the code for me, even getting an 80% coherent first pass of a sophisticated refactor was already radical enough.

If that's what vibe coding is, then nobody should be using that term because it might be the perfect example of "just because you can, doesn't mean you should".

In this case the netlist is the code, and the pcb is the output. Idk if vibe coding has rules, but if it does that seems well within the rules.

The next stage in `ato build` process would have caught the missing connections in the DRC check and the LLM could have fixed it itself.

> If you had no prior experience building that exact thing, writing that spec would be 95% of the work.

Nowadays most mainstream LLMs support pre-bundled prompts. GitHub Copilot even made it a major feature and tools like Visual Studio Code have integrated support for prompt files.

https://docs.github.com/en/github-models/use-github-models/s...

Also, LLMs can generate prompt files too. I recommend you set aside 10 minutes of your time to vibe-code a prompt file for PCB generation, and then try to recreate the same project as OP. You'd be surprised.

> Anyway, I don't think the experiment is wrong, but it's also not exactly vibe-PCBing!

I don't agree. Vibecoding doesn't exactly mean naive approaches to implementations. It just means you enter higher level inputs to generate whatever you're creating.

It's the era of jack of no trades, master of all.

There are numerous serious problems with this PCB. Even skimming the data sheets or design guides for the ESP32 or LDO would reveal them.

I’m puzzled why the post calls it “surprisingly good” when it’s so bad and missing basic requirements for different parts. I guess it’s surprising that anything at all was produced, but it’s weird that the author can’t identify the basic problems with the design.

This is similar to situations where someone uses an LLM to vibe code an app until it kind of works, but then an experienced developer takes one look at the codebase and can immediately see it was not developed with any understanding of the code.

The LLM generated four caps on the LDO output. They're all placed next to each other and away from the LDO, but that seems to have been a human choice. So I can't fault the LLM there.

That said, the AMS1117 datasheet shows a tantalum cap on the output. This is presumably because the non-negligible ESR helps stabilize the regulator, though they don't say that explicitly. The LM1117 datasheet explains this better, stating that "the ESR of the output capacitor should range between 0.3 Ω to 22 Ω". (These are very similar parts, just from different manufacturers.)

The ceramic caps chosen here are probably below that, so perhaps it would ring even with correct layout. The prompt guided towards that bad choice when it said all caps should be 0603, since almost all 0603 capacitors are ceramic. The LLM was free to choose a regulator optimized for use with ceramic output caps, but it probably chose the xx1117 because it's so common.

http://www.advanced-monolithic.com/pdf/ds1117.pdf

https://www.ti.com/lit/ds/symlink/lm1117.pdf

Similarly to how most web dev isn't exactly on the frontiers of computer science, a lot of day-to-day PCB design isn't about cutting-edge analog or radio stuff. It's just putting the same MCU or SoC on differently-shaped boards over and over again.

If you can reliably automate that, it's still a pretty big deal.

Sure, but that's most PCBs (or even subsets of PCBs). Most PCBs are not about using new/proprietary chips with custom requirements. It's mostly connect this MCU with some other ICs, some power delivery, some connectors, reverse voltage protection etc.

The traces for the power lines are extremely thin, this device may suffer issues related to that. These devices pull a lot of power when Wifi is on, and too-thin traces aren't going to help that. Depending on the device, those traces might act like a fuse (and go poof), and I can imagine there could be plenty of other issues that could lead to fires from a "vibe coded" PCB.

Tried out claude code with atopile this week, and it's absolutely crazy. atopile has mcp support and claude loves using it. The MCP gives access to the atopile design library and compiler amonst other things.

Disclaimer: co-author of atopile here