Text-to-CAD: the working engineer's guide

The first time I asked an AI to make me a flanged bracket, it came back looking almost right. Good proportions. Mounting holes in reasonable places. Fillets that seemed intentional. I sat there with my second coffee going cold, feeling a little unsettled, like the software had read my mind. Then I opened the file in Fusion 360 and the whole illusion collapsed. No feature tree. No parametric dimensions. Just a mesh blob wearing a convincing disguise. I couldn't edit a single hole diameter without rebuilding the entire thing from scratch.

That was about a year ago, and it taught me something useful about this whole text-to-CAD space: the distance between "looks like a CAD model" and "is a CAD model" is enormous. Text-to-CAD is AI that generates real, editable CAD geometry from a text description. Not meshes. Not point clouds. Not pretty screenshots. Actual B-Rep solids with faces, edges, and feature history that you can fillet, chamfer, dimension, and hand to a machine shop without apologizing. That distinction matters more than anything else in this conversation, and most of the marketing around AI-generated 3D conveniently forgets to mention it.

I've spent months testing the tools, reading the papers, importing the outputs, and trying to make parts from the results. This is what I know so far.

What text-to-CAD actually is#

Text-to-CAD means you type a description of a part and the AI generates parametric CAD geometry. The output should be a B-Rep (Boundary Representation) solid, the same kind of geometry you'd get from sketching and extruding in SolidWorks or Fusion 360. Proper B-Rep means real faces, real edges, real topology. You can select a face, apply a fillet, measure a distance, cut a pocket, or export a STEP file that a CNC programmer won't throw back at you.

This is fundamentally different from text-to-3D, which typically outputs triangle meshes, the kind of geometry used for game assets, rendering, and visual effects. A mesh from Meshy or Tripo might look like a bracket, but try selecting one face to add a chamfer and you'll understand why mesh geometry and engineering geometry are different species. I've covered the technical distinction in more detail in the text-to-CAD vs text-to-3D comparison, but the short version is: meshes approximate shape, B-Rep defines it. Manufacturing cares about the difference even when marketing doesn't.

If you want the full concept explained from scratch, the what is text-to-CAD post covers it without assuming you already know what B-Rep means.

How the technology works under the hood#

The academic foundation for this stuff comes from a NeurIPS 2024 spotlight paper called "Text2CAD," which introduced the first end-to-end framework for generating parametric CAD models from natural language. The researchers used roughly 660,000 text annotations on the DeepCAD dataset of about 170,000 models. The architecture is a transformer-based autoregressive network: a BERT encoder processes the text prompt, and a CAD sequence decoder generates a series of modeling operations (sketch, extrude, fillet, chamfer) rather than raw coordinates.

That sequence-of-operations approach is what makes this different from image generation or mesh generation. The AI isn't predicting pixels or triangles. It's predicting CAD commands. In theory, the output is a feature tree you can roll back, edit, and rebuild, the same workflow a human CAD user would follow.

In practice, the commercial tools are still catching up to the research. Most of the available tools use some variation of this approach: take a text prompt, map it to a sequence of CAD operations, execute those operations in a geometric kernel, and output a solid. Some tools generate code (OpenSCAD scripts, Python scripts for FreeCAD, AutoLISP for AutoCAD). Others generate operations directly inside a proprietary kernel. The how text-to-CAD works post goes deeper on the architecture and the different implementation strategies, but the key thing to understand is that the quality of the output depends heavily on how well the AI learned the grammar of CAD operations, not just the shape of the result.

The tools that exist right now#

I'll be blunt: the field is early. Most of these tools are useful for specific things and terrible at others. None of them will replace a competent CAD user on a real project. Some of them can save you time on simple geometry if you know their limits. The full tool comparison covers each one in more detail, but here's an honest overview of where things stand.

