PCBs without the magic smoke, using agents
27 October 2026, 2,046 words
Since May 2026, I’ve been experimenting with using agents to assist with the PCB design process in KiCad. I wanted to share the workflow and results I’ve found spinning out boards that generally require low mental effort but would usually be large time sinks. With this workflow, I’ve cut my design and implementation time in half.
An Illustrative Example
I lead the HackerFab node at UBC, where we are building the tools to fabricate semiconductor devices from scratch. A bunch of these tools have shared low-voltage power needs and also some AC power requirements that warranted designing a general tool power board. This is a trivial board, so it serves as a good example.
Design Specifications
The quality of your spec is make-or-break for the quality of your output. This is something I still like to have a lot of control over. For this example board, I started by getting user requirements from the team. This particular rev targeted powering a BLDC-motor-based spin coater and a tube furnace that uses AC mains to heat Kanthal wire around a quartz tube.
Tube furnace used for thermal annealing. Hits 1000 °C. Spin coater used for depositing uniform thin films like photoresist on wafers.
Here’s what I got from the team:
- Input:
120V AC from the wall through the socket, most likely through screw terminals. Try to use the terminals in the attached image, since the socket output wires are in the U-shape
- Outputs:
- 3V3, 5V DC (~500mA) for MCUs, most likely regular screw terminals. Might be good to have several of these to power other misc. components (2 of each)
- Some applications like having 12V 1A cont 2A peak. Potentially have these through regular screw terminals if we have projects that might need them (2 of these, one for motor at 1A cont. 2A peak)
- LiPo battery pack style connector (XT60) for 12V 5A cont (spin coater BLDC)
- Direct AC output of input AC through regular screw terminals (tube furnace SSR)
I usually take user needs and translate them into a functional spec, which is more prescriptive and leaves less room for guessing on the agent’s front:
- fork terminal connector → screw terminal that takes 120 VAC
- AC:DC rectifier → 12V (48 W + 5 W + 3.3 W + 60 W = ~120W → if a single supply powers multiple tools simultaneously)
- On standard screw terminals:
- 12 V (2x taps rated for 1A nominal, 2A peak = 4A peak)
- potentially isolated DC/DC converter (noise isolation for low voltage sensors):
- 12 V → 5 V (2x taps rated for 500mA)
- 12 V → 3.3 V (2x taps rated for 500mA)
- Use INA226 or equivalent for current sense (per rail instead of per tap)
- intelligent switches on each tap (EN, reverse polarity, overcurrent protection)
- AC → AC with Hall effect AC current sensor in between
- for BLDC/ESC: 12V, 5A through XT60 connector → sets the upper bound for power from AC:DC on single tool supply
- Mounting holes (M3)
- Status LEDs per rail
- Fuse per rail, TVS per tap
- An on-module NTC as well as an external NTC connector for monitoring overtemp on an external component (like an SSR)
- 12V PWM fan connector (expect <100mA) → temp control loop with the NTCs
- CAN-based communication to tool-specific controller → CAN transceiver + 4-pin screw terminal (5V, CANH, GND, CANL). Assume this 5V tap powers the micros on the CAN network.
- A small micro (Raspberry Pi Pico 2 footprint) that has sufficient I/O for the needs above
Moving forward, assume I’m using Sonnet 5.5 High in Claude Code. This was the best trade-off between speed and reasoning for this project. Throughout the design process, I maintain a spec sheet scratchpad on Notion; with the Notion MCP hooked up, I had Claude generate a table that summarizes the functional spec:
┌─────────────┬────────────────────────────────┬───────────────────────────────────────┬─────────────────────────────────────┬──────────────────────────────┐
│ Rail / port │ Source │ Spec │ Protection │ Termination │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ AC in │ Wall, 120 VAC │ L / N / PE │ 3 A fuse to the AC/DC module, 10 A │ 3-position screw terminal │
│ │ │ │ fuse on the furnace leg, varistor │ │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ AC out │ Passthrough of AC in, through │ Up to about 8.3 A (1000 W) to an │ │ │
│ (furnace) │ an on-board Hall current │ external SSR and the tube furnace │ 10 A fuse │ 3-position screw terminal │
│ │ sensor │ │ │ │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ │ │ 80 W, 6.7 A continuous. This feeds │ Surge-clamp diode, bulk capacitor, │ │
│ 12 V bus │ Isolated AC/DC module │ everything below; there is no 24 V │ rail current/voltage monitor │ Internal │
│ │ │ bus. │ │ │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ 12 V ESC │ 12 V bus, switchable │ 5 A nominal for the spin-coater motor │ 7.5 A blade fuse, high-side switch │ XT60 │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ 12 V ×2 │ 12 V bus, each switchable │ 1 A nominal, 2 A peak each │ 3 A blade fuse each, high-side │ Screw terminal │
│ │ │ │ switch │ │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ 12 V fan │ 12 V bus │ PWM fan, about 60 mA │ 500 mA resettable fuse │ 4-pin fan header (PWM and │
│ │ │ │ │ tach) │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ 5 V ×2 │ Non-isolated buck from 12 V │ 500 mA each, current-limited at about │ Per-tap current-limit switch │ Screw terminal; tap A is on │
│ │ │ 0.7–0.86 A │ │ the control-link connector │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ 3.3 V ×2 │ Non-isolated buck from 12 V │ 500 mA each, current-limited at about │ Per-tap current-limit switch │ Screw terminal │
│ │ │ 0.7–0.86 A │ │ │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ SSR drive │ 5 V rail, low-side driver │ Drives the furnace SSR input, 12 mA │ Series resistor, pulldown │ 2-position screw terminal │
│ │ │ max │ │ │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ Control │ Pico 2 and CAN transceiver, │ CAN H/L, 5 V and GND to a control │ Transceiver ESD protection, 120 Ω │ 4-pin connector │
│ link │ plus 5 V tap A │ board │ termination (solder jumper) │ │
├─────────────┼────────────────────────────────┼───────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────┤
│ Temp input │ Pico ADC │ NTC thermistor on the SSR heat sink │ Divider resistor │ 2-position screw terminal │
└─────────────┴────────────────────────────────┴───────────────────────────────────────┴─────────────────────────────────────┴──────────────────────────────┘
Part Selection
The bane of a system EE’s existence used to be part selection and fighting against crappy parametric search on catalogs like LCSC. Lucky for us, there is a neat MCP called pcbparts, which wraps LCSC, DigiKey, and Mouser. I can fetch and compare parts in seconds, which would normally take hours of reading datasheets:
Example MCP search for the AC/DC block.
During this process of part selection, I also generate some form of human-interpretable memory for design decisions, usually in the form of a markdown scratchpad. This is a great way to ground the model on long-horizon EE tasks like this. Imagine you are working with a junior EE: it is your job to make sure both of you are on the same page throughout the design lifecycle. In this case, this means regularly plumbing the bloat from these context docs. Eventually, I’ll migrate to having my schematics (with annotations) be the single source of truth.
Block Diagrams
Once I selected all the components for this board (minus some jellybean components/passives), I had the agent generate a Mermaid diagram that acts as the guiding reference for schematic drawing and human review:
Mermaid diagram for this board.
You can also enforce color coding and line widths depending on pwr/analog/digital etc. to improve readability, but I’m going to be lazy for this board.
Schematic Capture
Before drawing anything, the parts from the block diagram need to exist in KiCad. Our team has a shared KiCad library which I updated with the parts I needed off of Component Search Engine. This process also used to be quite painful with KiCad, but now it’s as simple as invoking a Claude skill. Library management is now a non-issue; we are past the days of having to click through KiCad’s UI to assign 3D models and footprints to schematic symbols.
Usually, I’m quite surgical with agent use in schematic capture. I’ll draw hierarchical sheets and define sheet ports/buses myself and then begin filling out each hierarchical sheet iteratively with the agent. However, I wanted to see if it could “one-shot” the schematic for this board.
I populated a local project folder with all the relevant datasheets and app notes for core active components ahead of letting Sonnet draw. What you see below is the output of a single prompt to generate the schematic from the block diagram and selected parts (with some manual cleanup to make things more legible):
“Based on the spec at {ref the Notion spec} and the planning we have done in {ref the design decisions and other relevant docs like ports and pins, BOM table, etc}, proceed with schematic capture. Strategize by designing functional groups first, then decide what resides in hierarchical sheets. Expose sheet ports and rely on buses to group nets and avoid clutter. The top-level sheet should closely resemble the high-level block diagram. Refer to {point at datasheets folder} for typical applications of the parts used.”
Top level
Mains
12V Bus
5V and 3V3 Rails
MCU
Safe to say Sonnet 5.5 did indeed one-shot the schematic, albeit with a well-scoped, high-level design and BOM established.
If you like to use a particular design language for schematics, passing a .kicad_sch exemplar with rules around designators and common annotations (power dissipation on resistors, LDOs, FETs, ripple on switching supplies, f3dB, etc.) saves a ton of time.
This is a good time to plug in kicad-happy, a set of agent skills for reviewing your KiCad project. It runs an analysis covering power/protection, analog (static and SPICE), and digital specs, and it catches a lot of common mistakes. It’s a must-run for me before layout. The power tree generation skill is a godsend; here’s what it built for this project:
120 VAC in (L / N / PE)
├── 10 A fuse → Hall current sensor → AC out → external SSR → tube furnace (≤ 1000 W, 8.3 A)
└── 3 A fuse → isolated AC/DC module (12 V, 6.7 A continuous / 7.4 A for 10 s, 92 % efficient)
└── 12 V bus (5 mΩ shunt + current/voltage monitor, surge-clamp diode, bulk cap)
├── 3 A fuse → P-FET switch → 12 V tap A 1 A nominal / 2 A peak
├── 3 A fuse → P-FET switch → 12 V tap B 1 A nominal / 2 A peak
├── 7.5 A fuse → P-FET switch → ESC (XT60) 5 A nominal / 5 A peak
├── 500 mA resettable fuse → fan header 0.06 A nominal / 0.08 A peak
├── Buck 5 V, 2 A (33 mΩ shunt + monitor)
│ ├── current-limit switch → 5 V tap A (CAN control-link connector) 0.5 A, limit 0.72–0.86 A
│ ├── current-limit switch → 5 V tap B 0.5 A, limit 0.72–0.86 A
│ └── Schottky OR-ing → Pico 2 VSYS → on-board 3.3 V (≤ 0.3 A, logic only)
└── Buck 3.3 V, 2 A (33 mΩ shunt + monitor)
├── current-limit switch → 3.3 V tap A 0.5 A, limit 0.72–0.86 A
└── current-limit switch → 3.3 V tap B 0.5 A, limit 0.72–0.86 A
Layout and Placement
For this project, I knew the board outline dimensions I was restricted to, since it needs to sit in the front panel of our tube furnace:
The empty front panel of our tube furnace, waiting for the power board.
Another layout concern for this board was AC/DC isolation and creepage specs. I had a local folder for design guides (from Texas Instruments, etc.) and IEC standards for high-voltage AC to low-voltage DC boards. Based on these guidelines and JLCPCB capabilities, I had the agent create custom design rules for this board, writing them into the .kicad_pcb file.
There are two ways to approach using agents at this stage:
- You do the initial layout of functional groups and hand over high-level layout given board outline restrictions (or vice versa).
- You give it the board outline and let it rip on layout end to end.
Irrespective of approach, my take is that the agent is:
- good at: brainstorming layout ideas, anchoring connector placements and core ICs, keeping switching/high-frequency circuitry away from low-frequency circuitry
- bad at: ratsnest awareness, passive placement (e.g., decoupling, pull-ups)
I’m not yet impressed with agent performance on layout tasks. I think the layout brainstorming is super useful, especially on space-constrained boards with top and bottom side placement, but when it comes to doing real layout, it’s definitely not one-shottable (yet). Here’s an example from this project:
Initial layout attempt.
I liked the way it packed the fuses and connectors, and after a suggestion to use the space under the Pico, which the courtyard was restricting, it did a decent job with the passives there as well. It still required a lot of optimization to clear up ratsnest crossings and generally do more logical placement based on energy flow (12V→5V and 12V→3V3).
Another useful agent task is planning out rule areas for copper pour keepouts based on this initial layout on the User.Drawings layer. I’m a fan of trial-and-erroring ideas on top of the drawings layer since it has a relatively fast turnaround and is non-disruptive to existing layout.
Routing
The consensus belief is that autorouters are bad, and if you ask your agent to do routing it will most likely rely on one. I came across this X post on a prompt for routing that I found useful:
PHBD@0x50484244A few KiCAD <-> LLM PCB layout tips from personal experience. Prompt it to: - Use KiCAD 10.99 (Nightly build, adds scripting features) and prompt it to interact with the program via KiPy + computer-use tools. - Not use autorouters like Freerouting. - Place components one at…October 14, 2026, View on XHere’s how it did on this board (I didn’t use the nightly build, btw):
Top Side
Bottom Side
Here are my thoughts on routing:
-
Great at fanouts; I liked the Manhattan routing scheme it followed on this board.
-
Competent at copper pours and via stitching.
-
Still doesn’t have a good internal representation of trace/loop inductances → will occasionally send long traces to GND vias from pads.
-
I would still route sensitive nets like controlled-impedance differential pairs myself.
- The agent is very useful for setting up net classes for these traces.
-
Decent understanding of trace current capacity but messes up KCL sometimes (e.g., a high-current trace into the Hall sensor pins):
Net-net, it still saved me more time than if I were to route it myself. With a little back-and-forth based on the review I did, I basically didn’t need to touch routing.
Outlook
The final power board after some manual tweaking.
Overall, I saved a ton of time on this board by using Sonnet. The time savings are currently skewed toward the part selection and schematic capture, but it is just a matter of time before it accelerates every stage. You can find the full KiCad project for this board here:
UBC-Hacker-Fab/tool-power-supplygeneral power supply for toolsThis example scratches the surface of what you can do with agents when designing boards with more discrete analog electronics. I’ve used them in the past to help simulate INAs, TIAs, class E amps, etc., and they are especially useful for writing annoying directive chains in LTspice.
There is definitely room to explore field solvers on top of KiCad to optimize agent-driven designs. I saw a recent post of someone simulating a half-bridge on a PCB using openEMS on top of KiCad-exported gerbers. Making the solution space smaller with better parametric feedback loops is still an open area.
Michael W.@Michaelskywal1/16 Every half-bridge hides a tiny bell: copper plus FET capacitance. Switch too hard and it rings, hundreds of millions of times a second. I simulated a real open-source motor controller at 48 V. Driver at full strength: its 80 V FET takes an 81 V hit. Turned down: clean. 🧵There is a class of boards that frequently get replicated at every company or design team building hardware: breakout boards, generic power supplies, adapters, switches, etc. As a systems EE, I would love to spend 0% of my time building repetitive boards and 100% of my time designing novel systems and circuits and translating research ideas to real problems. This is why I’m very optimistic about what agents are going to do for hardware engineering.
References
- pcbparts MCP:
PCB Parts MCP Server design-decisions.mdfor this project:
design-context/design-decisions.md- Claude skills for setting up and ingesting new parts into a KiCad lib:
.claude/skills - kicad-happy agent skills:
aklofas/kicad-happy - PHBD post on layout/routing prompt: Post by PHBD
- Power board repo:
UBC-Hacker-Fab/tool-power-supply - Michael W. post on an openEMS simulation on top of KiCad: Post by Michael W.