The Demo Video Problem

The AI-generates-a-3D-model demo is genuinely impressive: type a sentence, watch a bracket appear. What the demo never shows is the part going to manufacturing: the fabrication drawing with correct dimensions and weld symbols, the BOM with the right part numbers, the tolerances your shop floor actually holds. That gap between "a model appeared" and "production documentation shipped" is where engineering teams live, and it's why most AI-in-CAD content feels disconnected from real work.

Manufacturing has a non-negotiable requirement that pure generative AI struggles with: determinism. The same order must produce the same drawing, every time, auditable down to the dimension. A system that produces something plausibly different on each run is a liability in a release process, no matter how impressive the demo.

So the honest question isn't "can AI do CAD?" It's: which specific part of the automation problem is AI actually good at, and how do you wire it to the parts it isn't? After building both classic rule-based automation for 19 years and now an AI-driven system running in production, our answer is specific: narrower than the hype, but far more useful.

Where Rule-Based Automation Hits Its Ceiling

Classic CAD automation is rule-driven: engineering logic encoded as software, driving the Inventor, SolidWorks, AutoCAD, or Revit API to generate models, drawings, and BOMs from parameters. When parts follow a family (poles, conveyors, enclosures, frames), rules are unbeatable: cheap to run, deterministic, and fully auditable.

Rules have one hard precondition that's easy to miss: they assume you already know what the geometry is. A rule that says "offset the punch contact faces by the flash allowance" works only if something can tell it which faces are the punch contact faces. On a parametric product family, that knowledge is free: face seventeen is always the mounting face, because the template says so.

Now remove the template. Some manufacturers never see the same part twice: every incoming job is a new, unique shape. The workflow around each part is perfectly repetitive (the same tooling, the same drawing package, the same steps), but the geometry itself never repeats. There is no parametric baseline, so there is nothing for the rules to anchor to. For decades the only automation for this class of problem was a highly experienced engineer who could look at a novel part and simply know which surfaces mattered. That knowledge lived in a handful of heads, took years to grow, and walked out the door at retirement.

That is the ceiling. It isn't a scripting problem; no amount of better code fixes it. It's a recognition problem.

What AI Actually Contributes: Recognition

This is the piece AI genuinely solves. A machine-learning model trained on past projects can look at a part it has never seen and classify what the geometry means: this region is the die area, these faces are the punch contact surface, this is where flash begins and ends. In effect, it learns the same judgement the senior engineer applies, from the same evidence: hundreds of previously completed projects.

The model class that fits this problem reads the CAD data the way engineers do: as topology, not pixels. Graph neural networks over boundary representation (B-rep) geometry treat faces as nodes and edges as connections, the same way a feature tree treats geometry, just learned instead of authored. Trained on a manufacturer's own history, the model captures that company's specific engineering judgement, which is both the point and the moat: it encodes your decades of decisions, not generic internet geometry.

Note what the AI is not doing in this design: it is not drawing anything, not placing features, not generating geometry. It answers exactly one question, what is this?, and hands the answer to conventional automation, which has known how to act on that answer all along.

The Architecture: AI Brain, CAD Hands

The production architecture that follows from this division of labor is a closed loop with a strict separation: the AI decides what the geometry means; the CAD platform builds every feature natively. In our system it runs as five steps:

NAME. Every face of the model is assigned a persistent identity (S1, S2 … Sn) inside the CAD platform, before the part goes anywhere. This is the contract that holds the whole loop together.
EXPORT. The part leaves CAD as STEP AP242, an open, neutral format that carries the full B-rep topology plus those persistent face names. Geometry and identity travel together.
PREDICT. A locally hosted AI service reads the STEP file and returns plain JSON: semantic label → list of face IDs. No cloud dependency, no design data leaving the building. That is a hard requirement for most manufacturers, and easier to satisfy than most teams expect.
MAP. Back in CAD, the labels re-anchor to live faces by name. When the AI says "face S47 is punch area," the CAD platform knows exactly which face that is.
BUILD. Native API operations (the same delete-face, offset, extrude, and split calls that classic automation has always used) construct the output. The result is a normal, fully editable feature tree.

Two properties of this architecture matter more than any individual step. First, determinism is preserved where it counts: the AI's classification is checked and mapped before anything is built, and everything downstream is ordinary rule-driven automation you can audit. Second, the layers are swappable: because recognition and geometry-building never touch, you can retrain or replace the model, add a new output type, or change CAD versions without re-engineering the handoff. In our deployment, eleven distinct tooling workflows (dies, punches, knockouts, electrodes, and the production drawings for all of them) run through one unchanged pipeline.

