The Problem Nobody in AI CAD Talks About Honestly

There is a lot of noise right now around AI-assisted CAD. Generative design. AI mechanical layout. Automated DFM checking. Feature suggestion engines. Smart assembly automation. The pitch is compelling: train a model on millions of engineering files, and let it accelerate the work that used to take weeks.

I understand the appeal. I’ve been in rooms with engineers who spend hours on repetitive SolidWorks operations. I’ve watched experienced product designers redo the same tolerance stacks because nobody documented the lessons from the last three production runs. If AI can absorb that institutional knowledge and surface it in real time — the efficiency gains would be real.

But there’s a problem that almost nobody in the AI CAD space talks about honestly: where is the data actually coming from?

Not model architecture. Not GPU budget. Not even labeling pipelines. The fundamental bottleneck is sourcing real engineering data — the kind of data that actually makes a CAD AI system useful in production environments. And most of the startups building in this space are significantly underestimating how hard that problem really is.

Public CAD Repositories Are Not Engineering Data

The instinct for many AI companies is to start with what’s freely available. GrabCAD has millions of models. Thingiverse is full of geometry. Various open repositories have accumulated enormous amounts of uploaded files over the years. Surely that’s a starting point?

It is a starting point — but only for geometry recognition, not for engineering intelligence.

Here’s what most public CAD uploads look like in practice: a STEP file. Sometimes an STL. Occasionally a SLDPRT with a flat feature tree, no configurations, no tolerances embedded, no revision history, no relation to a drawing, and no manufacturing context whatsoever.

When an engineer exports a model to share it publicly, they strip almost everything that makes that file operationally valuable. The feature tree structure — the decision logic of how the part was built — is often flattened or lost entirely. The assembly constraints, the engineering intent behind why a boss is placed where it is, why a wall thickness was chosen, why a given rib pattern was used — all of that is invisible in a published STEP file.

For web AI — natural language processing, image classification, code generation — public repositories are genuinely useful because the artifact being trained on (text, images, code) largely preserves its operational meaning when published. Engineering CAD data is fundamentally different. The moment you strip the native format down to a neutral export, you’ve removed most of the information that matters.

What Real Engineering Data Actually Looks Like

If you want to build a CAD AI that is genuinely useful — not just a geometry suggestion engine, but something that understands real mechanical design — you need files that have never been published anywhere.

You need SolidWorks SLDASM files with full part trees intact. You need Creo assemblies with relation-driven constraints and family tables. You need engineering drawings with GD&T callouts, tolerance chains, and revision blocks. You need the ECO log — the change history — that shows not just what a part looks like now but what it looked like across six design iterations and why each change was made.

You need the DFM markups from the factory. The injection mold trial reports. The first article inspection failures and the design changes that followed. The supplier feedback on why a particular undercut couldn’t be tooled at target cost. The firmware constraint that forced a PCB layout revision in the third EVT run.

None of that exists in any public repository. None of it ever will. It lives in company PDM systems, in engineering drives, in scattered email threads, in the heads of experienced engineers who have done this twenty times and know immediately when a design is going to cause problems in production — even if they couldn’t always articulate exactly why.

This is the real data problem. It is not a technical problem. It is a trust problem, a relationship problem, and a structural problem rooted in how engineering organizations actually work.

Why Engineering Workflows Are Highly Fragmented

I’ve been in Shenzhen factories and supply chains long enough to understand how engineering data moves — or doesn’t move — through the ecosystem. And one thing that consistently surprises people outside of hardware is how fragmented and informal that data environment actually is.

Consumer electronics engineering in Shenzhen is largely a Creo/ProE world at the experienced-engineer level. Not SolidWorks. Creo. The reasons are historical and practical — many senior mechanical engineers in the Pearl River Delta were trained on ProE during the manufacturing expansion of the 2000s, and that habit has persisted. SolidWorks is more common in automation equipment, tooling and fixture design, and in European and North American-influenced engineering teams.

This matters for AI CAD data sourcing because it means the engineering knowledge is not concentrated in one software ecosystem. A startup trying to build a unified training dataset immediately faces a fragmentation problem: SolidWorks files and Creo files are not interoperable at the feature-tree level. The assembly logic, the parametric structure, the constraint system — all different. Training a model on one doesn’t transfer cleanly to the other.

