Designing hardware with AI: where it is strong, and where it needs an engineer

AI tools are now part of how hardware gets designed. Teams use them to explore architectures, read datasheets, draft schematics and firmware, and review their own work. They are good at much of it, and getting better quickly.

I use them every day, and I have built my own AI tooling for design review and design work. Building it meant measuring, over and over, where the tools are right and where they are not, on real parts and real boards. The short version: they are a real amplifier, and they need someone who knows the domain to steer them.

That is the gap. A software team using AI usually has the background to judge what comes back. Many teams building hardware with AI don’t, and they know it. They get a long way fast, then reach the point where the design has to survive physics, certification, a factory, and years in the field. This article is for them.

Why hardware is different

In software, a wrong answer from an AI tool usually shows up quickly: a test fails, you fix it, and it costs minutes. Hardware is less forgiving.

• Feedback is slow. A board takes days or weeks to arrive. A mistake found at bring-up costs a spin; one found in certification or production costs months.
• Not everything can be tested on a desk. Radio range, heat, a cold start, a surge on a cable, or a part that ages only show up in the right conditions.
• The real constraints are not in the files. The enclosure, the factory, the certification lab, the supply of a part three years from now: none of them is visible to an AI tool.

So in hardware, a confident wrong answer costs a lot, and the bill arrives late.

Where AI is strong

In my own trials, the tools earned their place in several jobs:

• Reading datasheets. Asked for a pin table, a recommended circuit, or an operating limit, a good model answers almost every time, in seconds, and is usually right.
• Understanding an existing design. Given a schematic, a model can explain what each block does, and a careful one says “unknown” instead of guessing.
• First-pass review. Model reviewers found real problems: swapped bus pins, a wrong divider, a protection part that could not protect what it sat next to.
• Sorting findings. Automated checks raise many false alarms. Models are good at separating the real ones from the noise, with reasons, so an engineer spends time on what matters.
• Answering questions about a design. “Why is this resistor here?” “What happens if this rail starts late?” With the design and its datasheets in hand, the answers cited their sources and said what the design did not show.
• Drafting. Firmware scaffolding, test scripts, documentation, and the first version of almost anything written.

Used this way, AI saves a lot of engineering time and gets a project to the hard questions sooner.

Three ways it fails

Confidently incorrect. The answer is specific, well written, and wrong. In my trials a model decoded a capacitor’s part number from memory and gave the wrong voltage rating. Another took a pin’s function from a sibling variant of the same part. A reviewer insisted a part needed a particular crystal frequency when it also accepts a cheaper one, so the simple fix was never offered. Each answer looked right, and each was caught only because something independent checked it against the datasheet or the design.

Two traps sit next to this one. Asked to review, models tend to agree: in one test, two reviewers approved every one of twenty draft rules, and pushed back only when told to assume some were flawed. And sometimes the source is the problem: a datasheet with a transposed equation, or an old revision of the right part. A tool that trusts its source passes the error straight through.

Out of date or out of reach. Models learn from public text. Much of what matters in hardware is not public: paid standards, vendor documents behind logins, simulation models, and how a particular factory actually builds boards. Public text also keeps old rules of thumb alive after the reasons have changed, and parts go out of date: one design picked a module its maker had already marked “not for new designs”, while a distributor still listed it as active. Compliance is especially exposed: in one design a bare radio chip with a hand-tuned antenna was called “pre-certified”, which would have meant a surprise at the test lab.

Confidently incomplete. This is the dangerous one, because nothing looks wrong. The output looks finished, and nothing says what is missing.

• A drafted power supply came back without its input capacitor and compensation network.
• A board passed an automated check because its high-voltage net had no voltage declared, so the voltage checks quietly skipped it, while a protection part on that net clamped well above what the regulator behind it could survive.
• Requirements agreed at the start, such as a current limit and a pin that must not float during boot, fell out of a later draft.
• On real designs with known faults, checks that never read a datasheet value missed nearly all of them.

A review that says nothing about a problem looks exactly like one that checked and found none.

What works

None of this is a reason to avoid the tools. It is a reason to use them with structure. These practices made the difference in my own work:

• Let the model read, propose, and explain. Let checks and an engineer decide. Pass or fail should come from something you can test, such as the design tool’s rule checks or a script, not from the model’s opinion of its own work.
• A check that checked nothing is not a pass. Skips, empty reads, and “no issues found” with no evidence should fail loudly.
• Every claim cites its source. A value without a quote from the right datasheet, page, and revision is a guess.
• A second model is a weak second opinion. Two models often make the same mistake, especially when the question leads them there. An independent check, or an experienced engineer, is stronger.
• Test the process on faults you already know. Seed real mistakes into a design, or replay the fixes in a past board’s revision history, and see what gets caught. It is the only honest measure of a review.
• Keep the requirements in human hands. A short list of what the product must do, owned by a person and checked at every step.
• Know what the tools cannot see yet: board geometry, radio behavior, compliance, manufacturing, and the product’s life after launch. Those still need someone who has done them.

I build these practices into Basanix, a Westlake Systems lab where I develop an AI reviewer and design companion for PCBs.

Your design data

Using AI tools means sending your design somewhere. Know where it goes and on what terms: whether it is kept, whether it can train models, and whether that fits your NDAs and your customers’ expectations. For sensitive work, use only tools whose terms you have read and accepted, or do the work without AI. It is your decision.

In my client work, your files go only to tools you approve, under terms that keep them private and out of model training. If you prefer, the work can be done inside your own AI tools, such as your company’s enterprise account, under your rules. If you would rather AI tools are not used on your project, they are not used at all.

Where an experienced engineer fits

The tools are fast. What they lack is the judgment of someone who has taken products through bring-up, certification, production, and years in the field: knowing which questions to ask, what a datasheet leaves out, and when a confident answer deserves a second look.

That is the role I fill for teams designing with AI: the hardware expert in the loop.

• Set up the workflow: which tools to use for what, where the review gates go, and what gets checked by script, by model, and by an engineer.
• Review what the tools produce: schematics, layouts, firmware, and part choices, against datasheets and real limits.
• Cover what they miss: layout and RF, compliance, manufacturing and test, and the product’s life after launch.
• Make the calls: what to trust, what to verify, and what needs a decision.

The same experience helps companies building AI design tools, which need someone who knows what a right answer looks like.

The tools amplify the work. The engineering decisions stay with an engineer.

If your team designs with AI and wants that experience on board, get in touch. If your design started with AI and you want to know what to check next, start with Built your hardware with AI? What to check next.