Why I'm So Excited About AI Generating CAD: It Finally Gives Us Open Hardware

Open-source hardware barely exists.

For you to read this article, hundreds — probably thousands — of open-source software dependencies are doing their job: the browser, the rendering engine, the networking stack, the servers it came from. Almost all of that is open. Almost none of the hardware it runs on is.

Software has an enormous open commons. Essentially every modern product is built on a mountain of shared, reusable, freely available code, and that feedback loop is a huge part of why software improves as fast as it does. AI itself is built on that shared foundation. Hardware has almost nothing like it. There is no real library of open, reusable design assets in the physical world — not because hardware engineers are less generous, but because the way hardware gets designed never allowed one to exist.

I think that's about to change.

AI is going to design most hardware. Not assist a human clicking through a CAD tool — actually generate the designs, the way it increasingly writes software: as text, as code. Describing geometry as code isn't a new idea; OpenSCAD, CadQuery, and build123d have pushed it for years. What held it back was that the code was tedious to write by hand. AI removes exactly that barrier.

And when a design is code, open is its natural state. Code is made to be read, copied, forked, and built on. Once most hardware is written as code by AI, the friction that kept hardware closed mostly goes away, and we get what software has had for decades: a growing library of open hardware that people actually use and build on.

I've spent the last three years on this as a side project, and I'm more convinced than ever it's where things are headed. The reason we never got here before is pretty clear: the geometry kernels are closed-source, and the file formats of the big CAD vendors — Dassault Systèmes, Siemens, Autodesk — are sealed shut. You can't build a community on top of that. The rest of this post is why I believe the wall is coming down, and what we're building at CADbuildr to help it along.

None of this is hypothetical — we're building the pieces in the open today: Foundation (the feature-tree library), IronStream (a from-scratch Rust kernel), castiron (tree-to-kernel compiler), and open projects like a chess set and woodworking joinery built on top.

The loop hardware never got

Why does an open commons matter so much? Because of the loop it creates.

If you write software you know it by heart. A company releases something into the open. The community uses it, stresses it, finds the bugs, hardens it. Then the company builds on top of the hardened thing, and so does everyone else. Value compounds and everybody wins.

Side by side: Meta releases PyTorch, the AI community hardens it, everyone builds on top and value compounds — versus a hypothetical Airbus part library sealed in closed formats, where nobody can fork it and every supplier starts from scratch.

Figure 1 — The loop. PyTorch compounds in the open; a sealed part library never does.

That loop has barely touched hardware.

What hardware got instead was patents. A patent walls an idea off for years and you need lawyers to cross; open source invites you to clone the repo and start building this afternoon. One of these produced an explosion of shared progress. The other was useful last century and arguably slows us down now.

Count the genuinely open hardware projects in the world and you get a short list: RepRap, Prusa's printers, Arduino, and not much past them (the GitHub open-source-hardware topic is a good place to look). Compare that to the mountain of open-source software. The asymmetry is staggering, and it's not for lack of goodwill — the tools don't allow it.

Think about what sits on the wrong side of that wall. The most sophisticated objects we've ever built — the airliners Airbus and Boeing build, SpaceX's reusable rockets, the EUV machines ASML ships to a handful of chip fabs, entire factories — all existed as geometry before they existed as metal. Folded into that geometry are years of experiments, failures, and hard-won material-science lessons. The geometry and its documentation is a large part of the knowledge, and almost none of it ever loops back to the rest of us.

Why hardware got left out

CAD is dominated by a handful of giants, and their tools are built on two closed things: a closed file format and a closed-source kernel. Dassault Systèmes (SOLIDWORKS, CATIA), Siemens (NX), Autodesk (Fusion 360, Inventor), Ansys — pick any of them, and both the format your work lives in and the engine that computes your geometry are sealed.

This isn't only greed. The geometry kernel — the B-rep / NURBS engine that decides how surfaces meet and solids resolve — is genuinely hard software, and it can't be perfect; that's the nature of solid modeling. Every kernel is opinionated. Each has its own strengths, its own quiet decisions about how a shape gets built, and its own ways of breaking.

That explains why the industry barely moves. Boeing or Airbus won't switch from CATIA even for something cheaper and nicer, because they know exactly how their current kernel fails. The failures are familiar and planned around. Predictable breakage is worth more to them than a better tool with unfamiliar bugs.

