One of the things that surprised me most about the newly released GPT-6 Astra is how capable it has become at working with KiCad.
I happened to be planning a new hardware project at the same time: a small controller board based on Espressif’s new ESP32-S31 module, intended to become the “head” of a small desktop robot.
So I decided to use the project as a real-world test of GPT’s PCB design capabilities.
Before touching the electronics, I first asked GPT to generate a concept image of the robot from a simple description.
The PCB inside the robot’s head needed to include:
- An ESP32-S31 module as the main controller
- Camera, dual microphones, and a speaker
- An LCD display
- 12 RGB LEDs
- An IMU
- A ToF distance sensor
The input I gave GPT was surprisingly simple.
I uploaded two PDF schematics from Espressif reference boards based on the ESP32-S31, together with the robot concept image, and asked GPT to design the electronics for the robot head.
That was basically it.
First Test: GPT-5.6 in Chat
My GPT Work usage quota had just run out, so while waiting for the next usage window, I tried the same experiment using regular Chat with GPT-5.6.
For most of my software development work I currently use Claude Code, while keeping GPT running alongside it for architecture review, debugging, and alternative approaches. It is actually quite interesting to let two strong models challenge each other’s ideas.
The first thing I asked GPT-5.6 to generate was the schematic.
The result was technically interesting, but visually not very good.
The schematic was hard to read, and it was not consistently using the standard symbols from KiCad’s official libraries.
That said, I have been arguing for a while that traditional schematics may eventually become less important in much the same way that programming languages are gradually becoming less visible to the user.
What matters most to me is not how beautiful the schematic looks.
What matters is whether the electrical relationships between pins, nets, and functional blocks are correct.
So I asked GPT to redraw the power section using standard KiCad schematic symbols and conventional schematic formatting.
The result looked much more like something drawn by an experienced engineer:
I manually checked the connectivity and could not find any obvious errors in that section.
That impressed me.
Remember, I had only provided GPT with two PDF schematics. The ESP32-S31 was still very new, with relatively little reference material available online, and almost every component used in the generated design came directly from those two reference documents.
That tells me something important:
GPT-5.6 is no longer simply “drawing schematics.” It is starting to understand enough of the circuit structure to reconstruct and adapt an electronic design from reference material.
From Schematic to Component Placement
Next, I asked GPT to propose a PCB component layout.
Not bad at all.
The placement was logically organized around the product architecture rather than simply arranging components mechanically.
In Chat mode, however, many of the components did not appear to have their corresponding 3D models associated with them.
Then things became much more interesting.
GPT-6 Astra in Work Mode
Once Work became available again, I submitted essentially the same requirements to GPT-6 Astra.
After roughly three iterations, it produced a complete compressed KiCad project that could be opened with KiCad 7 or newer.
After extracting the archive, I found much more than just a .kicad_pro, schematic, and PCB file.
GPT had generated a fairly complete engineering project structure with a number of supporting files.
The schematic used a hierarchical design structure, divided into 13 functional blocks.
The components on each sheet were spaced rather generously, but every page represented a clearly separated functional module.
More importantly, the schematic quality was dramatically better than my earlier Chat experiment.
The design consistently used symbols from KiCad’s official libraries, and the net labels were placed in a clean and conventional way.
It was actually pleasant to read.
Then I opened the PCB.
Apart from nine unrouted nets, the component placement and routing were surprisingly reasonable.
And when I opened KiCad’s 3D Viewer, most of the components already had 3D models attached.
Again, these were largely models from KiCad’s standard libraries.
Is It Ready to Manufacture?
Not yet.
There are still things I would definitely review before sending this board to fabrication.
For example, I have not yet completed a detailed review of every schematic block, and the antenna keep-out and placement around the ESP32-S31 module still need improvement.
There are also some layout decisions that I would change manually.
But that is almost beside the point.
The remarkable part is that GPT created something this complete from only:
two PDF reference schematics + a short product description + a concept image.
No carefully prepared netlist.
No existing KiCad project.
No detailed component-placement instructions.
No step-by-step guidance.
It simply worked through the problem and produced a usable engineering starting point.
If I continue from this generated project and perform the normal engineering review, corrections, and optimization, I estimate that it can already save me well over half of the time I would normally spend on the initial design.
The More Interesting Question: What Happens When the Loop Closes?
Today’s workflow is still essentially open-loop.
The model reads reference material, reasons about the design, generates a schematic and PCB, and then hands the result to the engineer.
But imagine connecting that same model to a complete verification loop:
- Circuit simulation
- ERC
- DRC
- Signal-integrity checks
- Power-integrity analysis
- Thermal analysis
- DFM checks
- Component availability
- BOM cost optimization
- Datasheet verification
- 3D mechanical checking
Now the model would no longer just generate a design.
It could generate, test, diagnose, revise, and verify the design repeatedly until it satisfied a set of engineering constraints.
That changes the nature of PCB design quite dramatically.
A senior hardware engineer might spend several days turning an idea into a reasonably mature first PCB revision.
I can now imagine AI-assisted workflows producing a comparable starting point in well under an hour for many conventional embedded designs — with the engineer spending most of the time reviewing decisions rather than manually creating every symbol, net, footprint, and trace.
And as these verification loops improve, the quality gap will shrink quickly.
Maybe Schematics Will Become Like Source Code
I have held a slightly unpopular view for some time:
traditional schematics may eventually become an intermediate representation rather than the primary interface for hardware design.
Something similar is already happening in software.
Developers increasingly describe intent in natural language while AI systems generate Python, JavaScript, SQL, configuration files, and infrastructure definitions underneath.
We still need the code.
But humans do not necessarily need to write every line of it.
PCB design may follow the same path.
Future hardware engineers may spend much less time manually placing symbols and routing nets, and much more time specifying:
- Functional requirements
- Electrical constraints
- Mechanical constraints
- Cost targets
- Manufacturing constraints
- Reliability requirements
- Test requirements
The CAD files will still exist.
The schematic will still exist.
The PCB layout will still exist.
But they may increasingly become machine-generated engineering artifacts rather than the place where the design process begins.
For makers, this could be particularly powerful.
A huge amount of time in hardware prototyping today is spent not on the creative part of the project, but on repeatedly doing very familiar engineering work: selecting known circuit topologies, reading datasheets, creating footprints, wiring common interfaces, placing decoupling capacitors, checking pin mappings, and routing fairly conventional boards.
AI is getting very good at exactly this kind of work.
My ESP32-S31 robot head is still just an experiment.
I certainly would not send the current version directly to manufacturing without reviewing it.
But after seeing what GPT-5.6 and GPT-6 Astra can already do with KiCad, I think we are much closer to a different kind of hardware design workflow than many engineers realize.
Instead of opening KiCad and asking:
“Where should I start drawing?”
we may soon start with:
“Here is the product I want to build. Generate the first manufacturable version, show me the risks, and tell me what I need to decide.”
That is a much more interesting way to build hardware.
And I suspect we are going to see progress here much faster than most of us expect.
source https://blog.tindie.com/2026/09/i-designed-a-kicad-pcb-with-gpt-5-6-and-gpt-6-and-it-changed-how-i-think-about-hardware-design/
