In this guide
How AI Designs Hardware: LLMs, PCB Layout and the Audit That Catches Their Mistakes
On 3 November 2026 OpenAI reported that its GPT-6 Astra model designed a working hardware device — a desk device for talking to its Codex coding agent — in under a week, with no direct human edits. Astra set the requirements, chose the components, laid out the printed circuit board, wrote the firmware and the Codex integrations, and a contract manufacturer built prototypes in under a month. The same report admitted the part that matters most for students: getting the device ready for manufacturing "still required several rounds of review and iteration", because Astra "did not consistently account for the manufacturer's production limits, tolerances, or details required for assembly". This guide explains how a language model designs hardware, where it goes wrong, and how a student team audits every output before ordering a board. The worked example throughout is a student build that copies Astra's workflow, not its device: GPT-6 Astra-Inspired AI-Designed Hardware Device with LLM-Generated PCB, Firmware and 3D-Printed Enclosure.
What "AI-designed hardware" actually means
A large language model does not understand electronics. It predicts the next token in a sequence, trained on vast amounts of text — including datasheets, forum threads, tutorials and open-source hardware projects. When you ask it to design a device, it produces the most plausible-looking schematic, parts list and code for your description. Plausible is not the same as correct. The model has no circuit simulator in its head, no knowledge of the specific parts on your bench, and no memory of the last board it designed unless you paste it back in.
What it is genuinely good at: turning a requirements paragraph into a structured specification, shortlisting common components, drafting a first schematic, writing boilerplate firmware, and generating an enclosure model from dimensions. What it cannot do: verify that a footprint matches a package, check that a design passes the fabricator's rules, or know that two parts share one data pin. That gap is the whole project. The LLM drafts, the student verifies, and the audit log is the proof that the verification happened.
Step 1: requirements and component selection
Every hardware design starts as a sentence: a desk device that lets you talk to a coding agent hands-free. The student turns that sentence into a requirements brief — what the device must do, its size, its power source, its interfaces — and the LLM drafts a functional specification and a first component list from it. The model is useful here because component selection is largely pattern matching: for a voice device it will reach for the parts thousands of hobby builds use, and for this project that shortlist is an ESP32-S3 module for the controller, an INMP441 MEMS microphone for capture, a MAX98357A amplifier for playback, an SSD1306 OLED for status, an EC11 rotary encoder for control and a WS2812B LED for state.
The student then checks each part against its datasheet before accepting it — and the numbers matter. The ESP32-S3-WROOM-1 runs a dual-core Xtensa LX7 up to 240 MHz with 512 KB of SRAM, 384 KB of ROM and 8 MB of flash. The INMP441 captures 24-bit I2S audio with 61 dBA signal-to-noise ratio and −26 dBFS sensitivity. The MAX98357A delivers 3.2 W into a 4 Ω speaker at 5 V. None of those figures come from the model; they come from the manufacturer's datasheet, and the audit log records that each one was checked there. A part the model suggests that has no datasheet, no stock and no footprint does not get used, however confident the suggestion sounded.
Step 2: the schematic — where the first mistakes hide
The LLM drafts the schematic, and the student redraws it in KiCad. This is where the first real errors appear, and they are the same errors in almost every AI-drafted schematic. The most common is the missing decoupling capacitor: every power pin on a microcontroller needs a small capacitor close by to steady its supply, and the model's first draft for the student puck omitted them on the ESP32-S3 supply pins. The audit caught it because the rule is simple and checkable — a decoupling capacitor belongs close to each power pin — and the log records the fix.
The second common error is the wrong footprint. A footprint is the pattern of copper pads a part solders onto, and it must match the part's package drawing exactly. The model's first draft used the wrong footprint for the ESP32-S3 module, which would have meant a board the module physically could not sit on. The fix is mechanical, not clever: open the package drawing in the datasheet, open the footprint in KiCad, and compare the dimensions pad by pad. The third is the power rail: the microphone runs at 1.8 to 3.3 V while the amplifier runs at 2.5 to 5.5 V, so the schematic needs a regulator the model may not have included, and every part's supply voltage has to be checked against the rail it connects to.
Step 3: PCB layout and design-rule checks
Placement and routing is where a language model is weakest, because it cannot see the board. The student lays out the two-layer PCB in KiCad from the model's placement and routing guidance, and then runs the design-rule check — the automated test that verifies trace widths, clearances, drill sizes and annular rings against the rules the student set. The rules come from the fabricator, not the model: a typical low-cost two-layer process has minimum trace widths and spacings around 0.127 mm, and a board that violates them cannot be manufactured, however good it looks on screen.
Layout has rules the check cannot fully enforce. The I2S clock and data lines between the ESP32-S3, the microphone and the amplifier should be kept short and away from the switching amplifier output, because a fast-switching output next to a digital audio line is a source of noise. The microphone needs a clear acoustic path through the enclosure. The USB-C connector needs its CC pins terminated with resistors, or the port will not negotiate power correctly — the model's first draft left them floating, and the audit log records that fix too. The two-layer board keeps routing simple, which is a deliberate student choice: fewer layers means fewer places for a routing error to hide.
Step 4: firmware — the shared I2S bus
The firmware is where the model's draft is most useful and still needs review. The puck's audio path has a genuine design constraint: the INMP441 microphone and the MAX98357A amplifier share one I2S bus, so the firmware must switch the bus direction between capture and playback — it cannot listen and speak at the same time. The model's first draft assigned both devices the same data pin, a conflict the student found by building a pin table: every pin, every function, checked against the ESP32-S3 datasheet before the firmware was written.
The session state machine is simple enough to verify by reading it: idle, listening, thinking, speaking. Pressing the encoder knob starts a session, the WS2812B turns blue, the microphone captures speech, the ESP32-S3 streams it over Wi-Fi to the coding agent, the reply comes back as text, the puck converts it to speech, and the amplifier plays it through the speaker while the LED turns green and the OLED shows the reply. The model's firmware skeleton gives the student this structure; the student fills in the pin assignments, the I2S configuration and the error handling, and tests each state transition on the bench before trusting it.
Step 5: the enclosure — tolerances are real numbers
The enclosure is modelled in OpenSCAD and 3D-printed in PLA, and this is where the model fails most visibly, because it has no sense of physical tolerance. A 3D printer lays down plastic in layers about 0.2 mm thick, the plastic shrinks slightly as it cools, and a hole drawn at exactly the size of a part will usually be too tight for that part to fit. The model's first enclosure set the OLED window tolerance too tight, and the student fixed it by printing a test piece and measuring it with calipers — the same loop as the rest of the project: the model proposes a number, the student measures the real thing.
M3 brass inserts give the enclosure its screw threads, and their holes need the same treatment: drawn to the insert manufacturer's recommended size, test-printed, measured, adjusted. A PLA enclosure is a prototype material, not a moulded product housing, and the guide says so plainly: it suits a desk prototype and a review table, not daily carrying.
The audit: the checklist that catches what the model misses
The audit is a checklist, run before the board is ordered, and every item names the check and what it catches:
| Check | What it catches | Tool |
|---|---|---|
| Datasheet check | Wrong part, wrong ratings, wrong supply voltage | Manufacturer datasheet |
| Footprint check | Package that does not fit its pads | KiCad footprint viewer and package drawing |
| Decoupling check | Missing capacitors on power pins | Schematic review |
| Pin-map check | Two parts on one pin, I2S and I2C conflicts | Pin table against the datasheet |
| Design-rule check | Trace and clearance violations | KiCad DRC |
| Fabricator rules | A board that cannot be manufactured | Fabricator design rules |
| Power budget | A regulator loaded past its rating | Current sum across all parts |
| Tolerance check | An enclosure that does not fit | Calipers and a test print |
The student puck's audit log is the worked example: six issues found and fixed. A wrong ESP32-S3 footprint in the first schematic. Decoupling capacitors missing on the ESP32-S3 supply pins. An I2S pin conflict with the microphone and amplifier on the same data pin. An OLED I2C address assumed to be 0x3D when the part uses 0x3C. An enclosure tolerance too tight for the OLED window. USB-C CC pins left floating. Each entry records the check that caught it and the fix applied — that log is the review thread of the whole project, and it is also the honest answer to the question of whether the AI designed the hardware: it drafted it, and the audit made it buildable. The full parts list, wiring and test procedure are in the project topic: GPT-6 Astra-Inspired AI-Designed Hardware Device with LLM-Generated PCB, Firmware and 3D-Printed Enclosure.
A small audit script
The simplest audit to automate is the bill of materials: every part needs a datasheet reference and a footprint before the board is ordered. A short script makes the check explicit and repeatable, and it fails loudly instead of silently:
# BOM audit: every part needs a datasheet reference and a footprint
# before the board is ordered. Anything missing fails loudly.
BOM = [
{"part": "ESP32-S3-WROOM-1-N8", "datasheet": True, "footprint": "ESP32-S3-WROOM-1"},
{"part": "INMP441", "datasheet": True, "footprint": "INMP441"},
{"part": "MAX98357A", "datasheet": True, "footprint": "WLP-9"},
{"part": "SSD1306 OLED", "datasheet": True, "footprint": "HEADER-4"},
{"part": "EC11 encoder", "datasheet": False, "footprint": "EC11"},
{"part": "WS2812B", "datasheet": True, "footprint": "5050"},
]
missing = [p["part"] for p in BOM if not p["datasheet"] or not p["footprint"]]
if missing:
print("AUDIT FAIL - incomplete entries:", ", ".join(missing))
else:
print("AUDIT PASS - every part has a datasheet and a footprint")
The EC11 entry fails on purpose in this example: its datasheet flag is False, so the script reports it and the board is not ordered until the student finds the datasheet and confirms the footprint. That is the whole method in miniature — a check that cannot pass silently.
Astra versus the student workflow
| Item | GPT-6 Astra (reported) | Student build |
|---|---|---|
| Design method | Reported: Astra set requirements, chose parts, laid out the PCB and wrote firmware with no direct human edits | LLM drafts, student audits every output, audit log kept |
| Manufacturing review | Reported: several rounds of review and iteration needed | DRC, fabricator rules and audit log before ordering |
| Design time | Reported: working device in under a week, prototypes in under a month | One semester build |
| BenchCAD score | Reported: 0.594 for Astra, 0.875 for a newer unnamed internal model | Not applicable — BenchCAD measures AI design models, not student builds |
| Hardware | Not disclosed in the report | ESP32-S3 puck with I2S audio, OLED and 3D-printed enclosure |
BenchCAD is the benchmark OpenAI cited for this work: it tests whether a model can rebuild 3D parts and identify connections on circuit boards. Astra's reported 0.594 against 0.875 for a newer unnamed internal model is a reminder that even the model OpenAI showcased is, by its own benchmark, wrong about two-fifths of the time — which is why the student workflow keeps the human in the loop rather than copying the no-human-edits claim.
Frequently asked questions
Can an LLM design a PCB on its own?
No, not to a standard you can order. It can draft a schematic, suggest parts and write firmware skeletons, but it cannot verify footprints, run a design-rule check or know a fabricator's limits. The student build treats the model as a drafting assistant and the audit as the design step that makes the board real.
Why does the model keep omitting decoupling capacitors?
Because it is completing a pattern, not reasoning about power integrity. Decoupling capacitors are small, repetitive and easy to leave out of a generated schematic, and their absence often only shows up as unreliable behaviour on the bench — a microcontroller that resets under load. The audit checks for them explicitly, one power pin at a time.
What is BenchCAD?
A benchmark that tests whether an AI model can rebuild 3D parts and identify connections on circuit boards. OpenAI reported Astra scoring 0.594 on BenchCAD 2.0 at its highest reasoning setting, against 0.875 for a newer unnamed internal model. The score measures the model, not any student build, and it is the clearest evidence in OpenAI's own report that AI-designed hardware still needs human review.
Do I need to know KiCad to do this project?
Yes, at a basic level. The LLM can explain each step and draft the schematic, but the student lays out the PCB, runs the design-rule check and fixes the footprint and pin errors the audit finds. Knowing the tool is part of the learning: the audit is only possible because the student can open the design and check it.
What does the student puck actually do?
It is a push-to-talk desk device for talking to a coding agent hands-free: press the encoder knob, ask a question out loud, and hear the agent's reply through the speaker while the OLED shows the session state. The device is the demonstration; the AI-assisted design workflow and the audit log are the project. The full build is published as GPT-6 Astra-Inspired AI-Designed Hardware Device with LLM-Generated PCB, Firmware and 3D-Printed Enclosure.
What if the audit finds nothing wrong?
Then check harder. A clean first draft from a language model usually means the checks were too shallow, not that the design is perfect. Re-run the footprint check pad by pad, re-read the pin table against the datasheet, and print a test piece of the enclosure before ordering the board. The audit log is only convincing when it records real fixes.
Limitations
- All GPT-6 Astra figures in this guide are reported figures from OpenAI's 3 November 2026 research post, not measurements of any student build and not guarantees of what any other model achieves.
- The student build is a lab-scale prototype inspired by the reported Astra workflow; it shares no parts, performance or capability with OpenAI's device.
- A language model's output quality depends on the prompt, the model and the task; the same request can produce a good draft one day and a wrong footprint the next, so the audit must be run on every revision, not only the first.
- The puck needs a network connection and valid coding-agent credentials, its single microphone and small speaker suit a quiet desk, and its two-layer board limits dense routing.
- Round-trip latency is measured by the student in the test session and recorded in the report; no figure is promised in advance, and the numbers in this guide are datasheet values or design targets, not test results.