Zoo.dev is the most serious dedicated text-to-CAD tool right now. It runs on a GPU-native geometric kernel called KittyCAD and outputs real B-Rep geometry in STEP, glTF, OBJ, STL, and several other formats. The API is well-documented, there's a Python SDK, and the free tier is generous enough to actually test things. I've gotten decent results for simple mechanical parts: brackets, enclosures, standoffs, basic housings. When it works, the output is a real solid you can import into Fusion 360 or SolidWorks and actually edit. When it doesn't work, you get geometry that looks plausible but has weird internal faces, missing fillets, or dimensions that suggest the AI was guessing. More on that in the accuracy section.

AdamCAD generates parametric models with adjustable dimension sliders, which is a smart approach. You get an STL plus controls to tweak dimensions after generation, starting at $5.99 a month. It's faster than Zoo for quick prototyping, but the parametric controls are limited compared to a real feature tree in SolidWorks.

CADGPT is misnamed, in my opinion, because it doesn't actually generate CAD models. It writes automation scripts: AutoLISP for AutoCAD, Python for other tools. That's a different job. Useful if you want AI-assisted scripting, but it's not text-to-CAD in the way the name implies.

CADScribe generates STL and STEP files and has been tested by Xometry and All3DP. The results are mixed on anything beyond simple geometry. For a basic box with mounting holes, fine. For anything with real constraints, fillets meeting at compound angles, shell features, or draft, you'll be rebuilding most of it.

CADAgent is the most interesting newcomer. It's an open-source Fusion 360 add-in released in March 2026 that generates models in real time inside Fusion 360 itself. You bring your own Anthropic API key. The fact that it operates inside a real parametric CAD environment means the output has actual feature history, which is what separates this from tools that generate geometry in isolation and hope for the best. I've been testing it and the results are promising for simple to moderate parts.

Vondy's AI CAD Generator outputs DXF files and is aimed at beginners. HP's AI Text to 3D is focused on their 3D printing ecosystem. Both are limited to simpler geometry.

What the big CAD vendors are doing#

The dedicated text-to-CAD startups aren't the only story. The major vendors are all bolting AI onto their existing platforms, with varying levels of ambition and varying levels of actually shipping anything.

Autodesk announced Neural CAD at AU 2025, which aims to generate editable 3D geometry from text prompts directly inside Fusion. They've also shown Text to Command ("extrude this face by 1 inch") and an Autodesk Assistant feature. As of Q1 2026, most of this is still in development or exploratory. I've seen the demos. They look good. Demos always look good. I'll judge it when I can break it in production.

Dassault Systèmes is shipping AI features in SolidWorks 2026 under the names AURA and LEO. There's an Assembly Structure Designer that takes text prompts, Design Inspection using natural language queries, and automated drawing generation. Most features are scheduled to ship by July 2026. The assembly structure approach is interesting because assemblies are where CAD workflows actually get complicated. Single-part modeling is the easy problem.

PTC's Onshape has an AI Advisor that went live in October 2025, offering real-time guidance while you model. They also have LLM-powered FeatureScript autocomplete, which is clever because FeatureScript is already a programming language, making it a natural fit for language models. Creo has generative design and an AI assistant in beta.

Siemens is building NX AI Chat and a Design Copilot for both NX and Solid Edge. The Solid Edge automated drawing feature that claims 80% of views auto-generated is genuinely useful if it holds up. Drawing creation is one of the most tedious parts of CAD work and one of the easiest to get wrong.

The AI in CAD software post tracks all of this in more detail, with specifics on what's actually shipping versus what's still a conference slide.

What text-to-CAD is good at right now#

Simple, well-described mechanical parts. That's the honest answer. If you need a rectangular enclosure with four corner mounting holes, a lid with snap fits, a basic L-bracket, or a standoff with specific thread dimensions, the current tools can often generate something usable. The key word is "well-described." Vague prompts produce vague parts. Prompt engineering for text-to-CAD is a real skill, and it matters a lot more than people realize.

The sweet spot right now is rapid prototyping and first-draft geometry. You need a quick bracket to hold a sensor? A simple enclosure to test fit? A mounting plate with a specific bolt pattern? Text-to-CAD can get you a starting point in seconds instead of minutes. You'll almost always need to edit the result, but starting from an 80% solution is faster than starting from a blank sketch.

