Last month I merged a set of pull requests into Mermaider, the dotnet Mermaid renderer that WinPrint uses to enable its kick-ass ability to print Markdown (and convert Markdown to PDF). Quality, well-engineered, features, reviewed and shipped. At no point did I open an IDE. Not once. Same story for recent work on WinPrint itself and MCEC (Model Context Environment Controller), two of my own projects with actual users. I described what I wanted, I asked for proof-of-concepts, I argued with the machine, agents built robust test frameworks and tests with my guidance, we looped, I did the user testing, and my agents shipped releases. The IDE sat there like a fax machine.
I pretend to write code for fun. Lately I don’t even pretend.
If that shift has happened to software (and it has, whether or not your favorite programmer admits it yet), it is now happening with hardware too. I’ve started calling this Prompt to Metal, and I want the term to catch on, so I’m going to define it:
Prompt to Metal (n): Building hardware products from expressed human intent. The high-judgement engineer and/or product person describes and judges; the machines draw the schematics, route the boards, write the firmware and companion software, run the tests, manage customer feedback, and improve the product.
Not “AI-assisted PCB layout.” Not “copilot for KiCad.” Prompt to Metal is the whole arc, from “I want a battery powered thing that senses X and reports Y” to a powered-on board blinking in customer’s hands, with humans in the loop the entire way but never once dragging a trace or writing a line of code.
The startups are doomed (and that’s fine)
There is now a wave of funded companies chasing pieces of this: H2LooP ($2M Seed) is supposedly a “AI-native platform for system/embedded software engineering”, siliXon raised a seed round to generate PCB designs from text prompts, Embedder (YC25, $500k) generates register-correct firmware from MCU datasheets, Axiometa Studio turns a prompt into running ESP32 firmware in the browser, and Flux and Quilter are attacking schematic capture and layout.
I assert they have no moat.
Their pitch is, in essence, “we put a prompt box in front of an EDA tool before the frontier labs got around to it.” I wrote back in 2013 about why nobody can copy Apple: a durable moat comes from something structural that competitors cannot replicate, not from being first to an obvious interface. A prompt box is not structural. The frontier models improve monthly, the open EDA stack (KiCad, Yosys, netlistsvg, tscircuit) is right there, and projects like KiChad are already teaching general-purpose agents to drive KiCad directly through clean APIs. When the general agent can do what your vertical product does, your vertical product is a feature.
Software engineers are, right now, stopping opening IDEs. The IDE is becoming a visualization and verification surface, not an authoring surface. Hardware engineers will stop opening KiCad, Altium, and the rest of the EDA “IDEs” for exactly the same reason. They will open them to look, not to draw.
Ask yourself: when did you last open an IDE to type code, versus to read what the machine wrote? I’ll wait.
My opinions, weakly held
I’ve been noodling on this space seriously (more on why in a moment), and I’ve arrived at five opinions. I hold them weakly, which for me is saying something.
- Human-in-the-loop is essential, but which part of the loop is not yet clear. Everyone agrees the human belongs in the loop. Nobody has convincingly shown where. Writing PRFAQs? Reviewing schematics? Approving BoMs? Setting constraints? Judging test results? I suspect the answer is “at the intent and judgment layers, and almost nowhere else.”
- The netlist is key, but it is not canonical. In software, Python and C# and Rust are not the canon; the specs, the docs, and the intent are. Source code is an intermediate representation that happens to be human-legible for historical reasons. The netlist is headed for the same fate. The interesting question is: will the netlist’s representation be something a human can read, or something only a machine can read? I honestly don’t know, and I think whoever answers that well wins a big prize.
- Visualization is what makes human-in-the-loop possible without a priesthood. If reviewing a design requires the domain expertise to read a schematic cold, then only priests get to be in the loop. We need many visual perspectives on the same metal: form factor, connectors, components, layout, schematics, system architecture, the software components riding on top, and the whole product lifecycle. Tools like netlistsvg are a primitive glimpse of this. The design is the model; every diagram should be a projection of it.
- Test is the hard part. Generating a plausible board is getting easy. Knowing it works is not. We need far better simulation, and we need harnesses where a host (the computer clipped onto the device) can exercise the metal automatically, at the bench and in the field. This is where I expect the real engineering to be for the next year or so. (I would have written “decade” in 2020. The rate of change is accelerating.)
- “Hardware is Hard” is mostly not about the hardware. When people say it, they mean design and manufacturing, and yes, those are hard. But having built and sold consumer hardware at scale, I can tell you the lifecycle is where the bodies are buried: marketing it, selling it, actually making a profit on it, making first-power-on delightful, shipping updates, servicing the thing, and retiring it gracefully years later. Prompt to Metal that stops at the Gerber files or a GitHub repo is a demo. AI will help across this entire arc, and almost nobody is working on that part.
About that project
I have skin in this game. I’ve been building something focused on two things the prompt-box crowd ignores: getting from intent to real running metal fast, and keeping that metal supportable in the field for years afterward. Along the way I’ve had to invent lexicon. The physical device is the metal. The computer attached to it for development and test is the host. One class of device ended up with the acronym GCU, which was an accident, but if you’ve read Iain M. Banks you understand why I refuse to rename it. Somewhere, the Grey Area is judging my solder joints.
The conversation I want to have
Prompt to Metal is coming. The only questions worth arguing about are the ones above: where the human sits, what the canonical artifact is, how we visualize, how we test, and how the metal earns its keep across an entire product lifecycle.
So argue with me. Which of my five weakly held opinions is most wrong? If you’re building in this space (or funding it), what do you believe your moat actually is? Leave a comment or find me on Twitter at @tigkindel. I read everything, and I change my mind in public.