How AI turns a sentence into a validated PCB (and where it still can't)

“AI designs a PCB from a prompt” sounds like magic or marketing. It is neither. Under the hood it is a pipeline of well-understood steps, most of which are about checking rather than generating. This post walks through that pipeline the way Banana Board actually runs it, and is honest about where the approach still falls short.

Step 1: turn intent into components and a netlist

The first job is to read a sentence like “an ESP32 that reads a BME280 over I2C and drives a relay” and decide what parts that implies: a specific board, a sensor on an I2C bus, a relay module, and the power and ground connections that tie them together. The output of this step is a netlist — a list of which pin connects to which — not a picture. Everything downstream operates on that netlist.

Step 2: validate every connection against the real board

This is the step that separates a design tool from a chatbot. Each connection is checked against the target board's verified pin map. Is that pin actually capable of I2C? Is it an input-only pin that cannot drive a relay? Is it a strapping pin that will break booting if you hold it low? Are two outputs being wired to the same net? These electrical-rule checks (ERC) catch the mistakes that a plausible-sounding but unchecked answer will happily make.

• Power and ground integrity — nothing left floating, no shorts.
• Double-drive detection — two outputs must not fight over one net.
• Input-only and strapping-pin misuse — the classic microcontroller traps.
• ADC channel availability — analog reads assigned to pins that can do them.
• A power budget — the board must be able to source what the design draws.

Step 3: generate and compile the firmware

For a microcontroller project, the wiring is only half the design; the code has to match it. The firmware is generated for the exact pins that were assigned, then compiled with arduino-cli. If it does not build, that is caught here, not on your bench. Because the code and the wiring come from the same validated model, the sketch references the same pins the diagram shows.

Step 4: place and route a real board

Now the netlist becomes copper. The engine clusters functional groups, places the components, and routes traces on two layers. The result is design-rule-checked (DRC): trace widths, clearances, and via counts are measured against fab rules. When Banana Board shows a board's grade and DRC pass count, those are numbers computed from the actual routed copper — you can see this on the AI PCB designer page, where the preview is a real routed board, not a mockup.

Step 5: export something you can order

Finally the board is exported as standard RS-274X Gerbers with an Excellon drill file, mask and silkscreen layers, and a bill of materials with distributor links — the package a board house like JLCPCB or PCBWay expects. Prefer to finish by hand? The whole project exports to KiCad. You can explore the raw output in the free Gerber viewer.

Where it still can't help (yet)

Being honest about the limits matters more than the pitch. AI-driven design like this is genuinely good at common maker and prototype circuits built around supported boards. It is not a replacement for a professional EDA tool on complex work:

• High-speed, controlled-impedance, or many-layer boards need manual control — reach for KiCad or Altium.
• Exotic or unsupported parts fall outside the validated pin maps, and validation is the whole point.
• Mechanical and thermal constraints (enclosures, heatsinking, high current) still need a human in the loop.
• Analog performance corners — noise, EMI, precision references — are design judgement, not a checklist.

The right mental model is not “AI replaces the engineer.” It is “AI does the validated first 80% in minutes, and you decide the last 20%.” For a lot of projects, that first 80% is the whole thing.