Text-to-CAD for 3D printing: what works and what breaks

Last Tuesday I printed a bracket that Zoo.dev generated from a one-line prompt. Peeled it off the build plate, held it up to the thing it was supposed to hold, and it fit. Not perfectly, there was about a millimeter of play on the mounting holes, but it fit. I stood there for a second feeling like the future had arrived. Then I printed the second part, an enclosure with a snap lid, and the overhang collapsed into spaghetti because the AI put a 70-degree unsupported ceiling in the middle of the box. Back to the present.

That's been my experience with text-to-CAD for 3D printing in a nutshell. The simple stuff works surprisingly well. The slightly less simple stuff fails in ways that suggest the AI has never watched a print fail, which of course it hasn't. It's generating geometry from training data, not from bitter experience with a clogged nozzle at 2 AM.

I've been 3D printing parts for over a decade, starting with a janky RepRap I built from eBay parts and ending up with a Bambu Lab that makes me feel like I wasted years on calibration. And I've been testing text-to-CAD tools for months. This is what I know about the intersection: where the geometry prints cleanly, where it fails, and what you need to fix before you hit slice.

The parts that actually print#

Simple prismatic geometry is the sweet spot. Boxes. Brackets. Plates with holes. Standoffs. If the part is basically a collection of extrusions and cuts with some fillets, text-to-CAD tools can generate something printable more often than not.

I keep a running list of test parts I've printed from AI-generated geometry. The success rate for simple parts, things like L-brackets with two mounting holes, or rectangular trays with a uniform wall, is around 70-80%. Meaning the STL comes off the tool, goes into PrusaSlicer or Bambu Studio, slices without warnings, and prints into an object that roughly matches the prompt. Not always dimensionally perfect, but physically real and vaguely functional.

The reason this works is because 3D printing, especially FDM, is forgiving. A wall that's 1.8mm instead of 2mm will still print. A hole that's 5.7mm instead of 6mm will still exist, even if your M6 bolt complains about it. The process doesn't care about sharp internal corners the way a CNC cutter does. It doesn't need draft angles. It doesn't need the geometry to be anything more than a watertight solid, and text-to-CAD tools are generally good at producing watertight output.

Zoo.dev in particular exports clean STL files that slice without repair in every slicer I've tested. That's not nothing. I've gotten STL files from human CAD users that needed mesh repair before printing, so the AI is at least clearing that bar.

Wall thickness: the first thing to check#

Every text-to-CAD tool I've tested gets wall thickness wrong at least some of the time. Not catastrophically wrong, usually. But wrong enough that you need to check before you print.

The problem shows up most often on enclosures and housing-type parts. I asked Zoo.dev for a rectangular electronics enclosure, 80 by 50 by 30mm, and got walls that varied between 1.2mm and 2.4mm depending on which face you measured. The prompt didn't specify wall thickness, so the AI guessed. Its guess was inconsistent and, on the thin side, below the minimum for reliable FDM printing with a 0.4mm nozzle.

This matters because thin walls cause problems. Below about 1.2mm on most FDM setups, you get underextrusion, gaps, and weak spots. Above 3mm, you start wasting material and print time. The sweet spot for FDM is usually 1.6 to 2.4mm for functional prints, and text-to-CAD tools don't seem to know that.

The fix is easy in theory: specify wall thickness in your prompt. "Rectangular enclosure, 80x50x30mm, 2mm wall thickness" gives better results than "rectangular enclosure." But even with specific prompts, I've seen the AI produce walls that don't match the requested thickness. My rule is always measure the wall in the STEP file before exporting STL. It takes thirty seconds and saves a failed print.

Overhangs and supports: the AI doesn't think about gravity#

This is the big one. Text-to-CAD tools generate geometry in a zero-gravity viewport where everything floats and nothing sags. They have no concept of build orientation, layer-by-layer deposition, or what happens when you try to print a 60-degree overhang without support.

I tested this with a simple request: a shelf bracket with a diagonal brace. The AI generated a perfectly reasonable-looking bracket with a clean 45-degree strut connecting the horizontal arm to the vertical plate. In principle, 45 degrees is right on the edge of what FDM can do without supports. In practice, the AI also added a small horizontal tab on the underside of the strut that turned a maybe-printable overhang into a definitely-needs-support overhang. The tab was about 5mm wide and entirely unsupported. Classic case of geometry that makes sense structurally but ignores the printing process entirely.

