CAD's open moment

To briefly set the scene, I am a mechanical and aerospace engineer by education and first half of career, who ran away to the world of enterprise software — data, AI, dev tools — for a minute or two and counting (8 years). I have spent thousands of hours in each of CAD (mostly Inventor and SolidWorks) and simulation (Fluent and Star-CCM+) and have quickly, if not scarily, amassed similar time in front of coding agents over the last year or so. I am currently spending a lot of time thinking and writing about the good patterns, anti-patterns and shared patterns; and so here we both are!

I’m not quite there on “software engineering is solved” or the SaaSpocalypse¹, but I will say that building software products with Claude Code and Codex is **magical**. It’s magical enough to spend serious time re-imagining the non-software engineering domains. As of this week, with Claude and Autodesk Fusion openly shaking hands, the rate of magic where AI meets geometry seems to be accelerating too.

My last post prodded at an example in ECAD and I decided to develop that a bit further here, because I believe it shows us that the future of CAD is open, and that the time to build said future has arrived.

Software vs ECAD vs MCAD

AI’s impact on software engineering is now beyond refute — transformational. The stars have aligned: code is easy to store, version control, compare (diff), verify, navigate and experiment with. Concretely, exploration in the code domain is very well-supported. Every other domain, from electrical and mechanical engineering, to law and finance is simply starting from a worse place. I’ve tabulated software against electrical and mechanical domains below. An attempt to sum it up would be:

For AI agents to be able to do useful work, they need to be able to author the artifact. To do that, they first need to be able to read the artifact and have access to wider context and history. The signs so far are that this works best if the artifacts are text and code.

Dimension	Software	ECAD	MCAD
Versioned source of truth	Source code, comments, and repo docs	Schematics, layouts, netlists, and DSLs	CAD models, assemblies, and drawings
Readability	Readable by humans, compilers, and agents	Increasingly readable by tools and agents	Visible to humans, opaque to machines and agents
Semantic structure	Modules, types, and dependencies	Nets, parts, constraints, and modules	Features, sketches, geometry, and assembly constraints
Design intent captured	Names, abstractions, tests, comments, and docs	Nets, interfaces, constraints, and modules	Feature history is weak rationale
Breadcrumb trail / rationale	Commits, pull requests, and issues	Reviews, commits, comments, and visual diffs	Revisions are tracked; rationale rarely connected
Change legibility	Diffs, blame, and review	Netlist/BOM diffs; visual PCB review	Hard to diff; hard to interpret
Branches, review, and merge	A native working practice	Code-defined flows are emerging	Weak, with exceptions like Onshape
Tests, checks, and sandboxes	Fast tests and CI	ERC, DRC, CI, and AI review	Slow, fragmented validation, including simulation
Agent legibility and operability	Native: code, tools, tests	Emerging: DSLs, KiCad, APIs	Limited: GUI/API-mediated
Open stack maturity	Deep open-source stack	KiCad, Zener, AllSpice-style workflows	FreeCAD and OCCT exist but the domain is fundamentally commercial and closed-source.
Core bottleneck	Product complexity	Vendor and layout fragmentation	Intent trapped in geometry; ecosystem trapped behind commercial walls.

A recipe for success

The basic recipe for success, in my humble opinion: agents working on legible, open-language source code; substantially trained on said source code; with access to the wider system context; compiling via open, transparent means (i.e. including the kernel) to the final artifact. It’s how software engineering works, and AI works real good on software engineering. Progress is being made in electrical CAD by developing an analogous pipeline.

For mechanical component design, the recipe — a spatially intelligent agent² speaking an open topology DSL³ — is probably this:

Requirements & intent
        ↓
Spatially intelligent AI agent that speaks an open topology DSL
        ↓
DSL source code (version-controlled)
        ↓
Open DSL → open B-Rep kernel
        ↓
Geometry artifact

The openness matters for a few reasons:

1. Open, legible source code powers the improvement flywheel, which everyone (hopefully⁴) benefits from,
2. Open and transparent compilation makes it practical to version control the source, rather than release control the output (the current mode of operation in mechanical design),
3. Source code is, by definition, closer to intent than a compiled artifact, whether it’s bytecode or a STEP file, and that is important for AI authors and much better for human engineers too,
4. While a ‘mechanical component requirements doc’ could in theory become the source equivalent, non-deterministic AI feeding a closed CAD kernel is a black box on top of a black box.

And perhaps less concretely, and more simply, my current vibes and taste (the currency of 2026), a closed AI model driving a closed CAD pipeline feels like something the industry should and will eventually reject. Even in the absence of our new overlord, Claude, rolling into 2026 with the commercial model of CAD looking fundamentally the same as in 1996 and the software looking none-too-different to 2016 feels kinda crappy.

Maybe I put software engineering on a pedestal, but they’ve really schooled us on ecosystem development⁵.

The recipe — is it almost feeding time?

