Built your hardware with AI? What to check next

AI tools have changed how hardware projects start. A founder can describe a product and get back a block diagram, a parts list, a schematic, and firmware that compiles, in an afternoon. I see more and more designs that began this way, at every stage: concepts, first prototypes, and products headed to manufacturing.

That is a real step forward. It also moves the hard part rather than removing it. Getting from a design that looks right to a product that works every time, passes certification, and can be built in volume still takes engineering judgment, measurement, and experience. If your project has reached that point, the good news is that you often do not need to start over. Much of what you have is usually useful. The job is to find out which parts are solid, which are risky, and what is missing.

What AI tools do well

Used well, AI tools are a fast way to:

Explore architectures and compare approaches before committing to one.
Summarize long datasheets and application notes, and find the section that matters.
Draft firmware: drivers, state machines, test scripts, and the glue between them.
Get a first schematic sketch, so there is something concrete to review.
Learn the vocabulary of an unfamiliar field quickly.

None of that is a shortcut to avoid. It gets a project to the interesting questions sooner.

Where AI-assisted designs most often need work

The problems below are not unique to AI. Engineers make every one of them. The difference is that an AI tool can sound equally confident whether or not it is right, and a design can look complete long before it is.

Parts

Part numbers that do not exist, or that exist but are a different part.
Parts that are obsolete, not recommended for new designs, or out of stock everywhere.
Pinouts and footprints taken from a similar part, or from a different package of the same part.
Values that are typical rather than worst case: a regulator that can supply the average current but not the peak, or a ceramic capacitor that is the right value on the label but loses much of it at the working voltage.

Every part should be checked against the datasheet for the exact part number you will buy. Before your first board spin covers part availability in more detail.

The details datasheets bury

Much of what makes a circuit work lives in the fine print: errata, layout guidelines, decoupling recommendations, startup sequencing, and the reference design the vendor actually tested. These are easy for any reader to skip, and AI tools often summarize past them. Boot and strapping pin states are one example. Crystal load capacitors are another; the crystal load capacitor calculator shows how they are sized.

Power and heat

Power is where many prototypes fail quietly. Check the worst-case current of every rail, the heat each regulator dissipates, what happens when a battery is nearly flat, and what happens when power is connected, removed, or reversed. A chat answer or a simulation is not a measurement; a bench supply, a meter, and a scope settle these questions quickly. If the product has a lithium cell or connects to mains power, charging, protection, and safety approval deserve their own check. For battery products, Battery-powered design covers budgeting and measuring.

Layout

A schematic can be correct and the board still fail. Ground planes, return paths, the stackup, placement of fast signals, and antenna keep-out areas decide whether the product is quiet, reliable, and certifiable. AI tools can describe these rules, but the layout itself still has to be checked against them.

Protection

Real products get plugged in wrong, touched by charged hands, and connected to cables that pick up noise. Look for ESD protection on exposed connectors and buttons, reverse-polarity and overvoltage protection on power inputs, and filtering on cables that leave the enclosure.

Firmware that works on the bench

AI-drafted firmware often handles the happy path well and the rest poorly. Check what happens on a brownout, a stuck bus, a full buffer, a lost connection, or a failed update. Look for a watchdog, a way to recover from a bad firmware load, and a plan for updates in the field. For connected products, security is now a regulatory requirement in the EU and the UK, and in other markets; see Designing connected products for EU and UK cybersecurity rules.

Compliance

An AI tool can list the approvals a product needs, but the list depends on details it may not have: every market you sell in, the radios, the power source, and who uses the product. Design choices made early decide how hard testing will be. Plan for compliance from day one and the compliance planner are good starting points.

Manufacturing and test

A board that works on your desk is not yet a product. Production needs a complete, consistent set of files, parts that can be bought in volume, a design your contract manufacturer can build, and a way to test every unit as it comes off the line. From prototype to production and What a complete manufacturing package includes walk through it.

Signs you have hit the wall

Projects that started with AI tools tend to stall in familiar ways:

The prototype mostly works, but fails now and then, and no one can say why.
One board works and the next one does not.
It works on the bench and fails in the enclosure, in the cold, or on battery.
A radio’s range is far shorter than expected. (The radio range estimator gives a quick sanity check.)
An early emissions scan or a test lab report comes back with failures.
Your contract manufacturer is asking questions you cannot answer.
Each fix seems to break something else.
No one can say which parts of the design were checked and which were only generated.

None of these mean the project is a failure. They mean it has reached the point where experience is worth more than another round of prompts.

Sort what’s solid from what’s missing

A good first step is a review against what the product has to do: what is sound and can stay, what is risky and needs to be checked or tested, and what is missing. That gives you a short, ranked list of work, and it keeps the parts of the design that are already right, along with the time spent on them. Occasionally a review shows that a rewrite really is the better path, and it is better to know that early. What I look for in a hardware design review describes how I approach it, and the schematic and layout review checklist is a place to start on your own.

What to send

You do not need to know what kind of help you need, or to tidy anything up first. To start, a short description is enough:

What the product is supposed to do.
What works, what does not, and how often.
Where you plan to sell it, and roughly how many you expect to build.
Any deadline you are working toward.

Keep everything else you have, however messy: chat transcripts, design files, a parts list, firmware, datasheets, photos of the prototype, and notes on what goes wrong. All of it is useful once the work starts.

An NDA can come first. I start with a short call to understand the project. The call is free, and it ends with a plan: a written proposal with the scope and cost of the work, such as a design review, debugging, or taking the design to production. Reviewing your files and finding the problems is paid engineering work, and it begins once you accept the proposal.

If your project started with AI tools and has hit a wall, get in touch.