In an October 26, 2026 article, hobbyist Matt Inglot describes using GPT through Codex and KiCad over roughly two months to develop a feature-rich Halloween prop controller PCB. He says ten manufactured boards arrived and the major features worked, while noting a pin-related flaw and substantial human steering, review, and iteration. The account is a single creator’s report, not an independent evaluation; it illustrates a possible agent-assisted hardware workflow rather than proving general reliability or performance.
This is a concrete example of an AI coding agent helping a hobbyist move from requirements and datasheets through schematics, PCB layout and routing to manufactured hardware—not just code. If workflows like this become more repeatable, they could lower the time and expertise needed to build custom electronics and let more people prototype physical products. The case also shows the limits: the creator reports substantial coaching and review, and a functional first batch still had a pin-selection flaw. It is one self-reported project, not evidence that AI can reliably design production-ready boards on its own.
Matt Inglot’s October 26, 2026 article reports that he used GPT via Codex and KiCad over roughly two months to develop a feature-rich Halloween controller PCB; ten manufactured boards arrived and, by his account, most features worked. He describes AI assistance with requirements, component research, datasheets, schematics, placement, routing, review, and simulation, while also reporting substantial human steering, design errors, and a pin-selection flaw. Separately, an electronics design engineer posted that an open-source MCP server lets Claude work inside Altium and showed it designing a four-layer LED board from a written specification. This is a distinct self-reported example, not independent validation of Inglot’s project; its demonstrated scope and quality remain unclear from the available description. Together the accounts make agent-assisted EDA a more concrete area to track, but they do not establish repeatability, reduced cost or time, or suitability for commercial or safety-critical hardware.
| source | object | author | score | comments |
|---|
| 🟠 reddit | I built a fairly complex PCB using GPT/Codex, got it manufactured, and it actually works. ChatGPT Retrieved article excerptOpen article · Retrieved 2026-10-28T15:24:11.798555+00:00 # I Used GPT to Design a Feature Packed PCB and It Actually Worked
### I spent my hard earned money manufacturing a PCB design that AI helped me create. Here’s how it went.
[Matt Inglot's avatar](https://substack.com/@mattinglot)
[Matt Inglot](https://substack.com/@mattinglot)
Oct 26, 2026
1
Share
**I just built a fairly complicated piece of hardware almost entirely with GPT via Codex and KiCad, and it works. It actually works!**
After 2 months of mostly steering GPT through the PCB design process, 10 newly manufactured circuit boards arrived at my doorstep, looking absolutely gorgeous and surprisingly functional.
This was a long journey. GPT 6 Astra, and Sol 5.6 (best available when I first started), have incredibly impressive electronics knowledge. But going from basic one-shot demos to actually producing a fairly complex PCB that’s manufacturable and satisfies numerous constraints is still a process.
I had to figure out how to “teach” GPT to:
- Search for components that JLCPCB stocks, identify good candidates, and verify their specs against the project’s needs.
- Accurately ingest PDF datasheets, extracting crucial technical information, package diagrams, and (at times incredibly lengthy) implementation recommendations.
- Lay out schematic diagrams in KiCad that are readable instead of an electrically valid but human-unreadable mess of overlapping symbols and wires.
- Assist with component placement.
- Reason through how to route the traces, and then do it.
- Perform numerous reviews and run simulations to validate each part of the design.
## **What the heck is a Halloween controller?**
My wife and I go all out on Halloween. From our early dating days of scaring pedestrians during Zombie Walks, to the current Haunted Circus that requires 8 volunteers to run it each year, Halloween has always been a full-out production.
Lights, sound, animatronic props, GAMES, candy, CARROTS, for one glorious night trick-or-treaters get to experience an other-wordly magical haunted world.
All of this spectacle requires electronics to set off props, coordinate audio and lighting, and to run increasingly complex games like “Off with Her Head” and “Steal the Banana”.
And here to provide all these electronics? The Halloween Controller! It is a standardized, feature-packed answer to an endless collection of custom, highly specific Arduino-powered boards.
Grab a controller out of the box, and you immediately have tons of functionality available:
- **Detect Motion:** motion detection and other sensor inputs from up to 4 different sensors.
- **Activate Store-Bought Props:** almost any store-bought animatronic that has a step pad input or “Try Me” button. It’s also very easy to hack fog machines and other props to make them controllable.
- **Play Audio:** loudly through a built-in amp, or via line-out to powered speakers.
- **Sync Jaw Movements to Audio:** I frequently override the built-in audio on store-bought props with our own speech. The controller makes syncing a prop’s moving jaw to that audio much easier.
- **Put on Light Shows:** build programmable light shows using any common addressable RGB strips like WS2812b, WS2815, etc.
- **Build Custom Props:** the controller provides 80%-100% of the electronics needed for fully custom animatronic props.
- **Wireless Control via ESP32:** the coolest feature! View controller stats and adjust settings like volume, motion detection range, and more directly from your phone.
Annnnnd it’s wireless! I can view the status of everything in our haunted circus from my phone and make tweaks on demand. A prop’s volume needs to be louder? Motion detection more sensitive? New logic to upload? All of this can be done without digging around for a USB port in the dark.
The wireless capability is soo nice! Here I am tuning the motion sensitivity of one of our props to better scare kids walking by.
## **The Development Process From Start to Finish**
### **Specifications: Using AI to Nail Down Hardware Specs**
The Halloween Controller’s journey started last year - I had built a *much* simpler version 1.0 with many of the same goals, but scoped down to what I could actually build in-time for Halloween as a squishy slow human that was using KiCad manually… uphill both ways.
Subscribe for free to get updates on my AI and hardware adventures.
The first controller was a game changer. But like with most of my creations, I immediately found issues and started dreaming up a grander version for next year.
A version 2.0 would pull the board forward to something much, much closer to an eventual shippable product (subscribe to know when/if that happens):
- Power regulation with 5.9-12V power input, with an actual electrical operating range of 5.4–13V. Version 1 bypassed power regulation by using 5V off USB power brick instead (bad decision).
- Power distribution with reverse-polarity and voltage protection, automatic DC/USB selection, current limiters, etc.
- Protected adapter-voltage pass-through (to be able to power a prop and controller with the same adapter).
- Built-in amplifier and audio playback instead of relying on the relatively limited and frustrating DFPlayer module. Plus DAC for line-out.
- More power and better protection for the dual accessory ports (for programmable LEDs, servos, etc)
- Everything 1.0 already had: ESP32 microcontroller with wireless support, ability to trigger up to 4 props through 4 electrically isolated totally overkill PhotoMOS SSRs, and 4 sensor/GPIO connectors (with 8 signal channels total instead of the previous 4).
Codex’s first job? Take the wish list above, alongside its own critique of V1, and work with me to create an actual set of specifications, complete with hard numbers behind them.
For example:
> “Support power adapters between 5.9 and 12V nominal, with an actual electrical operating range of 5.4 to 13V. Overvoltage protection up to 24V. May shut off, but not be damaged, between 13V and 24V.”
Spec development was an iterative process. GPT was extremely helpful in working through the different features to understand the impact that they have on each other and the constraints that they create.
Want a louder amp? Great, but now the audio must come off a rail not supplied by the USB port (or worse, implement power negotiation on the USB port). Want to be able to power the controller and a prop off the same power brick? *Vin* better support the power requirements.
### **Roughing an Initial Design and Bill of Materials Through AI**
Once GPT and I agreed on what the circuit actually needed to do, it was time for it to select the main components - the power regulation ICs, the amp and DAC, the current limiting circuitry, exact ESP32 module, and how these bits will work together.
Component selection can require a great deal of work. Work that I’ve always found a bit tedious, so I was glad to hand it off to an agent:
- Search for appropriately specced candidate components that are already in stock at my manufacturer of choice (JLCPCB).
- Read the component datasheet to confirm specs
- Read the component datasheet to understand how to implement it into the design
- Read the component datasheet to understand physical size.
- Iteratively combine candidate components into an actual design and understand the interplay between the parts’ specifications.
Coaxing GPT Sol 5.6 took a bit of prompting to break down the problem and allow it to understand the process and tools that it had available to do the above properly. Otherwise, like most LLMs, it had a tendency to take shortcuts and just authoritatively recommend whatever part selections it happened to have in its training data (heavily influenced by the same 20–40 year old parts used throughout countless electronics tutorials).
For example, in discussions with GPT, we discovered that JLCPCB has an API (!) that GPT can readily connect to through Codex. This immediately gave GPT a much more reliable interface than attempting to fumble through the JLC site with a web browser.
This process of discovering the best way to do something led to a pattern that would repeat itself many times over the course of the design. I would spend a good deal of time prompting and coaching GPT through complex tasks. We would run into issues and problem-solve them together. **Then** **once it was “trained” to do the work properly through this trial and error, I would ask it to create a skill that embodies everything it learned so that it would not need to be taught again.**
Once it had a part candidate, GPT still needed to do a deeper assessment of its suitability and how it would fit into the rest of the design. This meant reading datasheets reliably (a topic for another article), understanding the key parameters, and how components affect each other. For example, the requirements of the amplifier would greatly impact power regulator selection and design, and vice versa, leading to an iterative process of narrowing down components that would work, and work well together.
At this point GPT 5.6 Sol was still the top model, and it did an admirable job. It was incredibly good at synthesizing datasheet information (once it was taught to convert PDF files to a usable format), and understanding the complex interplay of multiple components within a circuit. It naturally considered power and voltage requirements, nominal vs absolute ratings, performance curves, and thermal impacts to select components that worked well together.
It did tend to over-engineer, sometimes comically so by default, and it was extremely free with how it spent my money. Being explicit with constraints was critical.
### **Refining the Design. And the Specs. And the Components.**
So far I have been painting a neat, linear process so far. In truth, moving forward to a new step in the design process did not mean leaving any of the other steps behind. More like adding steps while still doing the others.
As the design came together, assumptions were questioned, and costs came to light, things were reworked. Over and over.
The best (worst?) example was the power system, which endured multiple redesigns owing to multiple causes:
- GPT had a tendency to be extremely careful and literal with all specs, over-engineering everything to the nth degree to make sure that every edge case was covered. When it came to power regulation, which does have legitimately tricky considerations like inrush current, this spiraled out of control. I’m pretty sure at least one of GPT’s designs would have functioned on Mars.
- Just like humans, GPT made good old-fashioned mistakes, resulting in a power system that was simultaneously flawed, and yet extremely overengineered.
- I learned that every word in my specs had potential downstream consequences, and that being precise was important. An early version specced something like 5.5V - 15V, a range already accounting for tolerances. GPT alternatively read this ambiguity as absolute technical specs, and nominal values that had to be padded even further.
- At one point I thought it would be a good idea to have GPT write a simulation using ngspice. My failure to scope this work narrowly to what needed answering led to simulations that would take many hours to compute in a super realistic model, and yet not actually answer anything useful about whether the power design would work. Later, more focused simulations using TI’s PSpice and more careful prompting did lead to better simulations, so the idea was sound.
This makes GPT sound terrible, but it was just me climbing the same learning curve everyone has to climb when applying an LLM to a new task. Better prompting, more careful language, synthesizing learning into skills, and better review processes gradually led to a better experience. The next PCB design I create with AI should be scary fast.
### **Building an Actual Schematic**
At this point the design consisted of several AI-generated markdown files split across the different subsys | bacontreatz | 1 | 1 |
| 🟠 reddit | I built a fairly complex PCB using GPT/Codex, got it manufactured, and it actually works. codex Retrieved article excerptOpen article · Retrieved 2026-10-28T15:24:13.719052+00:00 # I Used GPT to Design a Feature Packed PCB and It Actually Worked
### I spent my hard earned money manufacturing a PCB design that AI helped me create. Here’s how it went.
[Matt Inglot's avatar](https://substack.com/@mattinglot)
[Matt Inglot](https://substack.com/@mattinglot)
Oct 26, 2026
1
Share
**I just built a fairly complicated piece of hardware almost entirely with GPT via Codex and KiCad, and it works. It actually works!**
After 2 months of mostly steering GPT through the PCB design process, 10 newly manufactured circuit boards arrived at my doorstep, looking absolutely gorgeous and surprisingly functional.
This was a long journey. GPT 6 Astra, and Sol 5.6 (best available when I first started), have incredibly impressive electronics knowledge. But going from basic one-shot demos to actually producing a fairly complex PCB that’s manufacturable and satisfies numerous constraints is still a process.
I had to figure out how to “teach” GPT to:
- Search for components that JLCPCB stocks, identify good candidates, and verify their specs against the project’s needs.
- Accurately ingest PDF datasheets, extracting crucial technical information, package diagrams, and (at times incredibly lengthy) implementation recommendations.
- Lay out schematic diagrams in KiCad that are readable instead of an electrically valid but human-unreadable mess of overlapping symbols and wires.
- Assist with component placement.
- Reason through how to route the traces, and then do it.
- Perform numerous reviews and run simulations to validate each part of the design.
## **What the heck is a Halloween controller?**
My wife and I go all out on Halloween. From our early dating days of scaring pedestrians during Zombie Walks, to the current Haunted Circus that requires 8 volunteers to run it each year, Halloween has always been a full-out production.
Lights, sound, animatronic props, GAMES, candy, CARROTS, for one glorious night trick-or-treaters get to experience an other-wordly magical haunted world.
All of this spectacle requires electronics to set off props, coordinate audio and lighting, and to run increasingly complex games like “Off with Her Head” and “Steal the Banana”.
And here to provide all these electronics? The Halloween Controller! It is a standardized, feature-packed answer to an endless collection of custom, highly specific Arduino-powered boards.
Grab a controller out of the box, and you immediately have tons of functionality available:
- **Detect Motion:** motion detection and other sensor inputs from up to 4 different sensors.
- **Activate Store-Bought Props:** almost any store-bought animatronic that has a step pad input or “Try Me” button. It’s also very easy to hack fog machines and other props to make them controllable.
- **Play Audio:** loudly through a built-in amp, or via line-out to powered speakers.
- **Sync Jaw Movements to Audio:** I frequently override the built-in audio on store-bought props with our own speech. The controller makes syncing a prop’s moving jaw to that audio much easier.
- **Put on Light Shows:** build programmable light shows using any common addressable RGB strips like WS2812b, WS2815, etc.
- **Build Custom Props:** the controller provides 80%-100% of the electronics needed for fully custom animatronic props.
- **Wireless Control via ESP32:** the coolest feature! View controller stats and adjust settings like volume, motion detection range, and more directly from your phone.
Annnnnd it’s wireless! I can view the status of everything in our haunted circus from my phone and make tweaks on demand. A prop’s volume needs to be louder? Motion detection more sensitive? New logic to upload? All of this can be done without digging around for a USB port in the dark.
The wireless capability is soo nice! Here I am tuning the motion sensitivity of one of our props to better scare kids walking by.
## **The Development Process From Start to Finish**
### **Specifications: Using AI to Nail Down Hardware Specs**
The Halloween Controller’s journey started last year - I had built a *much* simpler version 1.0 with many of the same goals, but scoped down to what I could actually build in-time for Halloween as a squishy slow human that was using KiCad manually… uphill both ways.
Subscribe for free to get updates on my AI and hardware adventures.
The first controller was a game changer. But like with most of my creations, I immediately found issues and started dreaming up a grander version for next year.
A version 2.0 would pull the board forward to something much, much closer to an eventual shippable product (subscribe to know when/if that happens):
- Power regulation with 5.9-12V power input, with an actual electrical operating range of 5.4–13V. Version 1 bypassed power regulation by using 5V off USB power brick instead (bad decision).
- Power distribution with reverse-polarity and voltage protection, automatic DC/USB selection, current limiters, etc.
- Protected adapter-voltage pass-through (to be able to power a prop and controller with the same adapter).
- Built-in amplifier and audio playback instead of relying on the relatively limited and frustrating DFPlayer module. Plus DAC for line-out.
- More power and better protection for the dual accessory ports (for programmable LEDs, servos, etc)
- Everything 1.0 already had: ESP32 microcontroller with wireless support, ability to trigger up to 4 props through 4 electrically isolated totally overkill PhotoMOS SSRs, and 4 sensor/GPIO connectors (with 8 signal channels total instead of the previous 4).
Codex’s first job? Take the wish list above, alongside its own critique of V1, and work with me to create an actual set of specifications, complete with hard numbers behind them.
For example:
> “Support power adapters between 5.9 and 12V nominal, with an actual electrical operating range of 5.4 to 13V. Overvoltage protection up to 24V. May shut off, but not be damaged, between 13V and 24V.”
Spec development was an iterative process. GPT was extremely helpful in working through the different features to understand the impact that they have on each other and the constraints that they create.
Want a louder amp? Great, but now the audio must come off a rail not supplied by the USB port (or worse, implement power negotiation on the USB port). Want to be able to power the controller and a prop off the same power brick? *Vin* better support the power requirements.
### **Roughing an Initial Design and Bill of Materials Through AI**
Once GPT and I agreed on what the circuit actually needed to do, it was time for it to select the main components - the power regulation ICs, the amp and DAC, the current limiting circuitry, exact ESP32 module, and how these bits will work together.
Component selection can require a great deal of work. Work that I’ve always found a bit tedious, so I was glad to hand it off to an agent:
- Search for appropriately specced candidate components that are already in stock at my manufacturer of choice (JLCPCB).
- Read the component datasheet to confirm specs
- Read the component datasheet to understand how to implement it into the design
- Read the component datasheet to understand physical size.
- Iteratively combine candidate components into an actual design and understand the interplay between the parts’ specifications.
Coaxing GPT Sol 5.6 took a bit of prompting to break down the problem and allow it to understand the process and tools that it had available to do the above properly. Otherwise, like most LLMs, it had a tendency to take shortcuts and just authoritatively recommend whatever part selections it happened to have in its training data (heavily influenced by the same 20–40 year old parts used throughout countless electronics tutorials).
For example, in discussions with GPT, we discovered that JLCPCB has an API (!) that GPT can readily connect to through Codex. This immediately gave GPT a much more reliable interface than attempting to fumble through the JLC site with a web browser.
This process of discovering the best way to do something led to a pattern that would repeat itself many times over the course of the design. I would spend a good deal of time prompting and coaching GPT through complex tasks. We would run into issues and problem-solve them together. **Then** **once it was “trained” to do the work properly through this trial and error, I would ask it to create a skill that embodies everything it learned so that it would not need to be taught again.**
Once it had a part candidate, GPT still needed to do a deeper assessment of its suitability and how it would fit into the rest of the design. This meant reading datasheets reliably (a topic for another article), understanding the key parameters, and how components affect each other. For example, the requirements of the amplifier would greatly impact power regulator selection and design, and vice versa, leading to an iterative process of narrowing down components that would work, and work well together.
At this point GPT 5.6 Sol was still the top model, and it did an admirable job. It was incredibly good at synthesizing datasheet information (once it was taught to convert PDF files to a usable format), and understanding the complex interplay of multiple components within a circuit. It naturally considered power and voltage requirements, nominal vs absolute ratings, performance curves, and thermal impacts to select components that worked well together.
It did tend to over-engineer, sometimes comically so by default, and it was extremely free with how it spent my money. Being explicit with constraints was critical.
### **Refining the Design. And the Specs. And the Components.**
So far I have been painting a neat, linear process so far. In truth, moving forward to a new step in the design process did not mean leaving any of the other steps behind. More like adding steps while still doing the others.
As the design came together, assumptions were questioned, and costs came to light, things were reworked. Over and over.
The best (worst?) example was the power system, which endured multiple redesigns owing to multiple causes:
- GPT had a tendency to be extremely careful and literal with all specs, over-engineering everything to the nth degree to make sure that every edge case was covered. When it came to power regulation, which does have legitimately tricky considerations like inrush current, this spiraled out of control. I’m pretty sure at least one of GPT’s designs would have functioned on Mars.
- Just like humans, GPT made good old-fashioned mistakes, resulting in a power system that was simultaneously flawed, and yet extremely overengineered.
- I learned that every word in my specs had potential downstream consequences, and that being precise was important. An early version specced something like 5.5V - 15V, a range already accounting for tolerances. GPT alternatively read this ambiguity as absolute technical specs, and nominal values that had to be padded even further.
- At one point I thought it would be a good idea to have GPT write a simulation using ngspice. My failure to scope this work narrowly to what needed answering led to simulations that would take many hours to compute in a super realistic model, and yet not actually answer anything useful about whether the power design would work. Later, more focused simulations using TI’s PSpice and more careful prompting did lead to better simulations, so the idea was sound.
This makes GPT sound terrible, but it was just me climbing the same learning curve everyone has to climb when applying an LLM to a new task. Better prompting, more careful language, synthesizing learning into skills, and better review processes gradually led to a better experience. The next PCB design I create with AI should be scary fast.
### **Building an Actual Schematic**
At this point the design consisted of several AI-generated markdown files split across the different subsys | bacontreatz | 157 | 28 |
| 🟧 echo.blog ⭐ | Inglot says GPT via Codex helped him iteratively specify, design, review, simulate, and manufacture a feature-packed Halloween controller PC | Matt Inglot | — | — |
| 🟠 reddit | I gave Claude Code ~600 tools to drive Altium Designer. Here it designs a full 4-layer PCB from a written spec ClaudeAI | Salitronic | 13 | 4 |