Insights · Field Notes

You Can't Collapse Taste

AI has collapsed the cost of drafting, testing and being wrong in hardware development. It hasn't collapsed the thing that decides whether a product is any good: knowing what to build, and recognizing a confident answer that's quietly wrong.

I closed The Four Files with a line I keep coming back to: you can collapse the cost of being wrong, but you can't collapse taste. It deserves more than one sentence, because it's the most important thing I've learned about building hardware with AI.

What collapsed

The cost of most of what used to fill an engineer's week has dropped dramatically. A first-pass schematic review, a firmware module, a test plan, a datasheet draft, a BOM scrub against stock: work that took days now takes an afternoon, and much of it gets drafted while I'm doing something else.

That changes the economics of being wrong. When a draft costs an afternoon instead of a week, you can afford to try three approaches and throw two away. Iteration is cheap. Being wrong is cheap. That's genuinely new, and it's why a small team can now cover ground that used to take a department.

What didn't

Here's what AI didn't make cheaper: deciding what to build, which tradeoffs to accept, what to leave out, and noticing when a fluent, confident answer is quietly wrong. That's taste. In hardware it isn't aesthetic. It's judgment, and it's earned the slow way.

Three recent calls from our own work show what I mean.

Asking whether a part has a future. A small battery-powered device with a wireless charging base has an obvious design: use a dedicated wireless-charging transmitter chip. A parts search, human or AI, naturally lands on the best-documented option. The question that has to be asked deliberately is whether that chip is still meant for new designs. Several dedicated transmitter controllers from major vendors are now marked not recommended for new designs. The right call was to stop shopping and build the transmitter ourselves from a small microcontroller and a few power parts, so the product isn't designed around a part with no future.

Asking how old the number is. On a recent sourcing pass for a gateway, the lesson we wrote down was blunt: quote vintage matters more than quote number. A spreadsheet of supplier quotes invites you to sort by price. Anyone who has watched component pricing move knows to ask when each number was quoted before trusting what it says.

Designing for the standard, not the sample. A gateway built around a plug-in compute module has to work with modules from more than one vendor. On the module in hand, a certain pin is unconnected, so it's tempting to treat it as free. But "unconnected on this module" is a fact about one module, not about the socket. The next vendor's module may use that pin. Taste is designing to what the standard guarantees, not to what today's sample happens to do.

None of those are hard calculations. Any of them could be worked out in seconds once someone thought to ask. The skill is noticing that the question needs asking.

The hardest decisions are subtractions

There's a fourth kind of taste that shows up on every program: knowing what to leave out. Drafts, human or machine, tend toward completeness. Ask for a design and you get every feature, every interface, every option the request implied. Real products get good by removal: the connector you don't add, the mode you don't support, the sensor you decide the customer doesn't need. Every addition is another interface to get right, which is exactly where products fail (the seam problem again). Saying no is a judgment call, and it's one of the most valuable ones an engineer makes.

Where taste comes from

Taste is accumulated scar tissue. It comes from respins, from field failures, from shipping things and watching what happens to them. We write the expensive lessons down, and our agents read that log before they start work, which helps. But reading a lesson is not the same as having paid for it. The engineer who has lived through a failure recognizes its early shape before anything breaks.

That's the part of the job AI moved to the center rather than replaced. When drafting is cheap, the value of an engineering partner isn't the hours of drafting anymore. It's the judgment about what to draft, what to keep and what to throw away. That's how we work: AI does more of the typing every month, and the decisions stay with people who have been shipping hardware for more than twenty years.

AI made being wrong cheap. It didn't make being right automatic.

One partner, concept to shipped

You bring the idea. We build and ship the full product.

Twenty-two years, thirty-five-plus products, one accountable team, electronics, firmware, mechanical, and manufacturing under one roof.

Get Started