I Asked AI to Design 12 Dev Boards. It Told Me to Write a Script. | atomic14

🌈 ESP32-S3 Rainbow: ZX Spectrum Emulator Board!<br>Get it on Crowd Supply →

I Asked AI to Design 12 Dev Boards. It Told Me to Write a Script.

View All Posts

read

Want to keep up to date with the latest posts and videos? Subscribe to the newsletter

Posts ·<br>Videos ·<br>ESP32 ·<br>Tools ·<br>Support

« Invaders! is back: rescued from a forgotten Bitbucket account

HELP SUPPORT MY WORK: If you're feeling flush then please stop by Patreon Or you can make a one off donation via ko-fi

I keep needing the same thing - a really basic dev board for whatever Espressif<br>module I’m playing with. USB-C, a 3.3V regulator, BOOT and EN buttons, three<br>LEDs (5V present, 3.3V present, and one on a GPIO so you can run the blink<br>sketch), and every GPIO broken out on headers. Nothing clever, just the minimum<br>board that gets a bare module doing something.

While building the ESP32 module database I<br>noticed there are twelve modules that fit one sensible recipe - a PCB antenna<br>and native USB - spread across the S2, S3, C3, C5, C6 and H2 families. Native<br>USB is the bit that keeps the component count down. There’s no USB to UART<br>bridge to buy and route, just a USB-C socket and a couple of 5.1K resistors on<br>the CC pins so the host actually hands over power.

Twelve near-identical boards is exactly the kind of job that makes you question<br>your life choices in KiCad.

So I did what everyone on the internet is currently telling you to do and asked<br>Claude to spin up a team of AI agents to design the boards for me.

And it said no.

Not a flat no, more of a “this is beneath me” no. Its argument, roughly - this<br>is a mechanical, repetitive job, and you don’t want a swarm of agents<br>improvising twelve layouts. What you want is deterministic scripts that produce<br>the same board every time, with AI involved only where there’s a real judgement<br>call to make.

Which is a surprisingly sensible thing for it to say. So I let it write the<br>scripts instead, and the AI’s contribution to each board shrank down to a<br>single file. More on that below.

That montage is to scale - the render pipeline normalises the zoom so a<br>29×33 mm C3-MINI board looks properly tiny next to a 28×55 mm S2-MINI.

The whole thing is on GitHub at<br>atomic14/kicad-esp32-dev-boards,<br>with fab-ready Gerbers and openable KiCad projects for all twelve boards on the<br>releases page.

So what’s left for a human to do?

Almost all of the pipeline is just deterministic scripting. The only real<br>judgement call is a small board.yaml per module, and it holds the things a<br>script can’t work out for itself from the symbol and footprint:

Which pins must not be broken out. This is sneakier than it sounds, because<br>it’s symbol specific rather than name based - SPIIO6, SPIIO7 and SPIDQS<br>are reserved for the octal flash on an S3-WROOM-1, but the same names are<br>perfectly usable GPIO on the quad S3-MINI-1.

The boot-strap pin that the BOOT button pulls low. GPIO0 on the Xtensa parts,<br>GPIO9 on most of the RISC-V parts, and GPIO28 on the C5, because nothing is<br>ever completely consistent…

The strapping and input only pins to steer the on-board LED away from. Given<br>that list the generator picks the LED pin itself - the safe pad physically<br>nearest the LED on the laid out board, so the trace stays nice and short.<br>Hang the LED off an input only pin and it simply never lights up, so the<br>build hard-errors rather than let that ship.

That’s the whole hand written input for a board. Everything else gets derived<br>from the module’s symbol and footprint - power, GND, EN, the USB D+/D- pair,<br>the GPIO net labels.

And this file is where the AI actually lives. All those judgement calls are<br>already written up in plain English on each module’s page of<br>the module database - for humans. So the job<br>I hand to the AI is a simple one: read the page, fill in the file. Messy prose<br>in, clean data out, which is the one thing a script can’t do.

It works under a safety net too. If it picks an unsafe pin for the LED then the<br>build hard-errors and refuses to generate the board at all.

So how does the generator work?

Each board starts from a pre-built skeleton project - the USB-C connector, LDO,<br>buttons and LEDs, already placed, routed and sanity checked.

There are actually two skeletons, mirror images of each other, one with EN on<br>the left and BOOT on the right and one the other way round. That one came out<br>of playing about with the AI. Depending on which edge a module’s reset pin<br>comes out on, putting the matching button on that side makes the routing much<br>easier, so the generator has a look at the footprint and picks whichever<br>skeleton fits.

From there the script does four things:

Builds the schematic with kicad-skip,<br>dropping in the module symbol and two break-out headers, wired up with net<br>labels.

Places the PCB. USB-C at the bottom edge with the buttons either side of it,<br>support components above that, and the module at the top with the antenna<br>hanging over the...