Text-to-CAD for aerospace: why it's not ready yet

Text-to-CAD is not ready for aerospace, and it won't be for a long time. I can say that with confidence because I spent a week trying to use AI-generated geometry in a stress analysis workflow, and the result was the kind of quiet failure where everything looks plausible until you open the FEA results and realize nothing about the part was designed with load paths in mind. The bracket looked like a bracket. The mounting features were in roughly the right places. But the geometry was just shapes arranged in space, with no awareness that this particular arrangement of shapes was supposed to keep something attached to an airframe at 30,000 feet.

I should admit upfront that I'm not an aerospace engineer. My background is product design. But I've done enough contract work adjacent to aerospace, fixtures, ground support equipment, test jigs, that I've sat through AS9100 audits, argued about documentation requirements, and watched the look on a quality engineer's face when someone suggests skipping the design history file. Aerospace is a different animal. The rules are not optional, the tolerances are not suggestions, and the documentation exists because people's lives depend on it.

Why aerospace is fundamentally different#

In general mechanical design, if a bracket is 0.5mm thicker than it needs to be, nobody cares. You added material. The part is heavier and slightly more expensive. That's usually the end of it.

In aerospace, extra weight is a cost driver measured in fuel burn over the life of the aircraft. A bracket that's 0.5mm thicker than the stress analysis says it needs to be is not a safety margin, it's a weight penalty that someone has to justify, document, and get signed off. And a bracket that's 0.5mm thinner than it needs to be is a potential fatigue failure that could ground a fleet.

Every dimension on an aerospace part exists for a reason that's traceable to a requirement. The material choice is traceable to a specification. The heat treatment is traceable to a process document. The surface finish is traceable to a fatigue analysis. The inspection criteria are traceable to the design intent. This traceability chain is not a nice-to-have. It's the core of AS9100 and the regulatory frameworks (FAA, EASA) that govern flight hardware.

Text-to-CAD tools generate geometry from a text prompt. That geometry has no traceability to anything. No requirements document. No stress analysis. No material specification beyond what the prompt mentioned in passing. No design rationale. No revision history that shows why a fillet radius changed from 3mm to 5mm between rev B and rev C. The limitations of text-to-CAD that affect all industries become disqualifying in aerospace because the documentation requirements aren't bureaucratic overhead. They're the mechanism that keeps aircraft in the air.

What happens when you run FEA on AI-generated geometry#

I tried this, because I was curious and slightly masochistic. I prompted Zoo.dev to generate a mounting bracket with specific dimensions and hole patterns, something that might serve as a structural element in a non-primary load path. Exported the STEP file. Imported it into Fusion 360. Set up a simple static stress analysis with fixed supports at the bolt holes and a load on the mounting face.

The analysis ran. Results came back. And here's where the education happened.

The stress concentrations were in places that made no engineering sense for the intended load case. The fillet radii were inconsistent: some transitions had generous radii, others had near-sharp corners, and there was no logic to which got which. The AI had distributed material based on what brackets in its training data looked like, not based on where the stress actually flows. One section had plenty of material where the stress was near zero, and another section was undersized right where the peak stress occurred.

This is not a cosmetic problem. In aerospace structural analysis, the geometry and the FEA are supposed to evolve together. You run the analysis, identify the stress concentrations, modify the geometry to reduce them, run again, iterate. The part shape is driven by the physics. Text-to-CAD reverses this: the shape is driven by training data, and the physics is whatever happens when you test the shape you got. That's not design. That's hope.

A stress engineer I've worked with on fixture designs put it plainly: "I can't sign off on geometry that doesn't have a rationale. If I can't explain why the wall is 3mm thick instead of 2.5mm, I can't certify the analysis." In aerospace, the ability to explain every design decision is not optional. AI CAD for real work already struggles with manufacturing realities. Aerospace adds the requirement that every geometric choice be justified, documented, and traceable.

The documentation gap#

Here's where the conversation gets uncomfortable for anyone excited about AI in aerospace design.

A typical aerospace part has a design history file that includes: the requirements it was designed to meet, the loads and environmental conditions it's designed for, the material specification and the reason for the material choice, the stress analysis showing the part meets the load requirements with appropriate factors of safety, the drawing with GD&T callouts traceable to the functional requirements, the inspection plan, and the test data if the part was qualified by test.

Text-to-CAD generates a 3D model with none of that. Not "some of it missing." None of it. The geometry arrives as a dumb solid body in a STEP file. No feature tree with design intent. No parameters linked to requirements. No inspection callouts. No surface finish specifications. No material specification beyond whatever the user typed in the prompt. No traceability to loads, no link to an analysis, no documentation of design decisions.

For a prototype jig that never sees flight loads, this is fine. For flight hardware, this is a non-starter. Not because the geometry is necessarily wrong (though it might be), but because there's no evidence that it's right. In aerospace, "it looks fine" is not an acceptable basis for certification. The text-to-CAD guide describes realistic workflows for these tools, and none of them include "put the output on an airplane."

Material and fatigue: what the AI doesn't know#

Aerospace design is deeply material-specific. An aluminum 7075-T6 bracket is designed differently from a titanium Ti-6Al-4V bracket, not just because the allowable stresses are different, but because the fatigue behavior, corrosion susceptibility, machinability, and damage tolerance characteristics are different. The material drives the geometry in ways that text-to-CAD tools have no framework to understand.

