The schematic had zero ERC errors. The BOM was fully cross-referenced against the datasheets. Every net class was defined, every controlled-impedance requirement documented in a clean decision log. And when I sat down to actually read it, I could not.
Decoupling caps were scattered across the sheet, placed wherever the tool had dropped them. Hierarchical labels overlapped. A pull-up resistor was sized correctly according to every rule the ERC knew about, but wired in a topology that would have held the bus low at startup. The design was formally valid. It was also completely unreadable.
This is not a complaint about AI tools in hardware design. It is a description of a specific gap, one that every team using AI-augmented PCB workflows will run into if they have not already.
What AI does well at the schematic
The tools are genuinely useful. A well-prompted LLM can cross-reference a component rating against a datasheet citation in seconds. Multi-agent verification frameworks check net connectivity, flag missing decoupling on a power rail, audit BOMs for footprint mismatches, and run derating math against IPC tables. These tasks used to eat hours of senior engineering time. The tools do them faster, and for rule-based checks, they do them reliably.
ERC tools have always handled formal connectivity checking. What the current generation adds is cross-document reasoning: “this net connects to a pin rated at 3.3 V, the component upstream is on a 5 V rail, and the datasheet specifies a maximum 0.3 V overvoltage tolerance.” That kind of reasoning across multiple sources is new, and it is genuinely useful.
Moravec’s paradox at the schematic
In 1988, Hans Moravec observed something that seemed backwards: the things humans find effortless, sensorimotor skills, spatial reasoning, common-sense perception, were the hardest problems in AI. The things humans find difficult, formal logic, rule application, calculation, were relatively tractable for computers. Easy problems were hard; hard problems were easy.
Hardware design has its own version. Formal connectivity verification: tractable for AI. Pattern recognition built on years of bench failures: not yet.
When I read a schematic, I notice things I cannot always articulate immediately. A decoupling cap that is technically present but placed three hierarchical levels away from the pin it serves. A pull-down topology that looks symmetric on paper but that I have seen behave badly at temperature extremes. A crystal load capacitor value that is within spec but that I have seen fail in high-humidity environments. None of these are ERC violations. They show up in bring-up, in the field, or in a regulatory audit.
The AI workflow confirms the net is connected. It does not catch that the connection is right but the context is wrong.
The engineering risk
I keep seeing the same failure modes in AI-generated schematics. A leftover functional cap from an earlier design state, still in the netlist, no longer serving the pin it was added for, but adding load and noise. A pull-up resistor with the correct value for one supply voltage, in a design that has since been revised to a different supply, where no rule flags the mismatch because both values are valid in isolation. A decoupling strategy that covers the stated rails but misses a secondary rail added late in the design process.
None of these are hallucinations in the LLM sense. The components are real, the values are plausible, the ERC is clean. The problem is that the design has not been read by someone carrying a mental model of the whole thing.
A senior engineer reading a schematic for the first time will catch these in minutes, not because they are running rules, but because something looks off. The decoupling cap is far from the pin. The topology is unfamiliar. The value is in range but suspicious given the rest of the circuit. Pattern recognition. And the current generation of AI tools does not have it.
The regulatory risk for safety-critical work
For teams working under Class II FDA, IIa CE MDR, IEC 60601, or ISO 13485, there is a second dimension to this gap. The design history file needs to answer a question that comes up in every audit: was this design reviewed by a qualified engineer?
An AI-generated schematic that was never humanly read leaves that question open. Not because it is wrong to use AI tools, but because the review on record needs to be a real review. If the schematic cannot be read by a human, the review cannot happen. And if it does not happen before clinical phase, the remediation cost is far higher than a human review during design would have been.
I have seen this play out in late-stage remediation. The formal records are complete. The ERC report is attached. The audit asks why a qualified engineer’s review sign-off is not in the file. At that point, the options are expensive.
The workflow that closes the gap
AI for the formal layer, a senior for the human layer, a junior under supervision for the work between them. That is the model that works.
Concretely: let the tools run ERC, check datasheets, audit the BOM, cross-verify net classes. Then have a senior engineer read the schematic, not to re-run the rules, but to catch what the rules cannot catch. For the iteration work between formal checks, a junior under structured supervision keeps the senior’s time focused on what only a senior can do.
In practice, many teams using AI-augmented workflows do not have a senior hardware engineer on staff. They have the tools, the tools produce clean formal output, and bring-up is the first time someone with real pattern recognition looks at the design. That is late.
The Moravec gap is not going away this year. The tools will close it eventually. Teams that build workflows assuming it is already closed will pay for it in bring-up failures and remediation cycles. Teams that close it themselves, with a human pass at the right point in the process, get the speed of AI and the discipline of senior engineering.