I Asked an AI to Design Six PCBs. Here's What a Pin-by-Pin Review Found.

Posted on Oct 19 • Originally published at pcbeditor.com • AI-assisted

"AI PCB design" demos tend to stop at a nice render. I wanted to know what happens after it: does the board actually work? So on 17 October 2026 I typed six one-paragraph prompts into PCBEditor (the browser EDA tool I work on), let it generate each board end to end, and then reviewed every one the boring way: exported KiCad board, BOM and datasheets side by side, pin by pin.

Short version: five of the six finished fully routed with zero DRC errors and exported Gerbers. Only one of those five was right the first time. The sixth, a 4-layer RP2040 board, didn't finish routing at all.

Update, 19 October: I re-ran the same six prompts on the next release. Four of the six came out right the first time. The results are near the end.

Each was one paragraph, with the parts and numbers I cared about spelled out. Here's the LiPo charger's, word for word:

Single-cell LiPo charger board: USB-C 5 V input, MCP73831 charger set to 500 mA, a charge status LED, a JST-PH 2-pin battery connector, and an AP2112K 3.3 V regulator output on a 3-pin header. 2-layer board.

The others: an ESP32-C3-MINI-1 board with a BME280 over I²C, USB-C, an LDO, a status LED and reset/boot buttons; an NE555 flasher alternating two LEDs at about 1 Hz from a 9 V battery; an Arduino Nano socket driving two DC motors through a DRV8833; an RP2040 with QSPI flash, a 12 MHz crystal and two 20-pin headers on four layers; and an ATtiny85 driving an SSD1306 OLED, with an ISP header and USB micro-B power.

A run takes a few minutes and goes through part research, netlist, placement, routing and a DRC pass, with a log of what it decided at each stage.

The LiPo charger, the one board that was right as generated: 2 kΩ on PROG for 500 mA, the charge LED on STAT, the regulator fed from the battery, 5.1 kΩ on both CC pins.

None of these would have been caught by a design-rule check. All four boards passed one.

ESP32-C3: the reset button wasn't a reset button. I asked for "reset and boot buttons". BOOT was right, on GPIO9. "Reset" came out as a user button on GPIO4, with nothing on EN except its pull-up and capacitor. The planner read "reset button" as "a button".

555 flasher: one LED could never flash. The 555 itself was wired correctly (TRIG and THR tied, DIS between the timing resistors, RESET high). But the second LED had its cathode on ground and its resistor to 9 V, so it was simply always on. The timing was also off: 10 kΩ, 100 kΩ and 10 µF give 1.44 / (210 kΩ × 10 µF) = 0.69 Hz, not "about 1 Hz".

Nano motor driver: the Nano had no power. The prompt said "the Nano powered from the motor supply through its VIN pin". The VIN contact on the socket was unconnected, and the board's 5 V net hung off the Nano's +5V pin, which nothing on the board fed. Unplug the USB cable and the whole thing goes dark. The DRV8833 side was textbook, except VINT had 1 µF where the datasheet asks for 2.2 µF.

ATtiny85 OLED: wrong clock pin, no power, a duplicate header. The ATtiny85's I²C hardware (USI) uses PB0 for SDA and PB2 for SCL. SCL landed on PB1 and the push button on PB2. The USB micro-B connector was on the board but not wired to anything, and a second 4-pin header duplicated the OLED socket.

And one that wasn't the AI's mistake but it didn't catch: I asked for a 6-12 V motor supply on a DRV8833, which is rated for 10.8 V on VM (11.8 V absolute max). Nothing flagged it. That's on me as the designer, and it's exactly the kind of thing a tool should warn about.

Every fix was one plain-English message that named pins. For the 555:

D2 never flashes: its cathode is on GND, so it is always on. Connect D2's cathode to the 555 output (U1 pin 3, net LED1_CTL) instead of GND, keeping R4 from 9V to D2's anode. Also change R2 from 100k to 68k so the rate is about 1 Hz. Then reroute.

The editor rewired only the three affected nets and kept the other 58 traces where they were. 68 kΩ gives 1.44 / (146 kΩ × 10 µF) = 0.99 Hz. A second message added the 10 nF on pin 5.

The fix request on the right, with the edit log underneath: "Detecting D2 cathode tied to GND", then a reroute of only the nets that changed.

The lesson I didn't expect: re-check after every edit. On the ATtiny85 board, the message that moved SCL to PB2 and the button to PB3 also dragged the ISP header's MISO contact along with the button net, so the chip could no longer be programmed. It took a second message to put MISO back on PB1. The edit did what I asked; it also did something I didn't.

The ESP32-C3 board had a correct netlist and a clean DRC, and a bad layout. The ESP32-C3-MINI-1's PCB antenna is the end of the module beyond its top row of pads, and Espressif wants it at the board edge with no copper underneath. The first layout put the module in the middle of the board, antenna over a resistor, the regulator and a ground pour covering the whole bottom layer.

Before: module mid-board, antenna end over parts and the bottom-layer ground pour. DRC: clean.

One message ("move U1 to the top board edge with the antenna end facing out, no copper under it") fixed it. The root cause was in the footprint data: its courtyard covered only the pad field, not the antenna, so placement treated the antenna as free board. That's been reported.

After: the antenna overhangs the top edge. 21 parts, 32.6 × 44.1 mm, two layers, all nets routed.

The RP2040 board was the stress test: a 7 × 7 mm QFN-56 at 0.4 mm pitch, QSPI flash, crystal, USB-C, a regulator and two 20-pin headers on four layers. Where it was wired, it was right: SD0-SD3 mapped correctly to the W25Q16, BOOTSEL through 1 kΩ on the flash chip-select like the Pico, 27 Ω USB series resistors. But:

Honestly, that's the behaviour I want from a tool when it can't do something: say so, name the nets, and don't hand me files that look finished.

The fixes for these went into PCBEditor 1.3.5. On 19 October I ran the same six prompts again, word for word, with no chat edits, and reviewed the exports the same way.

Four of six were right the first time, up from one. Checked against the datasheets:

Two small mismatches remain. The 555's 10 nF control-pin capacitor sits on an electrolytic footprint. And the ATtiny85 board's BOM names a TE micro-B connector on a different maker's land pattern. Neither would stop the board working, but either would trip up an assembler.

So: better, and still not a replacement for the review. Every one of these turned up by working through the checklist below.

The AI saved me the drafting on all six boards: parts lookup, symbols, footprints, placement, routing. It didn't save me the engineering. Every mistake above was found by reading a datasheet, and every fix was a sentence I wrote.

The full walkthrough, with the routed boards, 3D views, the DRC result and the export options, is at pcbeditor.com/ai-pcb-design.