Zoo is the current reference case, with the exception that while their DSL (KittyCad Language) is open source, the kernel that turns that into geometry lives on their cloud. I don’t begrudge them this — the right commercial model for an end-to-end open source play is not obvious.

KCL is a functional, text-based, parametric DSL for mechanical CAD. It sits at the same layer of the stack that Zener occupies in ECAD: a human-readable, machine-readable, version-controllable description of design intent that compiles down to geometry. I like their pitch (paraphrasing): text is readable, text is collaborative, text is what LLMs are demonstrably good at, and binary CAD files are none of those things.

Map KCL onto the recipe and most of the arrows light up:

• Intent → AI agent → DSL source code: Zookeeper, their conversational agent, is doing exactly this.
• DSL source code → version-controlled: It’s text. git init works. KCL files diff like any other source.
• DSL → geometry artifact: Their geometry engine compiles KCL to B-Rep, with full surfaces preserved end-to-end (not the mesh-output trap most “AI CAD” demos fall into).

The kernel arrow doesn’t light up. Zoo’s geometry engine is proprietary and runs on their cloud behind an API. Parasolid still runs most of commercial MCAD. OCCT remains the only credible open B-Rep kernel and adoption is thin. KCL is a serious answer to the upstream half of the recipe. The open kernel is still the open question.

Also in OSS CAD

OpenSCAD has been doing code-as-CAD since 2010. It’s programmer-flavored constructive solid geometry, with a small but loyal following. CadQuery and Build123d are the Python-native descendants, both sitting on top of OCCT. FreeCAD is the closest thing to a full open-source CAD application, also OCCT-backed. None of these have the polish, the funding, or the AI-native posture of Zoo, but they’ve collectively kept the idea of textual, parametric, open mechanical design alive through a long stretch where the commercial industry showed no interest in any of it. KCL is the loudest current expression of an idea that’s been incubating in open source for over fifteen years.

The next moment

Hardware writ-large has been having its moment for a while now. SpaceX ushered in a renaissance, and humanity needs to innovate its way out of a serious set of quandaries across defence, energy, water, and climate. There’s plenty of capital flowing in.

The incumbent CAD players have been protecting a (perceived) fixed pie with their walled gardens and 90s user interfaces. In this way, they’ve likely been part of the bottleneck to creativity and engineering in the face of a Jevons Paradox situation — we’ve got lots of sh** to build!

Software engineering is demonstrating the state of the art for engineering knowledge work. Claude is shaking hands with Autodesk out in the open. A future is arriving, and I suppose the question I’m putting out there is whether the fully-closed-source Anthropic-to-Autodesk pipeline is a step forward. (It’s rhetoric, the answer is obviously no.)

There’s plenty of value on the table. Imagine a defence prime spending bank on humans reverse-engineering STEP files and paper drawings back into modern CAD files. Having been burnt once, you’d think they’d be motivated to avoid the commercial CAD encryption trap™ again. That’s valuable work and a great learning experience for an enterprising startup (and its AI model). Manufacturing is another high-value domain where cryptic “exchange formats” cause immense pain.

My take: fully open CAD is inevitable. Open doesn’t have to mean unprofitable. The software community has designed myriad licensing models. It will require some commercial creativity and a steady nerve, but the prize is huge.

---

Footnotes

1. I’ve spent too long trying to implement technology change within enterprises to believe that anything short of AGI significantly changes the calculus in that market within 5 years. I am an AI bull but don’t yet believe in the sorts of miracles that would be required. ↩

2. By “spatially intelligent”, I mean models that can reason about 3D topology, not just produce convincing renders. The bar is whether the model knows that a hole in a part is the absence of material in a specific location with specific neighbours, not whether it can draw a picture of one. As of writing, frontier multimodal models are demonstrably capable here — see Fei-Fei Li’s World Labs work and the recent Claude/Fusion integration — but “demonstrably capable” is a long way from “ready to drive a B-Rep kernel unsupervised.” Progress curve looks promising. ↩

3. By topology DSL I mean a textual, parametric language whose primitives are geometric and topological operations (sketches, extrusions, sweeps, fillets, booleans), not raw mesh vertices. KCL is the cleanest current example; CadQuery, Build123d, and OpenSCAD are similar efforts. The point is that the source representation should describe what the part is and why. ↩

4. Worth flagging the cynical version of the same observation: the open ecosystem of software engineering may have been the very thing that handed AI the keys. Decades of open code, open issue trackers, open Stack Overflow, open package registries — the substrate that made software engineering legible to humans turned out to be the substrate that made it legible to LLMs. CAD has none of this corpus. Whether that’s a moat (good luck training the model) or a vacuum (whoever builds the open substrate captures the future) is the open question. ↩

5. Software engineering’s open ecosystem isn’t an accident. It’s compounding decisions over forty years: open file formats, open compilers, open package registries, open version control, open editors, open CI. Each layer was a fight. Each fight made the next one easier. CAD has won approximately none of these fights, and the result is the current, lamentable state of play. ↩