The Real Limitations of AI CAD (And How to Work Around Them)

AI CAD is genuinely useful for producing geometry from a clear description, and genuinely incapable of engineering judgement. The gap between those two statements is where most disappointment — and most bad decisions — come from. This is a specific account of the limits, what causes each one, and how to work productively inside them.

For the positive case, see can AI really design mechanical parts.

Limits that come from the technology

These are structural. They follow from how the systems work, described in how LLMs generate CAD.

Spatial reasoning is weak. A language model reasons over tokens, not over space. Whether a boss actually intersects the wall it is supposed to join, whether a rib is floating 2 mm off the surface, whether two components interfere — these are geometric facts the model infers indirectly and often gets wrong. Good systems catch this with deterministic geometry checks after generation, but the underlying weakness does not go away.

Arithmetic slips. Derived dimensions — bolt circles, pitch diameters, centre distances — involve calculation, and calculation is not a strength. The mitigation is to compute derived values in the generated script rather than asking the model to produce a number.

Training data is scarce. Mechanical CAD is a data-poor domain compared with text or images. Public datasets of parametric CAD models exist but are small, which means coverage is uneven: common part archetypes are handled well and unusual ones degrade sharply.

Non-determinism. The same description can produce different geometry on two runs. For specified dimensions this does not matter; for assumed ones it does, which is why a tool that distinguishes given from assumed values is more trustworthy than one that presents everything with equal confidence.

No self-knowledge. A model has no reliable internal signal for "I have never seen this part type". It will produce a confident script for something it handles badly.

Limits that come from the domain

These would exist even with a perfect model, because they are not geometry problems.

Requirements do not come from the description. "A bracket to hold a motor" does not say what load, what duty cycle, what temperature, what vibration environment, what safety factor, what material or what standard applies. Those are engineering inputs, and if they are not stated somewhere, no system can infer them.

Verification is a separate discipline. Whether a part is strong enough is answered by calculation or test, not by generation. A model can produce a shape; it cannot tell you the stress in it. See Hertzian contact stress and VDI 2230 bolted joints for the kind of analysis that has to happen independently.

Standards compliance cannot be self-certified. A generated part may cite ISO or DIN designations; that is not the same as conforming. Compliance is verified against the actual standard document, by someone who has it.

Responsibility is not transferable. If a part fails, the engineer who released it is accountable. No current tool absorbs that, which means every generated model needs a human owner before it leaves the building.

Manufacturing route selection is a judgement. Machined, cast, moulded, printed, fabricated — each implies different geometry. A tool can apply the rules for a process you name; choosing the process is an economic and engineering decision involving volume, cost, lead time and supplier capability. DFM 101 covers the rules; the choice remains yours.

Capability by task type

Maturity here means "how often the output is usable without correction", not "whether it produces something".

Working around the limits

The limits are workable. These practices are what actually change the hit rate.

Specify what matters, explicitly. Every dimension you do not state is a dimension the system will assume. State the ones that interface with something else — bores that take a bearing, bolt patterns that match a mating flange, envelope constraints — and let the rest be assumed. The prompt structure that works is in how to write a CAD prompt.

Name the process. "Machined from 6082 aluminium" and "injection moulded in ABS" imply completely different wall thicknesses, radii and draft. Naming the process activates the right rule set.

Reference standard parts by designation, not description. "M8×1.25 hex head, property class 8.8" is verifiable. "A medium bolt" is not.

Decompose large assemblies. Generate components individually against a defined interface, then assemble. This plays to the strength (single parts) and avoids the weakness (many simultaneous relationships).

Change one thing per iteration. When a model is nearly right, adjusting a single dimension tells you whether the change did what you expected. Adjusting five tells you nothing.

Verify against a checklist, not a glance. Envelope, wall thickness, hole sizes and fits, interference, tool access, mass. A model that looks right passes visual inspection by construction — that is what generation optimises for. The concrete list is in why AI CAD fails on the shop floor.

Match the tool to the stakes. Concept geometry, fixtures and jigs, and internal prototypes tolerate a much lower bar than a load-bearing production part. The framework for that decision is in when to trust automation.

What would have to change

Being clear about the path forward is more useful than assuming everything improves uniformly.

• Better geometric verification, not better prompting. The gains available from checking output rigorously are larger than those from asking more nicely.
• Larger and better parametric CAD datasets. This is the binding constraint on generalisation to unusual part types.
• Native tolerancing. Until tools reason about fits and stack-ups rather than nominal geometry, the drawing stays a manual step. See tolerance stack-up.
• Assembly-level reasoning. Constraint solving over a component graph is a different problem from generating one shape, and it is largely unsolved in this context.

The bottom line

AI CAD is a fast producer of first-draft geometry and not a source of engineering decisions. Its limits are specific and mostly predictable: spatial reasoning, arithmetic, tolerancing, assemblies, surfacing, and anything requiring judgement or accountability. Used for what it is good at — routine geometry from a clear description, generated quickly and verified deliberately — it removes real hours. Used as a substitute for engineering, it produces confident-looking files that fail on the shop floor.