Why AI hasn't worked for electronics engineering (yet)

Ask a software engineer what changed since 2023 and they'll show you: agents writing production code, review bots on every pull request, whole test suites generated overnight. Ask an electronics engineer the same question and you'll mostly get a shrug. Maybe they use a chatbot to summarize a datasheet. Maybe someone on the team tried an "AI schematic generator" once, got a circuit that shorted an output to ground, and never opened it again.

This isn't because electronics engineers are slower to adopt tools. It's because almost everything shipped under the banner of "AI for electronics" has quietly failed the first contact with a real design. It's worth being precise about why — because the reasons have very little to do with how smart the models are, and everything to do with what's around them.

The model speaks text. Your design doesn't.

Large language models are text machines. Software engineering happens to be made of text, which is the single biggest reason coding assistants worked on day one: the model reads the same artifact the engineer edits and the compiler consumes. There is no translation layer to get wrong.

Electronics is the opposite. The actual design — the thing that goes to fab — lives in formats that were never meant to be read by anything except one vendor's application. Altium projects, Cadence Allegro databases, Siemens Xpedition files: binary, proprietary, and mutually incompatible. Even KiCad, the friendliest case with its s-expression text files, encodes geometry, net topology, and layer stacks in ways no general model was meaningfully trained on.

So the first generation of tools cheated. They worked on screenshots of schematics, or on exported netlists, or in some intermediate representation that had to be converted back into the real format afterward. Every one of those translations discards information — design rules, constraints, courtyard geometry, the reason a trace was routed the ugly way on purpose — and information you discard is information the AI can't respect. The output looked plausible in the demo and fell apart the moment it had to round-trip into an actual project.

If the AI can't open the file your fab house needs, it isn't doing electronics engineering. It's doing electronics-flavored writing.

There's no compile button for a board

The second reason is deeper, and it's the one that separates the winners from the demos: software has a free, instant, merciless verification loop. Generated code compiles or it doesn't. Tests pass or they don't. An agent can propose garbage forty times, and the loop filters it down to the one attempt that works — cheaply, in seconds, with nobody watching.

Electronics has verification too, but the strong version of it is called fabrication, it takes two to six weeks, and it bills you whether you were right or not. Everything before that — ERC, DRC, simulation, design review — is a partial check that catches some classes of error and silently waves the rest through. A schematic can pass every rule check and still be wrong, because the error lives in a datasheet footnote about regulator stability with ceramic output caps, or in the difference between two package variants with the same symbol.

Here's why that kills naive AI tools: a language model's raw output is a probability distribution, not a fact. In software, the loop converts probability into certainty before anyone gets hurt. Point the same model at a schematic with no loop around it, and its errors flow straight through to the most expensive stage. The industry's early answer — "a human will check the AI's work" — makes the economics worse, not better, because reviewing someone else's schematic thoroughly takes about as long as drawing it, and reviewing an AI's schematic means checking everything, since you can't ask it what it was thinking.

The part number problem

Nothing shattered engineers' trust faster than hallucinated components. Every EE who experimented with chat models in 2023–2024 has a version of this story: the model recommends the "TPS54331DDA in SOT-23-6" — a real part, in a package it never shipped in — or cites a maximum input voltage from an adjacent row of the datasheet table, or invents a part number that has never existed but looks exactly like ones that do.

This isn't a moral failing of the model; it's what happens when you ask a compression of the 2024 internet to stand in for a live parts database. Component data is enormous, precise, and constantly changing. Stock moves hourly. Parts go end-of-life with a PCN notice, not a press release. A model's memory of DigiKey is out of date the moment training ends, and "roughly right" is worthless in a domain where the difference between the -Q1 and non-Q1 variant is whether your product passes automotive qualification.

The cost of being wrong is not symmetric

Underneath all of this is a brutal asymmetry that software people consistently underestimate. When an AI coding agent is wrong, you get a red CI run and you revert the commit. Cost: minutes, and mild annoyance. When an AI hardware change is wrong and nobody catches it, you get a respin: new fab run, new assembly run, four to eight weeks of calendar time, and — if you're unlucky enough to find it in the field — a recall.

This is why "80% accurate" — a triumph in most AI applications — is a non-starter in this one. An assistant that's right four times out of five doesn't save an electronics engineer time; it converts them into a full-time auditor with worse job satisfaction. The bar isn't "usually right." The bar is "wrong only in ways the checks catch before merge."

The training data was never there

One more structural fact: models learned software from billions of lines of public open-source code, complete with commit histories, bug reports, and fixes — an annotated record of how engineers actually work. Electronics has no equivalent. Real board designs are trade secrets. The open-hardware corpus is comparatively tiny and skews toward hobby-scale projects. Datasheets are public but locked in PDFs that mangle tables under extraction, and application notes encode their most important knowledge in figures, not sentences.

The result is a model that has read about electronics extensively but has watched very little electronics being done. It knows what a buck converter is. It has rarely seen the twelve-commit history of one being debugged. That gap — between knowledge and practice — is exactly the gap where invented pin assignments live.

What actually works: close the loop

Here's the good news buried in all of this: every one of those failures is an infrastructure failure, not an intelligence failure. And infrastructure can be built. What the successful pattern looks like — the one that finally transfers software's gains to hardware — is a harness around the model rather than a chat window in front of it:

• Native file access. Agents read and write the actual KiCad, Altium, Cadence, or Siemens files — no screenshots, no lossy exports, no "trust me" intermediate formats.
• Deterministic verification of everything. Every AI-proposed change runs the same gauntlet: ERC, DRC, netlist comparison, footprint-vs-datasheet cross-checks. These run as code, not as model opinions — the model doesn't get to grade its own homework.
• Live data, not memory. Part numbers, stock, pricing, and lifecycle status come from distributor and PLM APIs at the moment of the decision. The model chooses; the database supplies the facts.
• Diffs, not vibes. Everything lands as a version-controlled change a human reviews and merges — the same Git discipline that made software agents trustworthy, applied to hardware design files.

Inside that structure, the same model that embarrassed itself in a chat window becomes genuinely useful — because the harness converts its probabilistic output into checked, sourced, reviewable engineering work. The model was never the missing piece. The loop was. (We've written more on what a harness is and why you need one, and on the fragmented tool ecosystem that makes building one so hard.)

"Yet" is the operative word in this article's title. The gap between what AI did for software and what it's done for electronics isn't permanent — it's a to-do list. Most of the items on it have nothing to do with waiting for a smarter model.

Frequently asked questions

Written by

James Pentalow

VP of Revenue, Circuitly

James is a two-time founder and GTM lead at Circuitly. He's spent almost a decade working with customers in the electronics space and has been building agentic systems since 2022.