Most of the AI-generated parts I've printed needed support material removed. That's not unusual for FDM printing generally, but the issue is that text-to-CAD tools don't optimize for minimal support. A human designer who knows the part will be printed tends to round the underside of overhangs, add chamfers instead of flat shelves, orient features to be self-supporting. The AI does none of this because it doesn't know the part will be printed. It's generating shapes, not print-ready geometry.

For simple parts, this is manageable. You slice the model, add supports in the slicer, and deal with the cleanup. For complex parts with internal overhangs or enclosed cavities, it can make the part unprintable without redesign. I had one AI-generated part with an internal shelf that would have required support material inside a box with no way to remove it. A human would never design that for FDM. The AI did it without hesitation.

Dimensional accuracy: close enough for prototyping#

I measured forty-something AI-generated parts after printing, comparing the printed dimensions to what the prompt requested. On simple features like overall length, width, and height, the AI-to-STL dimensional error averaged about 2-3%, and the print process added another 0.2-0.5mm of dimensional variation depending on the material and printer. So a 50mm dimension typically ended up somewhere between 48mm and 51mm as a printed part.

For prototyping, this is usually fine. You're checking form, fit, and basic function. You're not machining bearing bores. The cumulative error from AI geometry plus FDM printing tolerance is rarely more than a millimeter on features under 100mm, and that's within the range where you can evaluate a design concept and decide what to fix in the next iteration.

For production printing, where you need parts to mate with specific hardware, mount in specific locations, or clear specific keep-out zones, the dimensional drift matters. A 6mm hole that prints at 5.6mm doesn't fit the M6 bolt. A 20mm standoff that ends up at 19.4mm leaves a gap in the assembly. These aren't failures of the printing process. They're the compounding of AI dimensional approximation plus print shrinkage plus process tolerance, and the result is parts that need post-processing or reprinting.

My workflow for anything dimensionally critical: generate the shape with text-to-CAD, import STEP into Fusion 360, measure and correct the critical dimensions, add the tolerances I need, and then export STL from Fusion. The AI saves me the initial modeling time. The measurement-and-fix step is non-negotiable.

STL export: mostly fine, occasionally cursed#

The good news is that text-to-CAD tools generally output clean STL files. Zoo.dev's STL exports have been consistently watertight in my testing. I run every file through the slicer's analysis tool, and the vast majority pass without mesh errors, non-manifold edges, or inverted normals.

The bad news is that resolution can be an issue. Some tools export STL with a triangle density that's either too low (visible faceting on curved surfaces) or too high (50MB files for a simple bracket). Zoo.dev lets you control the mesh density through the API, which helps. Other tools give you what they give you.

For FDM printing, this rarely matters. The layer height masks most faceting. For SLA printing, where surface quality is visible at the layer level, a low-resolution STL mesh can show up as visible flat spots on curved surfaces. I've had a couple of prints where the triangulation was coarse enough to see facets on what should have been a smooth fillet. The fix is to export at higher resolution from the source, or to re-export from a proper CAD tool after importing the STEP file.

SLA and SLS: less forgiving, less tested#

Most of my text-to-CAD printing tests have been FDM because that's what most people use and that's where the forgiveness is highest. But I've printed a few AI-generated parts on SLA and SLS, and the story is different.

SLA (resin) printing is more accurate than FDM but less tolerant of certain geometry problems. Thin sections that hold up on FDM can fail on SLA because the suction forces during peel are higher on large flat areas. Internal cavities need drain holes or you trap uncured resin. The AI doesn't add drain holes because it doesn't know the part is being resin-printed.

I printed a small AI-generated housing on my resin printer and it looked great until I realized the AI had created a nearly enclosed box with no drain path. I caught it before printing by checking the model in Chitubox, but a less careful user would have ended up with a part full of trapped liquid resin. That's the kind of process-specific knowledge that text-to-CAD tools completely lack.

SLS is even more specialized. The powder bed is more forgiving about overhangs, but wall thickness minimums are stricter for nylon, and the mechanical properties depend heavily on feature orientation relative to the build. None of this is encoded in AI-generated geometry.

What to actually check before you print#

After months of testing, I've developed a checklist for AI-generated parts going to the printer:

• Open the STEP file in Fusion 360 or your preferred tool. Don't trust the STL preview alone.
• Measure wall thickness on every face. Flag anything below 1.2mm for FDM or 0.6mm for SLA.
• Look for unsupported overhangs above 45 degrees. Decide if you can add supports or if the geometry needs redesign.
• Check for enclosed cavities. Add drain holes for SLA. Add support access for FDM if needed.
• Measure critical dimensions against your prompt. Correct anything that's off.
• Verify hole diameters. AI-generated holes are consistently undersized in my testing, by about 0.2 to 0.5mm.
• Check the STL in your slicer for mesh errors. Run a repair if needed (though this is rarely necessary with Zoo.dev output).
• Think about orientation. The AI doesn't know which way is up on the build plate. You might need to rotate the model for better printability.

This list sounds like a lot of work, and it is compared to just hitting "slice and print." But it's less work than modeling from scratch, and it's a lot less work than fixing a failed print. The checking takes maybe five minutes. The printing takes hours. Spending those five minutes is the difference between text-to-CAD being useful and text-to-CAD being a waste of filament.

FDM materials: the AI doesn't care, but you should#

Text-to-CAD tools generate geometry without material awareness. The output is the same whether you're printing in PLA, PETG, ABS, nylon, or TPU. This seems obvious, but it matters because material choice affects what geometry is printable.

ABS warps on large flat surfaces, so an AI-generated part with a big flat base might curl off the bed. TPU is flexible, so thin walls that hold up in PLA will flex and deform. Nylon absorbs moisture and has different bridging characteristics. PETG strings more, which means small details and holes might need different post-processing.

None of this is the AI's fault, exactly. A human modeling a part for 3D printing doesn't usually embed material properties in the geometry either. But a human who knows the part will be printed in ABS adds mouse ears to the corners or uses a brim. A human who knows it's TPU thickens the walls. The AI produces one shape for all materials, and the user has to adapt.

For PLA prototyping, which is where most text-to-CAD output ends up, this mostly doesn't matter. PLA is forgiving. It prints at low temperatures, doesn't warp much, bridges reasonably, and tolerates imperfect geometry with a shrug. That's why the "text-to-CAD for 3D printing" story is really a "text-to-CAD for PLA prototyping" story. The further you move from PLA on a desktop FDM printer, the more the AI's lack of process awareness becomes a problem.

The comparison nobody wants to make#

Here's the thing. If you already know how to model in Fusion 360, SolidWorks, or even OnShape, text-to-CAD for 3D printing doesn't save you much time on individual parts. I can sketch, extrude, and fillet a simple bracket in Fusion faster than I can write a good prompt, wait for generation, download the STEP, import it, check the dimensions, fix the walls, and re-export.

Where it saves time is when you need lots of variations quickly. Five different bracket shapes. Three enclosure options. A stack of standoffs with different heights. Generating those with text prompts is faster than modeling each from scratch, even if each one needs a five-minute checkup in Fusion afterward.

It also saves time if you don't know CAD at all. And that, honestly, might be the bigger story. A hardware tinkerer who needs a mount for a Raspberry Pi and a sensor board can describe it in English, get an STL, and print it. The dimensions might be off by a millimeter. The walls might need a little thickening. But the part exists, and it didn't require learning sketch constraints or feature trees. For the maker community, that's a real shift.

Where it actually fits#

Text-to-CAD for 3D printing works best when your expectations match the technology's actual capabilities. It's a first-draft generator for printable geometry. Not a print-optimization tool. Not a slicer replacement. Not a substitute for understanding your printer and material.

Use it for rapid prototyping where speed matters more than precision. Use it for concept models you'll iterate on. Use it to get a shape on the build plate fast, evaluate it in your hand, and then decide whether to refine it in real CAD or prompt another version.

Don't use it for production prints where dimensional accuracy matters. Don't trust the wall thickness without checking. Don't assume it's thought about overhangs, because it hasn't. Don't print the first output blindly. Look at it in a slicer first.

The gap between "geometry that exists" and "geometry that prints well" is real, and in 2026, the AI is responsible for the first part and you're responsible for the second. That's not a damning verdict. It's an honest one. For quick FDM prototypes of simple parts, text-to-CAD is faster than starting from scratch and good enough to learn from. For anything beyond that, keep your real CAD tools warm. The printer doesn't care who modeled the part. It only cares whether the geometry makes sense, and right now, that judgment is still yours.