Read the Full Series
This article is one part of a walkthrough detailing how we recreated an NXP i.MX 8M Mini–based computer using Quilter’s physics-driven layout automation.
On September 4, 2026 OpenAI launched GPT-6 Astra with a showcase video of the model completing PCB layout in KiCad. The clip is a 15-second condensed playback of a 2-minute-54-second run, and OpenAI describes it as turning a schematic into a "manufacturable PCB" by placing components and routing copper. This presentation has created a lot of commentary in the electrical engineering community. One repost of the clip on X passed 800,000 views within days. The KiCad forum had a thread on it within a day. Hackaday had a piece within two, asking whether AI can now design PCBs "that just work." Quilter has been working on automating layout with AI for several years, so we naturally thought we should contribute to this conversation.
LLMs have gotten better at hardware-adjacent work: reading datasheets, drafting schematics, reviewing a layout image, and now orchestrating CAD tools. Layout itself is a more difficult problem for LLMs to solve. We wrote about why sixty years of autorouters failed to earn engineers' trust. The Astra demo is worth looking at through that lens as well.
What Did the GPT-6 Astra PCB Demo Actually Show?
The Astra video demonstrated a frontier model operating a graphical ECAD tool (KiCad) end to end. That is new, and it is the strongest computer-use result any lab has shown on electronics.
The launch post lists a "Circuit board" example alongside game development and a Form 1040. It publishes no PCB-specific benchmark. The closest hardware metric in the post is BenchCAD, which tests reconstructing 3D objects from renders by generating CAD code, which is mechanical CAD, not board layout. The PCB result is a single video.
The commenters who defended Astra on the KiCad forum and the ones who criticized it converged on one point: today an LLM working on a board is, in one supporter's words, "trying to build a PCB blindfolded and handcuffed," and the fix is to give it deterministic tools to orchestrate. The thread's original poster, who uses LLM-plus-KiCad MCP setups, summarized the current state as "moderately good at PCB design but still very bad with high frequency signals," and "not great" on HDI and BGAs. And one designer summed it up well: a lot of people on the internet learned what an autorouter is this week.
Is an LLM a More Capable Autorouter?
The first commercial autorouters shipped in the 1970s, built on a maze-routing algorithm published by C. Y. Lee at Bell Labs in 1961. Every generation since has been measured on completion rate, a percentage of nets the tool connected without violating design rules.
Engineers learned to distrust that number for a reason. A board can be 100% connected and pass DRC but still have return-path discontinuities, poor impedance control, excessive coupling, or assembly problems. Connecting pins is not the same as producing a board that will perform as expected.
If we look at the Astra demo through this lens, we will see nets getting connected. Now Astra did place components as well, and that is different from traditional autorouters. However, "manufacturable" in OpenAI's description means the output can be sent to a fab. Nothing in the demo, or in the launch post, speaks to whether the finished board behaves as intended. The model has no way to evaluate that, because nothing in generating a KiCad file computes what the circuit will do. An LLM operating an ECAD GUI is a more capable operator pursuing the same objective.
Autorouter vs. LLM vs. Physics-Driven AI: How the Three Approaches Compare
Dimension | Traditional autorouter | LLM operating ECAD (e.g., GPT-6 Astra in KiCad) | Physics-driven AI (Quilter) |
Core approach | Hand-tuned heuristics and rule rankings | General-purpose language model driving a GUI or code interface | Reinforcement learning + classical solvers + computational geometry |
Problem framing | Placement is an input; route the nets | Sequential steps in a GUI: place, then route | Placement and routing solved as one coupled problem |
What it learned from | Rules encoded by engineers | Published text, code, and whatever board files are public | Synthetic training problems scored against physics; not human-designed boards |
Physics evaluation | None; DRC only | None inside generation; external tools can be called, results must be interpreted by the model | Physics Rule Checks run during candidate generation |
Objective | Net completion against design rules | Task completion as judged by the model | Layout candidates that pass DRC and targeted electrical checks |
Output | One result, often 90% with days of cleanup | One result per session | Dozens to hundreds of ranked candidates in native ECAD format |
Compute | Single workstation | Large, but spent on token generation for one board per session; ECAD runs locally | Cloud-scale parallel placement, routing, and checks across many candidates |
Documented strength | Simple, non-critical boards | Schematic drafting, datasheet reading, component selection, layout review | Dense boards within its stated operating range |
We have to acknowledge that this is where things stand today. Technology is evolving fast. LLMs may learn to orchestrate multiple tools well enough to address the problems above, and if artificial general intelligence (AGI) arrives, problems like these may look very different. As of the writing of this post, however, LLMs are still not well-suited to solve PCB layout, for several structural reasons.
Why Do LLMs Struggle With PCB Layout?
Placement and Routing Are One Coupled Problem
Layout is two problems tangled together. Placement decides where each component is located, and routing then connects them. And they can't be separated: you can't judge a placement until you try to route it. The classic autorouter took placement as a fixed input and started laying copper, and when routing got stuck it blamed the floor plan and quit.
An LLM operating KiCad sequentially, place then route, reproduces the same decoupling. Several voices on the KiCad forum thread made the point that routing is not even the hard part. One called placement "the hard problem," noting that it requires understanding the circuit and that a good placement has autorouted acceptably well for thirty years. Another said what matters is where components sit "in relation to others," and how that interacts with routing and real-world physics.
There Is No Training Data, and Hardware's Feedback Loop Is Too Slow to Create It
LLMs learn from what has been published. In software, that means decades of public code plus the full lifecycle of bugs and fixes. Hardware has almost none of that. As one forum member put it, the available PCB corpus is skewed toward hobby designs because "most of the high quality professional PCBs will be proprietary." Another added: you need bad examples and their fixes, not just good examples, and very few complete hardware design lifecycles exist publicly, from wrong footprint through crosstalk mitigation.
The reason those failure examples don't exist is the same reason they are hard to generate: hardware's feedback loop runs at fabrication speed. Software tolerates a 97% solution because the fix can be shipped the following day, and the reason LLMs got good at code is that the cost of finding out a program is wrong is the time it takes to build it. The lifecycle for finding a PCB issue "is measured in fabrication and assembly time with real-world cost." One professional in the Hackaday comments described what that cost looks like: if a hardware issue surfaces a year later, "my boss has to lie to the customer… the customer go to court, newspaper write about it. There is much higher pressure to deliver 100% solution." An approach that relies on a model learning from its mistakes needs those mistakes to be cheap and fast to observe. Fab runs are neither.
There is a deeper problem than just scarcity of data. Even with a perfect dataset, a model trained to imitate finished boards is bounded by the boards it learned from. Give it a design unlike anything it has trained on, and it falls back on the nearest example it has seen, which may or may not be right. DeepMind's AlphaGo Zero, trained on nothing but the rules of Go, beat the version trained on human games 100 to 0; a comparison model trained on human data learned faster at first but plateaued at lower results (Silver et al., Nature, 2017).
Quilter's approach follows the second path, and it solves the feedback-loop problem at the same time. Quilter does not learn by copying customer layouts or imitating finished human designs. The system learns from generated attempts, synthetic training problems, and classes of layout challenges, scored against physics simulation, where a failed candidate costs compute rather than a fab run. Commercial customers' designs are not used in the training pipeline at all; designs submitted through the free version are used to generate synthetic training problems, not to reproduce design patterns.
Layout Is Spatial and Geometric, a Documented LLM Weakness
Placement and routing are problems about geometry in a constrained 2.5D space: where things sit relative to each other, how much room a via consumes, whether a return path stays intact under a signal. This is a category where LLMs underperform.
GeoGramBench (ICLR 2026) evaluated 19 frontier LLMs on procedural geometry reasoning and found that even reasoning-oriented models scored below 50% on the hardest tier. A 2026 study of spatial imagery reasoning found the same qualitative failure pattern across every frontier model tested, with the best model well behind human performance on the SpatialViz benchmark. The research has shown consistent pattern so far where LLMs show moderate competence on simple spatial tasks, then rapidly deteriorate as compositional complexity grows.
Knowing the Theory Is Not the Same as Applying It
The most heated exchange in the KiCad thread was over whether LLMs can "learn physics." One side pointed out, correctly, that a frontier model can lecture on high-speed layout and EMI all day and can flag flaws in an uploaded layout image. The other side's response was equally correct: "spitting out established theory in text form is one thing but implementing said calculations/constraints in design is another."
An LLM's output is a sequence of tokens. A model can produce a layout that looks plausible, but plausibility is not the same as physics. Physics can only enter the loop as a tool the model calls, and then the model has to correctly interpret the result and correctly translate it into geometry, the two steps where the spatial-reasoning limitation becomes important.
To be fair to the tool-use argument: this is how LLMs already handle everything they are bad at natively. They run Python for arithmetic, call a search engine for facts, compile and test code rather than reasoning about whether it runs. An LLM could plausibly orchestrate a field solver, an impedance calculator, and a DRC engine the same way, and the KiCad forum's most constructive contributors argued for exactly that. There are two things to consider. First, at that point the physics is being done by the solvers, and the LLM's remaining job is search through a combinatorial space and translation of numeric results into geometry, which are the two capabilities the benchmarks above show it is weakest at. Second, the architecture that has proven this pattern works is not a general-purpose LLM driving a GUI. DeepMind's AlphaGeometry (Nature, 2024) solved 25 of 30 Olympiad geometry problems, against 10 for the prior state of the art, by pairing a neural model with a symbolic deduction engine that verifies every step; the neural model was trained from scratch on 100 million synthetic examples, not human proofs. AlphaGeometry works because each part does what it is good at: the neural model suggests promising moves, a deterministic engine checks whether each move is actually valid, and the model learned from synthetic problems rather than by imitating human solutions. Quilter is built in a similar way and optimized specifically for PCB layout. Reinforcement learning proposes placements and routes, solvers and Physics Rule Checks verify them, and the training data is generated, not copied from human boards.
Routing Is a Sequencing Problem With No Easy Backtracking
Quilter engineer Fayaz Rahman describes the router this way: "Router is very sequential… we can't do some sort of backtracking." Early decisions reshape the available space for everything that follows. A power pour that improves current delivery can block later escape routes. A wide trace that satisfies current capacity can starve neighboring signals. "The order and the constraints is probably the most difficult thing."
Reinforcement learning works well for this class of problems: sequential decisions with delayed consequences, evaluated against a reward. An LLM generating a board file token by token has no equivalent mechanism for learning what a placement decision on move three did to routability on move three hundred.
What Do the AI PCB Benchmarks Actually Measure?
Hackaday cites an EEBench score of 69.3% (±10%) for GPT-6 Astra, roughly in line with Claude Opus 5. There are two things to note about that number.
First, EEBench does not test layout. Its methodology evaluates analog and digital circuit design through simulation across 13 tasks, and its authors state it "does not yet tell us whether a model can lay out, manufacture and bring up a complete product." The composite score is 65% technical performance and 35% cost efficiency against a reference BOM. A 69% EEBench score says something about schematic-level design and not much about routing.
Second, EEBench is built and funded by atopile, a company whose product is a code-based interface for creating PCBs in KiCad aimed at AI agents. They disclose this themselves, and the benchmark is a useful piece of work. It is still a vendor-published benchmark, and the direction of its findings, that models know more electronics than they can express through a GUI so give them a code interface, aligns with the product.
Quilter's proof points are also self-published, and readers should weigh them the same way. The difference is that they are layout results with physical validation attached. Project Speedrun, an 8-layer Linux-capable motherboard placed and routed by Quilter and fabricated with no respins, has downloadable design files so anyone can inspect the result.
What Does a Layout System Need That an LLM in a GUI Doesn't Have?
Our recent blog argued that the autorouter failed because it lacked three specific capabilities, all of which have only recently become available. A frontier LLM operating KiCad is missing the first two, and has the third in a form that does not really solve the problem at hand.
1. A way to reason from physics. Making layout decisions evaluated against what the circuit will do, not against a fixed list of rules. Quilter uses reinforcement learning for this: define what a good board looks like, generate many candidates, score each against the physics, and let the system learn which decisions get there.
2. A way to check the physics during generation. A trained model is good at proposing decisions that look promising. It is not the right tool for calculating whether a specific differential pair, on a specific stackup, with a specific via transition, hits its impedance target inside tolerance. That’s a job for a classic solver. Quilter runs Physics Rule Checks during candidate generation: ground-plane coverage under high-speed traces, coupling between differential pairs, return-path continuity across layer changes, impedance held within tolerance for the stackup. Where the answer can be computed from the stackup, differential-pair spacing for instance, Quilter uses the solver-backed result directly rather than asking a network to learn it. Quilter is not just a trained model: RL where search is hard, computational geometry where geometry can shrink the search space, classical solvers where physics needs calculating, exact algorithms where exact methods win.
3. Compute at scale, aimed at the search. Every autorouter from Specctra onward was built to run on one workstation, which is most of why they never got past a first attempt or two. The only way to know whether a placement works is to route it, so every promising placement has to be routed just to be considered, and many candidates have to run through placement, routing, and physics checks in parallel. A frontier LLM has no shortage of compute, but an LLM operating KiCad spends it generating tokens for one board in one session, on an ECAD instance running locally. Running a thousand sessions in parallel would not change that without a physics evaluator to rank the thousand results. Quilter's compute goes into the candidates themselves: placement, routing, and Physics Rule Checks across many boards at once, on scalable cloud infrastructure or inside the customer's own AWS, Azure, or GCP for ITAR-controlled work.
Where Do LLMs Belong in the Hardware Workflow?
None of this is an argument against LLMs in electronics. The forum and Hackaday threads are full of engineers getting real value from them: schematic drafting from datasheets, component selection and availability checks, spinning up SPICE simulations for simple analog stages, and reviewing an existing layout for obvious flaws. One Hackaday commenter reported vibe-coding three modest boards that came back working first time. EEBench's own thesis, that models know more electronics than they can show through conventional design tools, is credible for the requirements-and-schematic stage it measures.
Layout is the stage where the problem stops being about knowledge and starts being about geometry under physical constraint. And at that point a general-purpose model becomes an orchestrator at best, and a purpose-built physics engine does the work.
With all the limitations stated above, the Astra demo is still a milestone in AI for PCB design. It brought more attention to one of the industry's long-standing problems, and through it a lot more people learned about PCB design in general.
See what physics-driven layout does on your own board. Talk to an engineer..
Frequently Asked Questions
Can GPT-6 Astra Design a PCB?
GPT-6 Astra can operate KiCad to place components and route traces from a schematic, as shown in OpenAI's launch video. OpenAI published no PCB-specific benchmark for it, and the demo shows net completion, not whether the resulting board meets impedance, return-path, or signal-integrity requirements. Engineers testing LLM-driven layout report it works on simple boards and struggles with high-speed signals, HDI, and BGAs.
Why Can't LLMs Do PCB Layout Well?
Layout is a coupled placement-and-routing problem where every decision has electrical consequences, and nothing in an LLM's token generation computes those consequences. LLMs also lack training data for professional layouts, which are proprietary, and measurably underperform on compositional spatial reasoning. They can call external solvers, as they call Python for arithmetic, but must then correctly interpret results and translate them into geometry, which is where they are weakest. Systems that pair a neural proposer with deterministic verification, like AlphaGeometry or Quilter, are built for this; a general-purpose LLM in a GUI is not.
What Is the Difference Between an LLM and Quilter for PCB Design?
An LLM is a general-purpose language model that can operate design software or generate board files. Quilter is a purpose-built layout system that uses reinforcement learning, classical solvers, and computational geometry to generate and rank complete placement-and-routing candidates against physics. Quilter's layout engine is not an LLM, and it does not learn by imitating human-designed boards.
Does Quilter Use an LLM?
Quilter's layout engine is not an LLM. It is built on reinforcement learning combined with classical solvers, computational geometry, and exact algorithms, and it is trained on synthetic problems scored against physics, not on human-designed boards or text.
Does EEBench Measure PCB Layout?
No. EEBench V1 evaluates analog and digital circuit design through simulation across 13 tasks. Its authors state it does not yet cover layout, manufacturing, or bring-up. It is built and funded by atopile, a design-tool vendor.










.webp)



