For 3D printing specifically, the tools are more forgiving because additive manufacturing is more tolerant of imperfect geometry than machining or molding. If the mesh is watertight and the dimensions are close, you can print it and see what happens. That's not how you'd approach a CNC part, but for prototyping it's fine.

What text-to-CAD is bad at#

Complex geometry with interdependent features. Multi-body parts. Assemblies. Anything where the relationship between features matters more than the features themselves.

I asked Zoo.dev to generate a gear once. I got something that looked like a gear, in the same way a drawing of a sandwich looks like lunch. The tooth profile was decorative, not functional. The root radius was wrong. The bore was close but not dimensioned to any standard. For a render, fine. For a print that needs to mesh with another gear, useless without complete rework.

Sheet metal is another weak spot. A good sheet metal part has bend allowances, K-factors, relief cuts, and flat-pattern logic baked in. Text-to-CAD tools don't understand any of that. They'll give you a shape that looks like folded metal but won't unfold correctly because it was never designed with bending in mind.

Draft angles for injection molding. Undercuts. Thin-wall considerations. Thread specifications. GD&T. None of the current tools handle these, and these are exactly the things that separate "a 3D shape" from "a part someone can manufacture." The text-to-CAD for manufacturing post covers this gap in more detail, but the short version is: if you need manufacturing-ready output, you need a human in the loop. Period.

Tolerance handling is nonexistent. I have never seen a text-to-CAD tool output a model with proper tolerances. The dimensions are nominal at best, approximate at worst. For prototyping, this is fine. For anything going into production, you're adding tolerances manually anyway, so the time savings shrink.

The file format question#

This matters more than it sounds. What a text-to-CAD tool outputs determines whether the result is useful or just pretty.

STEP (ISO 10303) is the gold standard for B-Rep exchange. If a tool outputs STEP, you can open that file in SolidWorks, Fusion 360, Creo, NX, or almost anything else and get real geometry with faces and edges you can work with. Zoo.dev outputs STEP, which is one of the reasons I take it seriously.

STL is triangulated mesh data. It's fine for 3D printing. It's useless for engineering edits. You can't select a face, you can't measure a true diameter, and you can't add a fillet to a mesh edge without converting it back to B-Rep first, which is a lossy, painful process that usually produces garbage. Tools that only output STL are not really text-to-CAD. They're text-to-mesh with better marketing.

OpenSCAD's .scad format is interesting because it's already code. An LLM generating an OpenSCAD script is generating a parametric model by definition, one you can open, read, edit, and rebuild. The downside is that OpenSCAD's modeling approach (CSG, constructive solid geometry) has real limitations for complex organic shapes.

DXF is 2D. Useful for laser cutting and CNC routing, not for 3D parts.

glTF, OBJ, PLY, FBX are all mesh or visualization formats. They have their uses but they're not engineering formats.

The takeaway: ask what format the tool outputs before you get excited. If the answer is "STL only," temper your expectations accordingly.

Accuracy and dimensional reliability#

This is the part where I get a little uncomfortable making general statements, because accuracy varies wildly between tools, between prompts, and between the complexity of what you're asking for.

I've tested Zoo.dev with specific dimensional prompts like "a rectangular plate 120mm by 80mm by 6mm with four M5 clearance holes on a 100mm by 60mm bolt pattern, 10mm from each edge." Sometimes the dimensions come back within a millimeter of what I asked for. Sometimes they're off by five percent, which might not sound like much until you try to bolt it to something real.

The pattern I've noticed: the more specific and constrained your prompt, the better the accuracy. "A bracket" gives you whatever the AI's average bracket looks like. "A 90-degree bracket, 3mm thick aluminum, 40mm legs, with two 4.2mm holes on each leg spaced 20mm apart" gives you something much closer to what you need. This is why prompt engineering matters so much for text-to-CAD specifically.

But even with perfect prompts, I wouldn't trust the dimensional output for anything going to manufacturing without measuring it myself. Every STEP file I've gotten from any text-to-CAD tool, I import it, measure the critical features, and adjust. It's a starting point, not a finished part. That's not a dealbreaker for the technology. It's just the honest state of things.

Where this sits in a real workflow#

