Text-to-CAD limitations: what nobody tells you

I was trying to explain text-to-CAD to a machinist I work with. Showed him a bracket Zoo.dev generated from a single sentence. He was impressed for about four seconds, the time it took him to rotate the model and notice the internal corner radii were zero. "So it doesn't know cutters exist," he said, and went back to his coffee. That's the whole problem in one sentence, from a guy who's been making parts longer than most of these AI companies have existed.

Text-to-CAD tools are genuinely useful for simple geometry. I've said that before and I mean it. But there's a growing gap between what the marketing implies these tools can do and what they actually deliver when you try to use the output for anything beyond a viewport screenshot or a quick 3D print. I've spent months testing this stuff, and here's the full list of what breaks, what's missing, and what nobody mentions in the demo.

No assemblies#

This is the one that surprises people most. Current text-to-CAD tools generate single parts. You can describe an enclosure. You can't describe an enclosure with a lid that snaps onto it, a PCB mount inside, a cable gland in the side, and a gasket groove in the rim. You can't describe an assembly of parts that need to fit together with defined relationships.

This matters because most real CAD work is assembly work. A bracket exists in context: it mounts to something, holds something, and clears something else. The dimensions of the bracket depend on the dimensions of the things around it. Without assembly context, a text-to-CAD bracket is a freestanding object that might or might not fit where you need it.

I tried working around this by generating individual parts and assembling them in Fusion 360. It went about as well as you'd expect. The hole patterns didn't line up. The mating surfaces weren't coplanar. One part was 2mm thicker than the other assumed it would be. I spent more time fixing the alignment than I would have spent modeling both parts from scratch with proper assembly constraints.

No tolerances or GD&T#

Text-to-CAD tools produce nominal geometry. There are no tolerances. No dimensional tolerances, no geometric tolerances, no surface finish callouts, no fit specifications. The model has dimensions, but those dimensions carry no engineering intent about precision.

This sounds abstract until you try to manufacture something. A 10mm hole is not useful information for a machine shop. A 10mm hole with H7 tolerance tells them exactly what diameter to cut and what surface finish to achieve. A 10mm hole with no tolerance annotation tells them to guess, call you, or apply their house standard, which may not be what you need.

I've never seen a text-to-CAD tool output a model with any tolerance information. Not once. And until they do, every output requires a human to add the engineering data before it's production-ready. The accuracy question is related but separate: even the nominal dimensions aren't always reliable, which makes the tolerance gap even worse.

Poor complex surfaces#

Flat faces, cylinders, simple fillets. That's roughly the surface vocabulary of current text-to-CAD tools. Ask for a NURBS surface that transitions smoothly between two different cross-sections, or a lofted shape with guide curves, or an organic surface with curvature continuity, and you'll get something that either doesn't work or approximates the surface with faceted geometry that looks smooth from a distance and terrible up close.

I asked Zoo.dev to generate an ergonomic handle. The result looked like a handle in the same way that a balloon animal looks like a dog. The cross-sections didn't flow. The transitions were abrupt. The surface quality was nowhere near what you'd need for an injection-molded grip. For a concept visualization, fine. For tooling, not remotely.

Complex surfaces are hard in manual CAD too. I'm not pretending they're easy. But the AI doesn't have the surfacing vocabulary to handle them, and the training data seems to skew heavily toward prismatic mechanical parts. If your work involves consumer products, ergonomics, or anything with curvature requirements, text-to-CAD isn't in the conversation yet.

Limited to simple prismatic geometry#

The sweet spot for text-to-CAD is boxes, brackets, plates, simple enclosures, and standoffs. Basically, the kind of geometry you'd create with sketch-extrude-cut-fillet operations. Once you step outside that vocabulary, the results degrade quickly.

Gears are a good example. I asked for a spur gear with specific module, tooth count, and bore diameter. What came back had the right number of teeth (sometimes) but the tooth profile was decorative, not involute. The root radius was wrong. The bore was close but not dimensioned to a standard fit. A gear that doesn't mesh with another gear isn't a gear. It's a decoration.

Springs, cams, helical features, threads, knurling, splines. All of these require specialized knowledge that the current training data doesn't capture well. The AI has seen thousands of brackets in the training set and very few cams. The output quality reflects that distribution.

No DFM awareness#

Design for manufacturability is not a feature you bolt onto a model after the shape exists. It's a set of constraints that inform the shape from the beginning. Wall thickness for injection molding. Draft angles for mold release. Tool access for CNC machining. Bend radii for sheet metal. Relief cuts for bending. Gate locations. Parting lines. Ejection strategies.

Text-to-CAD tools know none of this. They generate shapes that exist in a manufacturing vacuum. The bracket with zero-radius internal corners that my machinist spotted is typical, not exceptional. The AI doesn't know that a 3-axis CNC can't cut a sharp internal corner. It doesn't know that a 0.5mm wall will chatter and deflect during machining. It doesn't know that vertical faces on an injection-molded part need 1 to 3 degrees of draft or the part won't release from the mold.

This matters more than people realize because DFM violations are expensive. A part that looks fine on screen but can't be manufactured without a secondary operation, a more expensive process, or a complete redesign is not a time-saving. It's a time bomb. I covered this in more detail when I tested AI-generated parts for real manufacturing, and the results were not pretty.