Which makes "just build a new open kernel" a brutal proposition — nobody wants to write the thing that breaks in new ways. The exceptions are rare enough to name: Open CASCADE, and more recently Rust kernels like Truck and Fornjot.

The thing we keep throwing away: intent

There's a deeper problem underneath the format wars, and it's the one I care about most.

Export a CAD model today and you get one of two things: a STEP file (the boundary representation) or a mesh (triangles). Both are useful. Both throw away the most important part: intent.

A designer's reasoning doesn't live in the final surfaces. It lives (partially) in the feature tree — the sequence of operations, the sketches, the links between dimensions, the parameters, the tolerances. Something as simple as "this dimension drives that one, in three places" is gone the moment you flatten to STEP or mesh. You keep the answer and lose the thinking.

A feature tree with one driving dimension flowing through three features, exported to a STEP/mesh shell where the tree, the linked dimensions and the parameters are gone.

Figure 2 — What gets lost on export. One driving dimension flows through three features in the tree. Flatten to STEP or mesh and the geometry survives — the reasoning doesn't.

The CAD vendors know the feature tree is the crown jewel. That's why they keep it — in their own binary formats, where you can't get it out cleanly or carry it anywhere else. There's no good way to take a feature tree from one tool and rebuild it in another, so you're stuck in their world.

That lock-in is the business model. It's why a vendor can charge thousands of dollars for shared version history (PDM, PLM…) — something software engineers have had for free, and frankly better, since Git. We solved collaborative history two decades ago. CAD users are still renting it.

So these assets should be stored as feature trees: portable, inspectable, versionable. As text. What's new is that this is finally within reach.

What just changed

AI has changed how software gets written, and it's collapsing the value of a whole category of software assets. A piece of software is worth less and less on its own; the value sits in the data and the users around it. A geometry kernel is exactly the kind of asset losing its moat. What used to be a fortress is becoming a commodity.

Pretty soon, standing up a kernel won't be a multi-year heroic effort. It'll be closer to one-shot, AI-generated, cheap. We're building one ourselves right now (more below), so I can tell you it's not one-shot yet — but the trend line is unmistakable. Will Boeing switch the day it lands? Of course not — they're locked in by familiarity as much as by the kernel. But most hardware isn't Boeing. There's a whole world of new products, parts, and projects starting fresh every day, free to pick the open path from day one. That's how software flipped, too: not by converting the mainframes, but by everything new choosing the open stack.

Portability is heading the same way. We already watch AI rewrite entire codebases into another language, all at once, successfully. There's no fundamental reason it can't do the same for designs: read a model out of CATIA, rebuild it in Onshape, or the other way around. That's the thing worth building — not another walled garden, the bridges between them.

That leaves the big CAD vendors with two exits:

  1. Stay closed and build AI features inside their own software. Then an outside agent — Claude, ChatGPT — can't read or drive their tool. They keep the format closed and get left behind.
  2. Open up, with real APIs and MCP-style interfaces, so models can read feature trees and write them back. The moment they do, the format isn't really closed anymore — and switching tools gets easy.
Flowchart: a closed CAD vendor either stays closed and gets cut off from the frontier models, or opens APIs so models can read and write feature trees, and the format stops being closed.

Figure 3 — The two exits. Stay closed and get cut off from the frontier models, or open up and give up the lock.

Either way, the lock loosens. I'm betting on the second exit.

CAD as code (and why it never won — until now)

CAD as code isn't new. OpenSCAD, CadQuery, build123d, and newer entrants like Zoo.dev are variations on the same bet: describe the design in code.

The upside is real — parameters, reuse, version control, generation. But so is the cost. Code isn't always pleasant to modify, and sometimes you genuinely want an interface: you want to draw the sketch, not hand-edit ten lines to nudge a corner. That tedium is why the industry never made the jump.

AI removes it. Software engineers already write specs and let the AI write the code; for a lot of us that's simply how it works now. The same shift is coming to CAD: you get the expressive, portable, versionable code representation, and you skip the typing, because you're not the one doing it.

A lot of people look at this and bolt AI into each individual CAD tool. I think that's a band-aid. The better move is to let AI write the design as code, validate it across real engines, and use those engines to export clean results. The missing piece is a common representation: a tree of features.

What we're building: an open hardware ecosystem