Text-to-CAD is not a replacement for CAD software. It's a starting tool. Think of it like a sketch on a napkin, except the napkin is three-dimensional and already close to the right dimensions.

My current workflow when I use it: generate a first draft with a text-to-CAD tool, import the STEP into Fusion 360, measure and fix dimensions, add features the AI missed (fillets, chamfers, holes, mounting features), apply proper constraints, and then treat it like any other part. On simple geometry, this saves me maybe five to fifteen minutes compared to starting from scratch. On complex geometry, it saves nothing because I end up rebuilding the whole thing anyway.

Where I see the real value long-term is in iteration speed. You describe a concept, get geometry instantly, modify the description, get a new version. That feedback loop is fast in a way that sketch-extrude-fillet-undo-try-again isn't. For exploration, for "what would this look like if," for quickly testing five different bracket configurations before committing to one, text-to-CAD is genuinely useful right now.

For production work, it's supplementary. For prototyping and exploration, it's starting to earn its place.

The B-Rep vs mesh distinction, one more time#

I keep coming back to this because the market keeps trying to blur it. Every week I see another "AI generates 3D models from text!" announcement that turns out to be mesh generation. Meshes are fine for games, animation, VFX, and concept visualization. They are not fine for engineering.

A mesh is a bag of triangles. A B-Rep solid is a mathematically defined shape with faces, edges, vertices, and topology. You can compute exact volumes, areas, center of mass. You can apply manufacturing operations. You can generate toolpaths. You can check interference with mating parts. You can export drawings with real dimensions. None of that works reliably with mesh data.

If someone tells you their tool does "text-to-CAD" and the output is OBJ or FBX, they're doing text-to-3D with aspirational naming. The distinction isn't pedantic. It's the difference between getting a model you can work with and getting a model you have to recreate.

Will this replace CAD users?#

No. Not soon. Possibly not ever, depending on how you define "replace."

Text-to-CAD will change what CAD work looks like. It will automate some of the repetitive geometry creation that takes time but not much thought. Standard brackets, simple enclosures, mounting plates, basic structural shapes. That stuff will get faster.

But the hard parts of CAD, the parts where engineering judgment, manufacturing knowledge, tolerance analysis, assembly relationships, and plain experience matter, those are not what text-to-CAD solves. I still don't trust any of these tools to generate a part I'd send to a machine shop without checking every feature myself. A machinist I work with puts it this way: "I don't care how the model was made. I care if the model is right." Fair enough.

The more interesting question is whether text-to-CAD makes CAD more accessible to people who don't currently use it. Industrial designers who think in shapes but don't want to learn sketch constraints. Hardware engineers who need a quick enclosure but not a SolidWorks license. Hobbyists and small-shop people who just need a bracket and don't have time to learn a feature tree. That's where the real impact might be, not in replacing experienced users but in expanding who can generate usable geometry at all.

My honest assessment#

Text-to-CAD is real, it's early, and it's being oversold by about 60%. The core technology works. B-Rep generation from text prompts is a solved problem in the academic sense and a partially solved problem in the commercial sense. Zoo.dev, CADAgent, and a few others produce genuinely useful output for simple parts. The major vendors are paying attention and adding AI features to their platforms, which tells you the direction even if the shipping timeline is optimistic.

What's missing is reliability, complexity handling, manufacturing awareness, and dimensional precision. These are exactly the things that separate a demo from a tool you'd actually bet a project on. They'll improve. The research is moving fast. The training data is growing. But right now, in April 2026, text-to-CAD is a productivity aid for simple geometry and a curiosity for everything else.

I use it. I don't rely on it. That's probably the right balance for the next year or two. If you want to start experimenting, Zoo.dev's free tier is the best place to begin. Learn to write good prompts. Understand the output formats. Set your expectations at "useful starting point" rather than "finished part" and you'll be in the right neighborhood.

The tools will get better. The question for working engineers isn't whether to adopt text-to-CAD. It's when the output quality crosses the line from "interesting experiment" to "saves me real time on real work." For simple parts, that line is already here. For everything else, I'm watching, testing, and keeping my Fusion 360 shortcuts warm.