In hardware, a wrong answer isn’t a typo. It’s scrap.
The way to use AI in hardtech is not complicated, but it is specific: let it do the heavy lifting, and keep a human in the loop on every decision that touches the physical world.
This isn’t hedging. It’s the only model that works when the cost of a wrong answer is a scrapped panel, a failed validation run, a recall, or a field failure in something that’s supposed to be safe. In software, a bad AI suggestion gets caught in review or rolled back in an afternoon. In hardware, it gets caught at first article — if you’re lucky — or in the field, if you’re not. The blast radius is physical, and the feedback loop is measured in weeks and tooling dollars.
So the division of labor is clear. AI handles volume, breadth, and tedium: generating options, checking thousands of rules, surfacing the failure that matches three past ones, drafting the test plan. The human handles judgment: what’s actually required, what’s safe, which tradeoff to make, what to trust.
Which means the real work — the part that determines whether any of this pays off — is requirements. AI is only as good as the spec you hand it. Vague requirements produce confident, plausible, wrong output, faster than ever before. Tight requirements turn AI into leverage. The teams that win with these tools aren’t the ones with the best prompts. They’re the ones who already knew exactly what they were building and could say so precisely.
Heavy lifting, automated. Judgment, human. Requirements, sacred. That’s the whole method.