Software engineers solved the collaboration problem decades ago. Git, branching, merging, pull requests, diff reviews—these workflows let teams of thousands work on the same codebase without stepping on each other's toes. Every change is tracked. Every decision is reversible. Every version is recoverable.

Mechanical engineers? They're still emailing files named bracket_v3_final_FINAL_new2.step.

This isn't because CAD files are fundamentally different from code. It's because CAD software was built around a paradigm that predates modern version control—and the industry never caught up.

But that's changing. The rise of code-based CAD is bringing Git-style workflows to engineering design, and the implications go far beyond cleaner file organization.

The Problem with Traditional CAD Version Control

Traditional CAD systems treat designs as monolithic binary files. A SolidWorks assembly, a Fusion 360 project, an Inventor part—these are opaque blobs that your file system can copy but can't understand.

This creates several cascading problems:

Binary diffs are useless. When you change a parameter in a SolidWorks file, the entire binary blob changes. Git can tell you the file is different, but it can't tell you what changed. Was it a dimension? A material? A completely new feature? You have no idea without opening both versions and comparing manually. Merging is impossible. Two engineers can't work on the same part simultaneously, then merge their changes. If you branch a traditional CAD file and make changes on both branches, your only option is to manually recreate one set of changes on top of the other. There's no automated merge, no conflict resolution, no three-way diff. File references break. CAD assemblies link to part files by path. Move a file, rename a folder, reorganize your project structure—and suddenly your assembly is missing half its components. This fragility makes reorganization terrifying and collaboration hazardous. History is just file copies. Most engineering teams' "version control" is a folder structure: v1/, v2/, v3/. Maybe with dates: 2026-01-15/. This eats disk space, makes comparison difficult, and provides no context about why versions differ.

The CAD industry's response has been Product Data Management (PDM) systems—essentially glorified check-in/check-out databases that prevent simultaneous editing rather than enabling true concurrent work. It's solving the problem by making it impossible for two people to edit at once. That's not collaboration. That's a queue.

Why Code-Based CAD Changes Everything

Code-based CAD tools like CadQuery and Build123d represent your design as plain text—Python code that generates geometry when executed.

This single change unlocks the entire software engineering collaboration stack:

Meaningful diffs. When a code-based CAD file changes, Git shows you exactly what changed: this dimension went from 10mm to 12mm, this fillet was added, this extrusion direction was reversed. You can read the diff and understand the design intent without opening any software.

# Old version
box = Box(100, 50, 25)  # width, depth, height
New version  
box = Box(100, 50, 30)  # height increased for clearance

A reviewer can instantly see: height changed from 25 to 30, and the comment explains why.

Actual branching and merging. Two engineers can branch the same part, each make modifications, then merge their changes back together. Git handles the merge if the changes don't conflict. If they do, the engineers see exactly where the conflict is and can resolve it intentionally rather than accidentally overwriting each other's work. Pull request workflows. Design changes can go through review before being integrated into the main design. Senior engineers can approve modifications, leave comments, request changes—all before the part goes to manufacturing. The entire discussion is preserved in the version history. Bisection for debugging. When a design breaks—a part no longer fits, an interference appears, a simulation fails—you can bisect the version history to find exactly which change introduced the problem. git bisect works just as well for geometry as it does for code. No file reference problems. Code-based designs don't reference external files by fragile paths. The geometry is generated from the code itself. Reorganize your project however you want.

What This Looks Like in Practice

Imagine an engineering team working on a product with 50 parts. In a traditional CAD workflow, each part is a separate file, and the assembly references all of them. One engineer is working on the enclosure, another on the internal mounting brackets, a third on the PCB mounting system.

With file-based CAD, they're constantly stepping on each other's toes. "Can you check in the bracket? I need to update the enclosure." "Wait, I'm in the middle of a change." The PDM system becomes a bottleneck.

With code-based CAD and Git:

Each engineer branches from main

They work in parallel without blocking each other

When ready, they open pull requests

The team reviews the diffs—"I see you changed the bracket height, does that still clear the connector?"

Approved changes merge back to main

CI/CD can automatically regenerate STEP files, run clash detection, update documentation

The same workflow that lets software teams ship daily can let hardware teams iterate just as fast.

The Skeptic's Objection

"But I need to see the geometry, not read code."

Fair. And nothing about code-based CAD prevents visualization. The code generates the same BREP geometry that traditional CAD does. You can view it, rotate it, section it, measure it. The difference is that the source of truth is text, not a binary file.

Think of it like web development. The HTML and CSS are the source code. The rendered web page is the output. You don't review changes by comparing screenshots—you read the diff, then view the result.

Similarly, you don't review CAD changes by loading two STEP files side by side and hunting for differences. You read the diff, understand the change, then view the result if needed.

Henqo's Approach

At Henqo, we've built our entire pipeline around this principle. When you describe a part in natural language, we generate Build123d code that produces manufacturing-ready BREP geometry. That code can be versioned, diffed, branched, and merged—just like any other software project.

This isn't just about organization. It's about enabling a fundamentally different collaboration model for engineering teams. One where iteration is cheap, experimentation is safe, and the entire design history is intelligible.

The Shift is Already Happening

Cloud CAD platforms like Onshape have started adopting Git-style branching and merging, proving the model works for engineering teams. But they're still built on proprietary binary formats—the branching UI is bolted on top, not fundamental to the data model.

Code-based CAD takes the more radical step: make the design text from the start, and the entire Git ecosystem just works. No special CAD version control system needed. No proprietary PDM. Just Git—the same tool software teams have used for over fifteen years.

The engineers who adopt this workflow now will have a structural advantage in iteration speed and collaboration quality. The rest will keep emailing final_FINAL_v3.step.

---

What does version control look like on your engineering team today? Are you using PDM, cloud CAD, folder structures, or something else? We'd love to hear about workflows that are working—and ones that aren't.

---

Ready to try a CAD workflow built for modern collaboration? Try Henqo free and experience AI-native design with manufacturable output.