This is where CADBuildr comes in. The core is Foundation, an open-source Python library that turns code into a feature tree, kernel- and software-agnostic. But Foundation alone isn't enough. If you want an open commons for hardware, you have to work the whole stack — and that's what we're building.

The CADbuildr stack: kernels at the bottom including IronStream in development, translators above them, Foundation in the middle with importers feeding it, libraries and tools above, and open hardware projects on top. On the side, the knight from the chess package traces through the layers.

Figure 4 — The stack, bottom to top. Follow the knight from our chess set: it ships in the chess lib with a dependency on foundation, and a kernel meshes it into the STL/STEP you print.

Foundation at the center of a hub: CAD-as-code libraries on one side, CAD software and open kernels on the other, with arrows reading designs into the tree and building back out.

Figure 5 — Foundation as the interoperability hub. CAD-as-code libraries, CAD software, and open kernels all connect to one portable feature tree — read in, build out, both directions.

Layer by layer, from the bottom up:

Kernels. A feature tree has to be computed into geometry by something. Today that's Open CASCADE; we're also building our own — IronStream, a from-scratch Rust kernel, with castiron compiling Foundation trees straight into it and a Python binding so you can just import ironstream. Still a work in progress — kernels are humbling, ask me how I know — but it's getting close.

Translators. The bridges into other people's tools and back: Onshape works today, FreeCAD and SOLIDWORKS are next. Nobody will use open assets they can't bring into their own software, so as the vendors open their APIs, this layer grows.

Importers, sitting alongside Foundation: shims that let existing CadQuery and build123d files run unmodified and produce a Foundation tree, with OpenSCAD and Zoo next. If you already have designs as code, you shouldn't have to rewrite them.

Libraries on top. A standard library of off-the-shelf components — screws, bearings, motors — each modeled once, in the open. Electronics, analysis, sheet metal, wood joinery, and whatever the community needs next.

Open hardware projects at the very top. The point of the whole stack. We've built an open chess set you can browse part by part, woodworking joinery with precise joint interfaces, LEGO-compatible parts, and we're porting a full Prusa i3 printer. Each project exercises every layer below it, and each one is a seed for the commons.

A nice side benefit of building this on a modern web stack (Pyodide, WebAssembly): the CAD renders directly in a web page. The chess set below is live in your browser — the Foundation code runs and gets meshed on the fly, no install.

The full chess set, authored in Foundation, running live in the browser via Pyodide and WebAssembly — placed on a table in a Mars scene.

Figure 6 — CAD in a web page. The chess set, built and meshed live in the browser — on Mars for good measure.

The ambition is, honestly, enormous: an open, composable representation of everything we design, and a much faster way to design the next things. We're still figuring out how to sustain an effort like this. But the direction is clear enough to start, so we started — and I'll be sharing these tools here as they land.

This is for everyone

I've spent most of this post in the weeds — kernels, trees, formats — because you have to see the trap clearly to believe there's a way out. But the technical stuff isn't why I care.

Make it concrete. Say a rural clinic needs a peristaltic pump — the kind that moves fluid without contaminating it. Today your best case is finding an STL on a forum: a dumb shell you can't resize without remodeling it from scratch, in software you'd have to learn or buy. In the world I'm describing, that pump is an open package. You tell an agent it has to fit the 8 mm tubing and the motor you can actually buy locally; it edits the feature tree, the linked dimensions propagate, the bearings and screws come from the standard library, an analysis package checks the flow rate, and you export a clean STEP for whichever machine shop or printer is nearby. Your variant goes back into the commons for the next clinic. That's the loop from the top of this post, finally closing on a physical object.

When a good representation of a design is open and portable, you can share the thing itself — reproduced on the other side of the planet, adapted to local needs, improved by whoever touches it next. Linux runs the servers of the most valuable companies on Earth and the secondhand laptop in a classroom with no budget. Open hardware can serve both ends the same way: clean water, medical devices, tools, and infrastructure reaching people that closed formats priced out, while also accelerating the most advanced engineering we do.

A shared common-good layer for designing things in the open. That's the goal, and the window to build it is open right now.

It's what I'm spending my AI tokens on. If you want to build on any of this — or tell me why I'm wrong — I'd love to hear from you.

References & links

What we're building (all open)

CAD-as-code tools

Open-source geometry kernels/software

The incumbents (closed CAD)

Open hardware to explore