Fatigue is the big one. Most aerospace structural failures are fatigue failures, not static overloads. A part that passes a static stress check can still fail after 10,000 flight cycles if the stress concentrations are in the wrong places, the surface finish is too rough, the grain direction of the material is wrong, or the residual stresses from manufacturing weren't accounted for.

Text-to-CAD generates geometry with no awareness that fatigue exists. The fillet radii it chooses are cosmetic, not stress-driven. The transitions between features are whatever the training data suggests, not what the S-N curve for the material requires. The surface finish implied by the smooth viewport rendering bears no relationship to the surface finish achievable by the manufacturing process or required by the fatigue life target.

I once watched a fatigue specialist spend forty-five minutes explaining to a junior engineer why a particular fillet radius had to be exactly 5mm and not 4mm. The explanation involved S-N data, stress concentration factors, a safety factor chain, and a service life calculation that traced back to the aircraft's inspection interval. That single radius captured more engineering knowledge than a text-to-CAD prompt could express in a page of text.

Where AI might eventually help in aerospace#

I'm not saying AI has no future in aerospace. I'm saying its current form, generating geometry from text prompts, is the wrong tool for the job as aerospace currently defines the job. But there are spaces where AI-assisted CAD could be useful if the expectations are calibrated correctly.

Non-critical ground support equipment. Test fixtures, handling tools, protective covers, storage racks. These parts don't fly. They're often designed to general engineering standards rather than aerospace-specific requirements. The documentation burden is lighter. The tolerance requirements are looser. A text-to-CAD bracket for a ground handling cart is a different conversation from a text-to-CAD bracket for a wing rib.

Early concept geometry for trade studies. If you need to quickly evaluate three different bracket configurations for weight and envelope before committing to a detailed design, AI-generated starting geometry could save time in the concept phase. The key is that nobody should confuse concept geometry with design geometry. The concept gets you to a conversation. The design gets you to a part.

Tooling and jig design, where the tooling doesn't affect part quality and the failure mode is "we make a new jig," not "the aircraft has a problem." I've used text-to-CAD output as starting geometry for simple fixtures, imported into Fusion 360, rebuilt with proper constraints, and used for non-flight purposes. It saved some sketching time. It didn't save any engineering time.

Automation of documentation templates and drawing formatting. This isn't geometry generation, but it's where AI might help aerospace workflows: automating the boring parts of the documentation process rather than trying to automate the engineering judgment that the documentation captures.

The certification wall#

The fundamental problem with text-to-CAD in aerospace is the certification wall. Every piece of flight hardware needs to be shown to meet its requirements through a combination of analysis, test, or similarity to previously qualified hardware. All three paths require documentation that traces the part geometry back to the requirements.

AI-generated geometry doesn't trace back to anything. It traces back to a text prompt and a training dataset. Neither of those constitutes a design rationale in any regulatory framework I'm aware of. A Designated Engineering Representative (DER) can't sign off on a part whose design basis is "the AI thought it should look like this." That's not how certification works, and no amount of AI improvement changes the regulatory structure.

The aerospace industry moves slowly on purpose. The conservatism is annoying until you remember that it exists because the consequences of failure are catastrophic and irreversible. The industry adopted CATIA V5 over a decade after it was available. It's still transitioning from CATIA V5 to 3DEXPERIENCE, and that's software from the same vendor. The idea that aerospace will adopt AI-generated geometry for flight hardware in the near term requires ignoring everything about how the industry actually adopts technology.

The training data problem#

There's another issue that rarely comes up in the text-to-CAD hype: the training data. Current text-to-CAD models are trained on publicly available CAD datasets, things like ABC, Fusion 360 Gallery, and similar repositories. These datasets are dominated by consumer products, simple mechanical parts, and educational examples.

Aerospace geometry is almost entirely proprietary. The bracket designs, structural configurations, material-specific feature choices, and analysis-driven geometry that characterize real aerospace hardware are locked inside OEM and supplier PLM systems. They're export-controlled under ITAR or EAR. They're not in any training dataset, and they can't be without serious legal and security implications.

So even if text-to-CAD tools could handle the documentation and certification challenges, they wouldn't know what aerospace parts look like. The training data doesn't contain the kinds of parts you'd actually need to generate. You'd get consumer-product brackets with aerospace aspirations, which is roughly what I got when I tested it.

The honest assessment#

Text-to-CAD for aerospace is a mismatch between a tool designed for speed and an industry designed for certainty. Speed is nice. Certainty keeps aircraft in the sky. When those priorities conflict, certainty wins, and it should.

If you work in aerospace and someone asks you about using text-to-CAD for flight hardware, the answer is no. Not "not yet." No. The limitations aren't just about geometry quality or dimensional accuracy. They're about the absence of everything that surrounds the geometry in an aerospace design process: the analysis, the documentation, the traceability, the certification basis.

For ground support equipment, fixtures, and concept-phase geometry that will be completely redesigned before it matters? Sure, give it a try. Treat the output like a napkin sketch that happens to be 3D. Import it, rebuild it, add everything the AI left out, and do the engineering. The AI generated a shape. Your job is turning it into a part. In aerospace, the distance between those two things is measured in documentation pages, analysis reports, and sign-off authorities. That distance isn't getting shorter anytime soon.