Your data never leaves your building For teams with proprietary designs, this is usually the first question: where does our data go? With a custom model, nowhere. The model runs on your own infrastructure, inside your network, and your design data is never sent to an external server. The compute-heavy step is training, which benefits from a higher-spec machine (typically a GPU); once the model is trained, running it on a new part is far lighter and generally runs on a standard engineering workstation. You own the model, the data, and the pipeline end to end.

A Production Example: Non-Repetitive Tooling

The system described above is not a lab project. We built it for a leading watch manufacturer whose new-product team designs unique case and dial geometries: by definition, parts that never repeat. Every new part needed a complete press-tooling set (die, punch, knockouts, electrodes) plus manufacturing drawings, designed from scratch. Only a small group of highly experienced engineers could do the work, it took one to two weeks per part, and rule-based automation had failed repeatedly for exactly the reason described earlier: non-repetitive inputs give rules nothing to anchor to.

With the AI classification layer in front of conventional CAD automation, that tooling design now completes in under four hours, with fewer revision loops, and with newer engineers producing output that previously required the most senior people in the room.

The result we'd underline isn't the speed. It's the knowledge retention: judgement that used to exist only in a few senior engineers' heads is now captured in a trained model the company owns. That expertise no longer retires, resigns, or gets poached.

Do You Need AI, or Just Good Rules?

Here is the test we apply on first calls. Note that it disqualifies most projects from needing AI at all:

Do your parts follow families or templates? If yes, you don't need AI. Rule-based automation will be cheaper, faster to build, and deterministic. Most configure-to-order businesses live here.
Can an engineer write down the logic? If your best engineer can explain the decision process as rules, even hundreds of them, encode the rules. Rules you can read beat models you have to trust.
Is the input genuinely non-repetitive? Unique geometry on every job, with expert judgement required just to interpret it: this is the AI case. The signature: your automation attempts keep failing at the "which faces?" step, not the "build it" step.
Do you have training data? The AI case requires history: hundreds of completed projects whose outcomes encode the judgement you want to capture. If the projects exist in your archives, you likely have what's needed; the data is usually messier than anyone hopes and still sufficient.

The uncomfortable truth a vendor selling "AI-powered" everything won't tell you: if a rules-based system can solve your problem, adding AI makes it worse: more cost, more validation burden, less explainability, for zero added capability. AI belongs in the pipeline only where rules structurally cannot go.

Copilots, Assistants, and Generative Design

Three other things currently travel under the "AI + CAD" banner, and they're worth separating from production automation:

CAD copilots and assistants, natural-language interfaces like Autodesk Assistant arriving in Inventor 2027, make the software easier to drive interactively. Genuinely useful for accessibility and learning curves; not a pipeline. An assistant helps an engineer do a task; production automation does the task without the engineer.
Generative design and topology optimization explore geometry under constraints: powerful for weight reduction and concept exploration, but they produce candidate geometry for a human to evaluate, which is a different job than producing release-ready documentation unattended.
AI code assistants quietly deliver the most immediate value: they've made writing the automation itself (iLogic rules, API add-ins) dramatically faster. The engineering discipline around that code (validation, error handling, deployment) still decides whether it's production software or a clever snippet.

How to Evaluate an AI + CAD Project

If your workflow passes the non-repetitive test, the evaluation path is more ordinary than the technology suggests:

Start with the workflow map, not the model. Which decisions require expert recognition, and which are rules pretending to be judgement? The AI scope should shrink during this exercise; that's a good sign, not a bad one.
Audit the training data. Completed projects, in CAD formats you can still open, with enough consistency to label. This determines feasibility more than any algorithm choice.
Prototype the recognition first. Before building any pipeline: can a model trained on your history classify a held-back part your team agrees is correct? That single result de-risks the entire project.
Insist on the separation. Whatever a vendor proposes (including us), the AI should output labels, and native CAD automation should build the geometry. If the pitch has AI "generating the model" end to end, ask how release-quality drawings and auditability work. Then watch the answer carefully.

AI didn't replace CAD automation. It removed CAD automation's oldest limitation: the requirement that someone already knows what the geometry is. For manufacturers whose every part is unique, that changes what's automatable at all. For everyone else, the rules you could have built five years ago are still the right answer, and they're cheaper than ever to build.