Why Engineers Are Switching to Code-Based CAD

Your CAD file is a black box. You know what it looks like. You might even remember how you built it. But try to answer these questions:

What changed between version 12 and version 15?
Why did you choose those specific fillet radii?
Can you rebuild this part with a 20% larger base?

If your workflow lives entirely in a GUI, you're hunting through feature trees and hoping your notes are good. If your workflow lives in code, you just read the diff.

This is why a growing number of engineers—especially those working with AI, automation, and parametric systems—are abandoning traditional CAD interfaces for something that looks more like a Python script than a SolidWorks feature tree.

The Rise of Code CAD

Code-based CAD isn't new. OpenSCAD has been around since 2010. But something shifted in the last two years. Tools like CadQuery and Build123d are seeing serious adoption, and the academic research community is paying attention.

In May 2025 alone, three major papers explored AI + code-based CAD:

CAD-Coder demonstrated a vision-language model that generates CadQuery code from images of physical objects
Text-to-CadQuery proposed a new paradigm for scaling CAD generation using large language models
CAD-Recode showed how to reverse-engineer CAD code from point cloud scans

Why CadQuery specifically? The researchers are explicit: "CadQuery offers the best trade-off between usability and flexibility, making it well-suited for programmatic shape synthesis."

But there's a deeper reason these tools are gaining traction now, and it has everything to do with how AI actually works.

Why AI Loves Code CAD

Here's the uncomfortable truth about AI and traditional CAD: Large language models don't understand click sequences.

When you build a part in Fusion 360 or SOLIDWORKS, you're recording a series of GUI interactions—select this face, extrude 10mm, add a fillet here. That interaction history is stored in a proprietary format that's designed for replay, not understanding.

AI models, on the other hand, are trained on text. Specifically, they're trained on massive amounts of code. Python is one of the most represented languages in their training data.

This creates a fascinating convergence: A Python-based CAD language like CadQuery or Build123d can leverage all the code understanding that LLMs already have.

When you write:

box = cq.Workplane("XY").box(100, 50, 30)
box = box.faces(">Z").workplane().hole(10)

An LLM can reason about this. It understands function calls, method chaining, and parameters. It can modify 100 to 120 and know it changed the width. It can add a new operation and predict what will happen.

Try that with a binary .sldprt file.

The Version Control Revolution

Ask a software engineer what would happen if they couldn't use Git, and watch them shudder. Version control is foundational to how modern software gets built.

Now ask a mechanical engineer how they version their CAD files.

If you're lucky, it's PDM (Product Data Management) software that costs five figures annually. More commonly, it's PartV3_Final_FINAL_v2_JoesEdits.sldprt.

Code CAD changes this equation entirely. When your geometry is defined in text files, you get:

Meaningful diffs: See exactly what changed between versions
Branching: Experiment with design variants without duplicating files
Merge capability: Combine changes from different team members
Commit history: A complete record of why every change was made
CI/CD integration: Automatically validate designs on every commit

This isn't theoretical. Teams are already using GitHub for CAD. The CadQuery community has hundreds of shared models that benefit from the same collaborative workflows that made open source software possible.

Parametric Design, Actually Parametric

Every CAD system claims to be "parametric." Define some dimensions, change them later, and the model updates.

In practice, parametric CAD breaks constantly. Change the base sketch and watch downstream features fail. Modify a fillet and see half your references turn red. This is the infamous Topological Naming Problem that we've written about before—and it's been plaguing CAD for 30 years.

Code CAD handles parametrics differently. Your parameters are just variables:

BASE_WIDTH = 100
BASE_DEPTH = 50
HOLE_DIAMETER = 10
box = cq.Workplane("XY").box(BASE_WIDTH, BASE_DEPTH, 30)
box = box.faces(">Z").workplane().hole(HOLE_DIAMETER)

Want to generate 10 variants? Loop over different values. Want to tie dimensions to a spreadsheet? Read from a CSV. Want to expose parameters as command-line arguments? That's just Python.

The parametric behavior isn't layered on top of an implicit model—it's inherent in how the geometry is defined.

The Learning Curve Objection

The obvious pushback: "Not everyone can code."

It's fair. Traditional CAD has a lower barrier to entry for basic tasks. Sketch a rectangle, push-pull it into a box, done.

But consider the full picture:

Most CAD users hit walls. Advanced surfacing, complex assemblies, design automation—these require specialized knowledge regardless of interface

Code is actually learnable. More people can write Python today than at any point in history

AI assistants change the equation. You don't have to write code from scratch. You describe what you want.

That last point is where tools like Henqo come in. We believe the future isn't "code CAD vs GUI CAD"—it's natural language CAD backed by programmatic representations.

You say "make a box with a hole in the top." The AI generates CadQuery or Build123d code. You can inspect it, modify it, version control it, and feed it back to manufacturing systems that expect STEP files.

The code is the source of truth. The interface is just conversation.

When Code CAD Makes Sense

Code-based CAD isn't for everyone or every project. It shines brightest when:

You need design automation: Generating families of parts, configuration management, batch processing
You work with AI systems: LLMs can read, write, and reason about code
Version control matters: Collaboration, history, traceability
You value reproducibility: Script generates geometry deterministically
Manufacturing integration is critical: Code outputs BREP (STEP files), not just meshes

It's less ideal when:

You're doing highly organic, artistic shapes
Speed of initial concept sketching matters more than downstream workflows
Your team has zero programming experience and no interest in learning

The Future is Hybrid

We're not arguing that code CAD will replace all GUI-based design tools. The creative exploration of early-stage design often benefits from direct manipulation.

But we are arguing that the industry is moving toward code as the canonical representation of designed geometry—especially as AI becomes more capable.

GUI-based CAD will increasingly become a view into underlying programmatic definitions. You'll sketch with your mouse and the system will generate code. You'll prompt in natural language and see both the geometry and the script that created it.

The question isn't whether you'll work with code CAD. It's whether you'll use it directly or through an AI intermediary.

---

What's your take on code-based design? Have you tried CadQuery, OpenSCAD, or Build123d? We'd love to hear what's working (or not) in your workflow.

If you're curious about AI-native CAD that outputs real STEP files, try Henqo — we're building the bridge between natural language and manufacturing-ready geometry.