Beyond software fragmentation, there’s organizational fragmentation. In Shenzhen, engineering work is distributed across dozens of specialized service providers — structural engineers, PCB layout houses, mold design shops, jig and fixture suppliers. Large ODMs have internal teams. Smaller manufacturers outsource aggressively. Design ownership is often unclear. Files move through WeChat, through USB drives, through shared drives with no version control. I’ve seen product development projects where the “master” design file existed in four different versions across three different companies’ servers simultaneously.

For an AI company trying to build a training pipeline on this, the idea of clean, standardized, metadata-rich engineering data flowing from a reliable source is essentially fiction.

The Trust Problem and the NDA Reality

Let’s say an AI CAD company manages to find engineering organizations willing to participate in a data sharing program. They’ve solved the identification problem. Now they face the trust problem.

Engineering files are among the most sensitive intellectual property that any manufacturing company holds. A product design file doesn’t just show you the geometry — it shows you the engineering decisions, the cost assumptions, the supplier choices, the performance tradeoffs. It shows you how a company actually makes things. For a competitive hardware business, that is genuinely sensitive information.

Almost every meaningful engineering file in any commercial organization is either explicitly covered by an NDA or implicitly protected by common-sense confidentiality. When an engineer at a Shenzhen ODM says “I can’t share our customers’ design files” — that’s not being obstructive. That is the correct answer. The moment they share those files without authorization, they’re exposing their employer to legal liability and their customers to competitive risk.

The NDA problem doesn’t just affect raw file sharing. It affects even the anonymized, aggregated approach. Engineering teams are sophisticated enough to understand that DFM patterns, tolerance preferences, assembly structures, and feature tree logic can potentially be reverse-engineered to identify product families. The legal teams at serious engineering companies have already thought about this. Getting sign-off to contribute even cleaned, anonymized engineering data to a third-party AI training dataset is a non-trivial legal and organizational process.

I’ve seen this dynamic play out in practice. I’ve been in conversations where an engineering director is genuinely enthusiastic about an AI tool — understands the value, wants to participate — but the legal review takes months and ultimately limits participation to a level that isn’t actually useful for training purposes.

Why Engineering Intuition Is So Hard to Capture

There is another layer to this problem that goes deeper than file access. Even if you could get clean, complete, NDA-cleared engineering data — feature trees, drawings, revision history, DFM feedback, manufacturing outcomes — you would still be missing something crucial.

Engineering intuition.

An experienced mechanical engineer at a Shenzhen mold shop looks at a part design and within minutes knows that the ejector pin placement is going to cause surface witness marks on the cosmetic face. They know this not because they ran a simulation — they know it because they’ve seen it happen eighty times. That knowledge is rarely written down anywhere. It exists as pattern recognition built from years of watching what happens between the design file and the finished part.

The same is true for assembly tolerance stack-ups in consumer electronics. An engineer who has shipped twenty wearable products knows intuitively where the critical clearances are going to cause problems in mass production, even in a design that looks clean on paper. They know because they’ve been in the factory at 2am watching the line fail and working backwards to find the root cause.

This kind of operational knowledge is extremely difficult to encode in training data. It is implicit, contextual, and deeply tied to the specific product categories and manufacturing environments where it was earned. Even if an AI could absorb millions of engineering files, it would still be missing the manufacturing feedback loop — the signal from real production that tells you which design decisions were actually right and which ones caused problems that never showed up in simulation.

Building that feedback loop into an AI training pipeline requires real partnerships with manufacturing organizations. Not one-time data exports. Ongoing relationships where production outcomes are connected back to design decisions over time. That is building relationships, not scraping data.

Why Shenzhen’s Engineering Ecosystem Matters — And Why It’s Hard to Access

From my position in Shenzhen, I have a particular view of why the engineering data problem is especially acute in consumer electronics — which is one of the highest-value domains for AI CAD applications.

The Pearl River Delta has accumulated an extraordinary density of manufacturing and engineering knowledge over thirty years of building the world’s consumer hardware. Shenzhen engineers have worked on smartphones, wearables, earphones, smart home devices, medical hardware, industrial edge devices, toys, audio products — the product scope is enormous. The manufacturing tacit knowledge embedded in this ecosystem is genuinely irreplaceable.

But that knowledge is trapped in exactly the structures I described: fragmented organizations, informal communication channels, NDAs, competitive sensitivity, and a cultural default toward operational secrecy. Shenzhen’s engineering ecosystem does not have a culture of open data sharing. It has a culture of competitive advantage through execution capability. The knowledge stays close.

