makeIRLEngineering notes

AI & vibecoding

The Limits of AI in Hardware Design: What It Cannot Do Yet

AI hardware tools cannot yet guarantee requirements, pin truth, analogue behavior, EMI, thermal safety, manufacturability, sourcing, or physical validation.

Published Updated

The hardest failures begin before schematic capture

AI can generate a large amount of plausible hardware work quickly. Its main limitation is not drawing speed; it is knowing which unstated requirement must not be guessed.

“Make a USB-powered motor controller” leaves open the motor voltage and stall current, USB power negotiation, fault energy, braking behavior, isolation, connector system, thermal environment, enclosure, emissions target, and what happens when firmware crashes. No layout optimizer can recover requirements that were never supplied.

A capable assistant can ask questions and structure answers. It cannot independently decide which business, safety, regulatory, or system tradeoff the owner intended. Treat unresolved assumptions as blocking design inputs, not opportunities for completion.

It cannot guarantee source truth

Language models can summarize datasheets and search component catalogs, but they can also merge related package variants, use stale documents, or invent a missing value. This is especially dangerous for pin numbers, absolute maximums, startup states, and orderable suffixes.

Retrieval and tool calls improve grounding; they do not make every extraction correct. Primary manufacturer documents still need a revision, exact MPN, cited page, and independent check. The workflow in why LLMs hallucinate pin numbers shows why ERC cannot repair a symbol whose original pad mapping was wrong.

The same issue affects component models. A SPICE result is meaningful only if the model, parameters, operating point, and topology are appropriate. A confident explanation of a simulation does not validate its input deck.

It cannot infer all of the relevant physics from connectivity

A netlist says which pins connect. It does not fully describe geometry, field coupling, material variation, parasitics, heat flow, or mechanical stress. Even a detailed PCB database needs correct models and boundary conditions.

Current problem areas include:

  • switching-power stability and high-di/dt loop behavior outside a reference layout;
  • RF matching, antenna detuning, shielding, and enclosure interaction;
  • high-speed return paths, connector transitions, crosstalk, and power-distribution impedance;
  • precision analogue leakage, thermocouple effects, noise, guarding, and component drift;
  • thermal performance with real airflow, copper spreading, interfaces, and adjacent heat sources;
  • creepage, clearance, insulation coordination, pollution degree, and fault energy;
  • vibration, flex, connector loads, board strain, and assembly tolerances;
  • EMC emissions and immunity in the final cable-and-enclosure system.

Specialized solvers can analyze portions of these problems, and AI can drive or interpret those tools. The limitation is the unattended chain: selecting the right model, creating a valid setup, knowing what was omitted, and proving the result covers worst case. A pretty heat map can be based on the wrong power loss.

The five datasheet sections that matter for layout are a minimum input, not a complete multiphysics model.

It cannot create safety or compliance by assertion

Safety requirements depend on product context and jurisdiction. Medical, automotive, machinery, battery, radio, aerospace, and mains-powered products involve standards, risk analysis, documentation, qualification, and sometimes independent certification. Adding “make it compliant” to a prompt does not define the applicable clauses or produce evidence.

AI can help build a traceability matrix, identify candidate standards, draft test plans, or check documents for missing fields. A qualified person still determines applicability, designs the mitigations, approves deviations, and submits representative hardware for required tests.

For hazardous energy, add independent protective mechanisms and analyze single faults. Do not rely on generated firmware as the only safety boundary. The consequences of an error should determine the rigor of review.

It cannot promise live availability or manufacturing capacity

Supply data changes between design and order. A model’s remembered price, lifecycle, or inventory is not a live quote. Even an API result can refer to the wrong region, packing, or assembly stock pool.

Manufacturing capabilities also vary with stackup, material, quantity, and process option. A 0.15 mm drill listed somewhere on a capability page may be unavailable or expensive for the board configuration being quoted. The fabricator’s review and order-specific confirmation remain authoritative.

AI can automate exact-MPN stock queries and compare rules, but purchasing still needs traceability, allocations, attrition, shipping, and substitution control. A released BOM must be checked at release time.

It cannot validate a board without physical evidence

ERC checks electrical-type rules. DRC checks encoded geometry and connectivity. Simulation checks a model. None proves the delivered product works in its real environment.

Physical validation includes:

  • controlled first power-up and rail/current measurements;
  • interface and firmware tests over voltage and temperature;
  • thermal measurements at worst-case load;
  • signal-integrity or RF measurements where required;
  • fault injection and protection tests;
  • EMC pre-compliance and formal testing;
  • mechanical fit, insertion cycles, vibration, and environmental tests;
  • production test coverage and yield monitoring.

An agent can generate test firmware and procedures. Instruments and representative hardware produce the evidence. Unexpected results require engineering judgment about whether the model, board, fixture, firmware, or requirement is wrong.

It cannot review itself independently

Asking the same model that generated a design to “double-check everything” is not independent verification. The model retains the same assumptions and may rationalize its earlier output. A second prompt or model can find issues, but shared training data and source material create correlated failure modes.

Use different mechanisms:

generation:      AI assistant or automation engine
rule checking:   KiCad ERC/DRC and project-specific scripts
source review:   primary datasheets plus a human reviewer
physical review: SI/PI/thermal tools where justified
release review:  manufacturing and assembly output inspection
validation:      instruments, fixtures, and acceptance tests

Independence matters more than the number of chatbot passes.

Where AI belongs today

Delegate reversible, inspectable work: requirements formatting, candidate discovery, repetitive schematic edits, first-pass layout, rule generation, BOM cleanup, documentation, test scaffolding, and log analysis. Increase autonomy only when inputs are constrained, outputs are machine-checkable, and rollback is cheap.

Require a domain reviewer for architecture, exact part choice, custom libraries, power, RF, safety, thermal design, mechanical interfaces, and release. Keep a clear boundary where generated work becomes approved work.

The question in can AI design a PCB? has a conditional yes. The conditions are evidence, constraints, independent checks, and testing. Ignore them and the familiar PCB mistakes that cost a respin arrive faster, not less often.