We’re excited to announce that Orchestra Bio has been acquired by OpenAI. To read more about the acquisition, read Jay Rughani and Jorge Conde’s post about it here. For more general information on what OpenAI is up to in the Health space, check out our podcast with them here.
It took me eight months to build my first FPV drone. I procured the parts in January, received them in February, remembered I bought them in June, assembled and lit the drone on fire in July, re-assembled and crashed it into my neighbor’s roof in August, and then, and only then, at the behest of my wife, downloaded a FPV flight simulator.
A super-intelligent AI surely could have done better.
While far from superhuman today, the frontier models can now generate CAD, design custom PCBs, source COTS parts, and describe how those parts are to be assembled. And they’re only getting better. Hardware design benchmarks like CAD Arena, EE Bench, and my own LuxoBench show steady improvements; and more generally, you’d have to be crazy to bet against the Bitter Lesson and say hardware design will forever stay beyond the frontier.
Superhuman hardware engineers are coming soon, perhaps very soon. But what will they look like? Will superhuman hardware engineers surpass all humans in one fell swoop, or only in specific domains/disciplines? And what will hardware engineering look like before, during, and after the crossover?
My answer to each of these questions starts with one simple observation: that the interface between the digital and physical world is lossy. This makes it hard to “write” changes from the digital world of bits into the physical world of atoms, and hard to “read” measurements of the physical world back into a computer. This lossiness will shape when and how future superhuman hardware engineers will emerge — and means that even once the models can consistently one-shot electromechanical designs, they will still have a lot more work to do.
Write access: from digital designs to assembled atoms
When OpenAI released GPT-6 Astra, the online world erupted with demonstrations of its 3D design prowess. Tom Krcha used Astra to model a steam train, Thomas Ricouard made a walk-through of a photorealistic house, Anshu Chimala made a 3D game, and Sharif Shameem made the Palace of Fine Arts in San Francisco.
These demonstrations got hardware engineers wondering if the models could also generate engineering-grade CAD. Nim Cheema, co-founder of Dessn AI, asked Astra to create a DJ controller. Roberto Nickson made the top models design, engineer, and 3D print bridges. And I launched luxobench.com, where I asked OpenAI’s Astra, Anthropic’s Fable 5.1, and SpaceXSI’s Grok 4.6 to help me build an interactive desktop lamp.
We quickly found that — unfortunately — the models by themselves are still not quite ready for primetime hardware engineering.
There are many levels to building real-world hardware, and clearing each one requires different, and often entirely independent, skills.
At the 101 level, you have to decompose the product down into components, identify available commercial-off-the-shelf (“COTS”) parts, ensure their mutual compatibility, design the mechanical and electrical interconnections between them, ensure the final design is buildable, and then actually procure parts from online stores.
Even this step is hard enough, and can set back not only backyard hobbyists like yours truly, but also the most sophisticated engineering teams in the world. In Walter Isaacson’s biography of Elon Musk, he relays a story of a time in 2006 when a Falcon 1 hot fire was delayed due to a capacitor — a tiny electrical component that was only in stock at a store roughly 6,000 miles away from their launch pad in the middle of the Pacific Ocean. Getting COTS parts where you need them, when you need them, is hard enough.
At the 201 level, however, things get even harder: you now have to make custom parts, which means navigating the complex translation step from digital design tools to physical machines. Take, for example, CNC machining. After a mechanical engineer designs a bracket, they can’t just hit “print” and have the part materialize before them. Instead, they work with a machinist, who translates their CAD file into CAM (“Computer-Aided Manufacturing”) software, which writes the instructions that will actually drive the CNC machine.
In practice, this is an artisanal process that requires a master machinist to choose the right stock, workholding, tools, and cutting strategy to guide the tools as they cut through the block of titanium. This causes variability in the manufacturing process, and variability leads to errors in translation.
At the 301 level, you take those simple parts and start to bring them together into a complex electromechanical assembly. As you add more parts together, you add complexity and “stack” tolerances up — meaning, every part might individually meet its drawing, but still fail to fit into the assembly due to compounded and correlated errors. Those other parts are also likely built by different people on other teams in the company, requiring requirements, schedule, and risks to be communicated across the organization to ensure that the parts can interface nicely together and are delivered when they are needed, but not before and not after.
At the 401 level, you realize that your design needs not only COTS parts and custom-designed parts, but also either inputs or particularly complex assemblies from other external vendors. The hardware world loves talking about vertical integration, but basically everyone relies on vendors — it almost never makes sense to build your own chip fab or copper mine. Even SpaceX, the champion of vertical integration, has 591 current employees with a “supply chain” or related titles, and is actively hiring 128 more.1 And once you have outside vendors involved in building custom parts, good luck!
And then, finally, at the 501 level, you have to do all of the above at massive scale. It is a fundamentally different task to build 1 of something and to build 1,000,000 of something: you need to worry far more about part and process variability, you need much more financing (much further in advance) for things like machines and inventory, you need to train the people (or program the machines) who will assemble, integrate, and test the product for you, and you quickly hit the limits of your vendors.
Each of these “writing” problems, from the 101 to 501 level, are all fundamentally solvable but need to be solved individually. As we’ll discuss below, superhuman AI might be great at pure design, meaning at defining the platonically ideal part for a particular job, but struggle with “design for manufacturing,” or finding a point design that meets the requirements while remaining easy to build/procure and inexpensive. The former is a relatively tractable task that can largely stay within a machine; the latter requires significantly more interaction with the real world, and should therefore prove more difficult for the models to master.
Read access: observing and measuring the real world
One of my friends buys 45 million chickens per week. But despite his efforts to buy the same spec from the same suppliers and run everything through the same process with the same machines, his week-to-week variance in saleable food products after processing (i.e., chicken breasts you can buy at the supermarket) has historically been as high as 20%.
Improving that number over time has taken him a herculean effort: extensive measurement and analysis of every step of his supply chain, plenty of old-fashioned vendor cajoling, and a very sophisticated data operation behind both. In one memorable case, he found a malicious supplier deep in his supply chain that was injecting its chickens with water before shipping them. All of the intake measurements for weight would pass, but that water was, of course, not meat, so he was left with less usable product than he intended to buy.
Everyone who has built hardware at scale, or otherwise managed a supply chain, has their own version of this story. It is exceptionally hard to know precisely what is going on in the real, physical world.
First, the real world is non-uniform, and constantly changing.
Physical objects have defects, change their properties based on environmental variables (e.g., temperature), and are subject to wear and tear. Even extremely well-tuned processes and measurement tools stray over time. In practice, this means that physical systems like supply chains and manufacturing lines constantly break, and must be designed with variance in mind — and you can only know when something breaks or has strayed if you invest significantly in measuring the inputs and outputs of the system.
Second, real-world data is sparse. You can’t get all the data all the time. This is a fact I’m acutely aware of, having worked on a number of satellite programs: our thermal team would have loved to put thermistors more or less everywhere on the satellite, but the software, structures, and production teams unfortunately also got a say.
And then when something goes wrong, you often realize that diagnosing the issue would have been significantly easier if you had collected some obscure piece of data — a picture of an electronics board at an intermediate stage of assembly, an extra sensor at a new location, and so on.
Third, real-world data is often expensive to collect. High-performance domains (e.g., F1 racing) and high-reliability domains (e.g., human spaceflight) often need hardware measurements to be extremely precise, and precision comes with cost in dollars and in time because precise measurements need even more precise machines. For instance, the CMMs (coordinate measuring machines) that measure flatness, perpendicularity, dimensions, and so on for machined parts are not cheap, and often painfully slow to procure and to operate.
Fourth, the real world has inherent latency. Physical processes take time — you can only thermally cycle an electronics board so quickly; mixing volatile chemical solutions or solid rocket propellant must be done with care; and mechanical fatigue testing takes time to play out. These processes can be accelerated, but only so far.
My favorite machine at Astranis, the Highly Accelerated Life Testing (“HALT”) Machine, was colloquially called the “shake and bake” — it combined vibration with rapid thermal cycling to stress parts as fast as possible. But a HALT campaign as a whole is hard to compress: no matter how fast you design new iterations of the board in between tests, you still have to run the whole test again once per cycle.
And, fifth, some information about the physical world is qualitative — and gathering such data is often the most incompressible step of real-world hardware design. Do your users like your product? How comfortable is the device to hold? How easy is it to build a component using your tool? Reckoning with qualitative, unquantifiable data is a part of any real-world build, and measuring that data to bring it back into a digital learning cycle is exceptionally difficult.
Data limitations like these are massive drivers in the spikiness of AI capability development today. The more quantifiable and machine-readable the results of a test, the faster the models can climb the hill. The reasons above have limited the frontier models to date — but how long those challenges can hold back the unstoppable force of the Bitter Lesson remains to be seen.
Hardware development in an AGI world
Hardware engineering is iterative: you design, build, test, and iterate, and each loop through this process takes time.
The design step is digital, and therefore very model-legible. Just as human hardware engineers use computer software to design the part or the assembly, superhuman AI can do the same — and given the growing power of computer use and the growing capability of AI in similar all-digital tasks, we should expect AI models to become superhuman hardware designers in the near future.
But designing hardware is only the very beginning of the hardware engineering process. Once you design the part, you still have to build, test, and iterate — and each subsequent step requires more physical-world interaction than the one before. Becoming a superhuman hardware engineer therefore requires much more than superhuman hardware design, and the frontier will likely be split across many distinct lines of effort.
First, hardware design needs better simulation tools. Every engineer is rooting for Navier, Inviscid, and Lanyon, because better simulation tools would allow hardware engineers to iterate at software speed. Engineers love that better sim tools may save them trips to testing facilities like cyclotrons, radiation sources, thermal-vacuum chambers, and wind tunnels, and executives love that they can save the capex needed to build such facilities in house.
It may prove difficult to convince hardware companies to bet on simulation alone, but as models get demonstrably better, engineers will start trusting the sims more and more, just as sims are getting faster and more efficient per unit of compute. Atoms are likely to stay in the iteration loop forever, but with better sims, atomic assembly can be confirmatory, not experimental.
Second, we expect demand to “shift left,” i.e., move closer to raw materials. As the models distribute superhuman hardware design skills more broadly, the world will need more wire harnesses from Senra Systems, control panels from Podium Automation, machined parts from Hadrian, and electronic components from Cofactr. The world will also need more software licenses, like Sift for telemetry, Instrumental for inspection, and Revel for testing — and, for that matter, more copper from Mariana Minerals.
Armed with superhuman intelligence and new tools, we also should expect to see more companies bring more of their bill of materials in house. Take, for instance, what Diode has done for PCBs.
In its current form, Diode is a way for professional electrical engineers to develop custom printed circuit boards faster and more efficiently. But what happens when everyone has the same skills as a professional electrical engineer? We should expect to see much more demand from a much broader set of users — all of whom will need to translate their designs into the real world, which means navigating supply chains, ensuring designs can be cheaply and accurately built, and more.
Third, the AI labs need to acquire “process knowledge.” You hear the legendary stories of a machinist who can tell how an operation is going just by listening to their CNC machine, or how PhDs at TSMC have spent decades perfecting everything in the semiconductor manufacturing process, all the way down to the polishing pads.
But end-to-end data that could allow models to approximate that kind of “process knowledge” is hard to come by. In Eric Jang’s great piece, “Smooth Exponentials for Robotics,” he estimates that robotics labs in 2026 are training their robots using, roughly — millions of hours of egocentric data, hundreds of thousands of hours of UMI gripper data, tens of thousands of hours of teleoperated robot data, and just hours of “high-quality, hardware-specific demonstrations for high-performance demos.” This funnel is unsurprising, and I expect it to persist even after the superhuman crossover.
The best answer to overcoming this data scarcity, of course, is to find creative ways to get it yourself — Periodic Labs is a great example. The company announced recently that they have set up an autonomous lab to run end-to-end physical experiments on things like superconductors, magnets, and semiconductor materials. This is the platonic ideal of AI-for-hardware data: design, work instructions, test execution, end-result measurement, and iteration all in one coherent loop.
But even the best test setup can only go so far. I suspect that the most incompressible step of the design process — meaning, the step that even a truly superhuman hardware engineer would struggle to expedite — is gathering feedback from the end users of hardware products. A superhuman hardware engineer could design one million new iterations of the Apple Watch and get them manufactured for cheap… but then how can it know what customers actually want?
Superhuman hardware engineers are coming fast
I expect the frontier models to quickly solve hardware design, which will shift the frontier to the remaining steps of hardware engineering (DFM, testing, iteration) that require greater interaction with the real, physical world. Advancing that frontier will mean solving a whole new set of challenges: improving the interface between the digital and physical worlds; finding ways to more quickly discover customer preferences; and building data pipelines that can approximate the process knowledge currently only held by master technicians.
The crossover between human and AI hardware engineering may prove uneven, as laid out above. But once here, its impact should prove immense: humanity will be able to directly use digital AI tools to bring about real, physical, material abundance — or, at the very least, drones for hobbyists that don’t light on fire.
This newsletter is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Furthermore, this content is not investment advice, nor is it intended for use by any investors or prospective investors in any a16z funds. This newsletter may link to other websites or contain other information obtained from third-party sources - a16z has not independently verified nor makes any representations about the current or enduring accuracy of such information. If this content includes third-party advertisements, a16z has not reviewed such advertisements and does not endorse any advertising content or related companies contained therein. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z; visit https://a16z.com/investment-list/ for a full list of investments. Other important information can be found at a16z.com/disclosures. You’re receiving this newsletter since you opted in earlier; if you would like to opt out of future newsletters you may unsubscribe immediately.
Spent years designing cement jobs on a screen. On the screen they always looked great. Then you pump it and the well does whatever it wants. It’s like baking a cake inside a pipe you can’t open.
The chicken story is the same thing. Every weight on the way in was fine, and the water was still in the bird.
Designing is getting cheap. Knowing what really happened down there is where the money is.
AI may make hardware rediscover a very old bottleneck: reality has a refresh rate. You can generate a million designs before lunch, but the machinist, thermal chamber and chicken still refuse to operate at token speed. At some point intelligence gets cheap and contact with reality becomes the scarce resource.