For AI companies trying to build manufacturing-aware CAD intelligence, Shenzhen is simultaneously the most important data environment in the world and one of the hardest to access. The engineers who understand injection molding tolerance realities, plastic material behavior under thermal cycling, antenna placement constraints in metal enclosures, battery swelling margins in compact wearable assemblies — those engineers are here. Getting their knowledge into a training dataset requires the kind of trust-building that takes years, not months.

Operational Workflow Infrastructure as the Real Moat

Here’s what I think this means for the AI CAD space over the next several years.

Model architecture will not be the differentiator. The fundamental transformer-based approaches to understanding parametric structure and geometry are not deeply proprietary. Any well-funded team with good engineers can build a capable model architecture given enough time.

The moat will be operational workflow infrastructure. Meaning: the actual partnerships, integrations, and trust relationships that give an AI company sustained access to real engineering data at production quality.

The companies that will win in AI CAD are not necessarily the ones with the most sophisticated models. They are the ones that figure out how to embed themselves into real engineering workflows — at the PDM level, at the factory feedback level, at the supplier communication level — in a way that continuously generates high-quality training signal and creates switching costs for the engineering organizations they serve.

This is less like building a typical AI product and more like building an enterprise software business with deep industry integration requirements. The sales cycle is longer. The trust-building is slower. The data access has to be earned through demonstrated value, not extracted through clever engineering.

Some AI CAD companies are starting to understand this. The ones that are building PDM plugins, factory integration tools, and supplier feedback systems — rather than just standalone design suggestion interfaces — are building toward the right architecture. Whether they can execute at the relationship and trust level required is a separate question.

What This Means If You’re Building Engineering AI

If you are working on AI CAD or manufacturing AI and trying to figure out your data strategy, here are the operational realities I would keep in mind:

• Public repositories are geometry data, not engineering data. They are useful for shape recognition and basic feature detection. They are not useful for understanding engineering intent, manufacturing feasibility, or design decision logic.
• Feature trees, assembly constraints, and revision histories are the real signal. If your training data doesn’t include these in native format, you’re training on shadows of engineering knowledge, not the thing itself.
• NDA and IP sensitivity is not an obstacle — it is the central structural reality. Your data strategy has to be built around earning trust and creating legitimate, legally clear sharing structures. This takes time.
• Manufacturing feedback loops are essential for production-relevant intelligence. CAD data without production outcome data produces AI that understands geometry but not manufacturability. The feedback loop is not optional.
• Shenzhen is a critical data environment that requires relationship access, not remote scraping. If your consumer electronics AI doesn’t have real Shenzhen supply chain and factory data in its training pipeline, you will have significant blind spots in the product categories that matter most.
• Engineering intuition cannot be captured purely through file analysis. Some form of expert annotation, engineering review, or structured knowledge extraction from experienced practitioners is going to be necessary for high-quality training signal.

Final Thoughts

I’ve watched a lot of hardware technology waves move through Shenzhen over fifteen years. Some of them lived up to the hype. Many didn’t — not because the technology was wrong, but because the execution reality was harder than the pitch suggested.

AI-assisted engineering has genuine potential. I believe that. The right AI tools, built on real engineering data, could meaningfully reduce the friction between design intent and manufacturable product — which is a problem I deal with directly on projects every year.

But the honest assessment is this: the bottleneck is not model architecture. The bottleneck is data. And the data problem in engineering AI is not a technical problem — it is a relationship problem, a trust problem, and an operational integration problem that requires years of patient ecosystem-building to solve properly.

The next generation of engineering AI may depend less on who has the best model — and more on who has the deepest access to real engineering workflows.

That access cannot be downloaded. It has to be earned.

I Work FOR YOU, Not Factories. My role is to stand on your side of the table — understanding the manufacturing ecosystem from the inside, and helping overseas teams navigate it without losing control of their product.

Need China-Side Hardware Execution Support?

If you’re building a hardware product and need someone who understands the manufacturing execution side — supplier evaluation, DFM coordination, EVT/DVT/PVT support, production oversight — this is the kind of work I help with from Shenzhen.

Not a factory broker. Not a sourcing agent. A China-side operator who works for your team’s product goals.

Feel free to reach out directly:

Email: [email protected]

Website: www.easelinktech.com