Automating CAD Design Workflows with Generative AI

Repetitive operations in a CAD environment — dimension updates, assembly revisions, output packages — are mostly rule-based. LLMs can bridge those rules with natural language and structured input; but geometric correctness and manufacturing reality must stay with engineering discipline and validation layers.

Important: AI is leverage for speed and iteration; architectural decisions, testing, and quality remain the responsibility of a person.

• Input normalisation: turning user dimensions, material, and variant choices into a structured form
• Rule engine: the engineering rules that trigger parametric CAD updates
• Validation: geometry, assembly interference, and production output checks
• Documentation: the standard flow of PDF, DWG, DXF, and production-data packages

Where LLMs are strong

Converting natural-language input into structured parameters, simplifying error messages, and producing repetitive documentation text are valuable at this layer.

Where LLMs are not enough on their own

Critical geometry calculations, tolerance chains, production-line compatibility, and licensed CAD API limits require human oversight.

"Let's do CAD automation with AI" is not a project definition. Every attempt started without narrowing the pilot ends the same way: a demo that works but nobody trusts. I narrow it with four questions:

1. Which task repeats, and how many times a month? Automating something done three times a month costs more than it returns.
2. How structured is the input? Do the dimensions arrive from a form or from the body of an email? The second is where an LLM genuinely adds value.
3. What does a wrong output cost? A wrong quotation drawing gets corrected; a wrong DXF sent to cutting turns sheet metal into scrap. As the cost rises, the validation layer thickens.
4. Who knows the right answer? If nobody can confirm the output is correct, the pilot cannot be measured.

A good first pilot is usually this: a task that repeats often, has messy input, and where being wrong is cheap. In most firms, the quotation stage fits that description exactly.

If you do not measure the current state before the pilot starts, you have no baseline afterwards. The four metrics I record:

Of these, the correction rate teaches the most. A high rate does not mean the automation is not working; it shows where the rule set is incomplete. Looking at where corrections cluster writes the agenda for the next development round on its own.

The checks every automatic output must pass before reaching production — in order, stopping at the first failure:

1. Input completeness — did every required parameter arrive, are the units right
2. Range check — is each dimension within a manufacturable range (line width, minimum bend radius, sheet thickness)
3. Geometry health — did the rebuild complete without errors, are there open contours or zero-thickness faces
4. Assembly interference — is the interference check clean
5. Output integrity — were all expected files produced, are their sizes plausible
6. Naming and revision — does the filename follow the scheme, has the revision number advanced

This entire list is deterministic; there is no LLM at any step of it. The model's job was to understand the input and turn it into parameters; correctness is decided by rule code.

The separation must be clean: an LLM's output never goes straight to production, it always becomes the rule engine's input. If the rule engine rejects it, the job stops.

Accepting up front where generative models are not good on the CAD side is the decision that saves the project:

• Tolerance chains. Cumulative tolerance calculation is arithmetic and standards work, not judgement. Do not hand it to the model.
• Critical geometry. Strength, centre of gravity, section calculations — these are library work, not generation work.
• CAD API limits. Which call returns what in which version is documented knowledge; this is exactly where hallucination is most likely.
• Production-line reality. The model does not know what the roll-form line can bend; that knowledge is entered into the rule set by hand.

Against that, there are three places the model genuinely pays: structuring messy input (an email, a phone note, the description of a hand sketch), translating error messages into language the user understands, and producing repetitive documentation text.

I order it like this: pick a narrow pilot → measure the current state → give input normalisation to the LLM → leave the decision to the rule engine → validate the output with a deterministic checklist → grow the rule set by watching the correction rate.

This loop survives changes in the technology. When the model gets better, the first step gets faster; but the need for the validation layer does not shrink.