Inconsistent dimensional accuracy#

When I say inconsistent, I don't mean "always wrong by the same amount." I mean sometimes the dimensions are close, sometimes they're off by a millimeter, sometimes they're off by five percent, and you can't predict which outcome you'll get. The same prompt on the same tool can produce different dimensions on different days. Consistency is the problem, not just accuracy.

I tested a specific prompt ten times on one tool. Asked for a plate that was 80mm by 50mm by 5mm. Eight of the ten results were within 0.5mm on all dimensions. One was off by 1.2mm on the width. One was off by 2mm on the thickness, which is a 40% error on a 5mm dimension. There's no warning. The model looks fine in the viewport. You only find out when you measure it, which I do with the STEP file in Fusion 360 before I'd ever send anything to manufacturing.

For prototyping and concept work, this inconsistency is tolerable. For production, it's disqualifying. You can't build a manufacturing process on output that might be accurate. It needs to be accurate every time, or the checking time eats the time savings.

No sheet metal support#

Sheet metal in CAD is its own discipline. A proper sheet metal part has bend features, not folded solid bodies. It has K-factors that determine the developed length based on material type and thickness. It has bend relief cuts to prevent tearing. It has a flat pattern that unfolds correctly for laser cutting or punching. The relationship between the 3D folded part and the 2D flat pattern is mathematical, driven by real material properties.

Text-to-CAD gives you a shape that looks like folded metal. It is not sheet metal. There are no bend features. No K-factor. No flat pattern. The geometry is a solid body that happens to resemble something you could bend from sheet, but try to unfold it and you'll get nothing, because the model was never designed with bending in mind.

For anyone who works with sheet metal regularly, this is a dead end. You'd spend more time converting the output into proper sheet metal features than you'd save by generating the shape in the first place.

No injection molding features#

I touched on this above with DFM, but injection molding deserves its own callout because it's such a common manufacturing process and so completely unsupported by text-to-CAD tools.

A good injection-molded part design accounts for draft angles, uniform wall thickness, gate location, weld line control, sink mark prevention, undercuts and side actions, and mold release. The part geometry is shaped by the process as much as by the function.

Text-to-CAD generates geometry that ignores all of this. The walls vary in thickness. The faces have no draft. Snap fits and ribs are designed without regard for ejection. A tooling engineer I showed some AI-generated enclosure designs to said they'd each need a complete redesign before quoting. Not adjustments. Redesigns. That's not a time saving. That's a liability.

No engineering constraints#

In real parametric CAD, constraints are the skeleton of the model. A hole is concentric with a boss. A bolt pattern is symmetric about an axis. A wall thickness is linked to the overall width by a ratio. These relationships mean the model can adapt when requirements change. Move the mounting surface and the holes follow. Change the material thickness and the bend radii update.

Text-to-CAD geometry has no constraints. Features exist at specific coordinates, but there's no encoded reason why. Move one hole and nothing else adjusts. The AI generated the positions based on the prompt and the training data, not based on engineering relationships. The result is geometry that's fragile to any change.

This is why I keep saying text-to-CAD output is a starting point, not a finished model. You import it, measure it, and then rebuild it with proper constraints in your real CAD tool. The text-to-CAD guide describes the workflow I actually use, and it always involves significant manual rework. The AI gets you a shape. You turn it into a model.

The feature tree gap#

Related to the constraint problem: most text-to-CAD output has no usable feature tree. Zoo.dev gives you a STEP file that imports as a dumb solid. No history, no features, no timeline you can roll back. CADAgent, which works inside Fusion 360, does generate a feature tree, but it's usually structured in ways that are fragile and hard to modify.

A good feature tree captures design intent. It lets you change one dimension and have the rest of the model update logically. A text-to-CAD output captures shape, period. For a one-off part that never changes, this is fine. For anything that lives in a project with revisions, it means rebuilding.

What actually works despite all this#

After listing everything that doesn't work, I should be honest about what does. Because something does.

Simple parts for quick evaluation. Concept geometry for design reviews. First drafts of brackets, plates, and enclosures that you plan to refine in traditional CAD. Quick STL files for test prints where dimensional precision isn't critical. Starting shapes for design exploration when you want to react to geometry rather than imagine it.

For all of those, text-to-CAD saves time. Not manufacturing time. Not engineering time. Sketching time. And that's worth something, especially early in a project when the cost of being approximate is low.

The honest assessment#

Text-to-CAD limitations aren't temporary inconveniences that the next software update will fix. Some of them, like tolerance handling and DFM awareness, require fundamental changes to how these models are trained and what data they're trained on. Others, like assembly support and complex surfaces, are hard AI problems that the research community is working on but hasn't solved commercially.

If you understand the limitations, you can use the tools productively within their actual capabilities. If you don't, you'll generate geometry that looks like a part on screen and turns into a problem the moment it meets material, tooling, or an inspector with calipers.

I use text-to-CAD. I know what it can't do. That knowledge is what makes it useful instead of dangerous. The tools will get better. But right now, the list of what they can't do is longer than the list of what they can, and anyone telling you otherwise is selling something.