Most text-to-CAD demos can't make a part you'd send to a machine shop.

2026 is the year text-to-CAD became a product category. Type "a steel bracket, 150 by 80, four M8 bolt holes" and a model appears in seconds. The demos are genuinely impressive. The tool roundups are everywhere. And the reviewers have finally started saying the quiet part out loud.

Leo AI's assessment of the category it competes in: "the gap between what the demos show and what actually survives a design review is enormous." That's a vendor saying it about their own market.

We build a text-to-CAD tool. This post is partly about the category and partly about us, because the criticism lands on everyone — including Text2CAD.

The landscape splits into two camps

RapidDirect tested eight AI CAD tools this year, and the results sort cleanly:

Mesh generators (Meshy, Hunyuan 3D) produce textured 3D meshes fast. They're good at what they're for — e-commerce visuals, game assets, marketing renders. But in the reviewers' words, the geometry "lacks the mathematical precision needed for CNC tooling paths" and "the physical dimension tracking required for factory production." A mesh has no dimensions, only the appearance of them.

Parametric generators (Zoo, AdamCAD) output actual CAD — B-Rep solids with STEP export, or constructive code. Dimensions are real and editable. The tradeoff: they handle simple single parts well and start struggling with complex assemblies and organic surfaces. Brackets and fasteners, yes. A gearbox, no.

The pattern across every roundup: the closer a tool's output is to editable engineering intent, the narrower the range of parts it can make. The more spectacular the demo, the less manufacturable the file.

"They learn what parts look like, not how parts work"

That line — also Leo AI's — is the sharpest description of the core failure. Most text-to-CAD systems are trained the way image generators are trained: on what finished parts look like. So the output looks right and is wrong in the ways that matter:

• No feature tree. You can't open it in SolidWorks and modify the hole pattern — there's no hole "feature," just frozen geometry where holes happen to be.
• No tolerance data. A bore that needs to be ⌀8 H7 comes out as ⌀8-ish.
• No material or process awareness. Wall sections too thin to mold, overhangs that need support the model doesn't know about, undercuts no 3-axis mill can reach.

A bracket with wall sections too thin for injection molding is not a bracket. It is a rendering.

Nobody sends a rendering to a machine shop.

---

Why we generate code instead of geometry

Text2CAD takes a different bet, and the 2026 reviews are why we think it's the right one. When you describe a part, Claude doesn't generate a mesh — it writes OpenSCAD code, which a 20-year-old open-source compiler turns into geometry deterministically.

Code-first buys three things the mesh camp can't offer:

• Every dimension is a named number. The bolt spacing isn't an emergent property of a mesh — it's hole_spacing = 31, sitting in an editor, waiting to be changed.
• The output is reviewable. An engineer can read 40 lines of OpenSCAD and verify intent in under a minute. Nobody can review a million-triangle mesh.
• The compile step is honest. OpenSCAD doesn't hallucinate. If the code is wrong, the part is visibly wrong in the preview — which is exactly what the Improve loop critiques and fixes.

Where Text2CAD falls short too

No pretense — here's our side of the ledger, same standard applied:

• Single parts only. Like Zoo and AdamCAD, we live in bracket-and-flange territory. No assemblies, no mates, no interference checks between parts.
• Printable is not machinable. We give you a clean STL for your printer (STEP export is on the bench). But STL is still frozen geometry once it leaves the code — and we don't generate tolerance callouts, surface finishes, or drawings. What goes to a machine shop is a drawing, and we don't make one.
• No process intelligence yet. Claude knows a surprising amount about design-for-printing from its training, but Text2CAD doesn't enforce minimum wall thicknesses or flag unprintable overhangs. The Improve loop catches some of this visually. Some is not all.
• An engineer is load-bearing. Our own product page says reviewable "by a human engineer in under a minute" — that review is part of the system, not optional polish. That's also why it's a private beta and not a self-serve product.

Five questions to ask any text-to-CAD tool

If you're evaluating anything in this category in 2026 — us included — the demo will not tell you what you need to know. These will:

1. Can I edit the output parametrically, or is it frozen geometry? (Mesh = frozen. Code or B-Rep = editable.)
2. Are the dimensions real? Ask for a 31mm hole spacing, then measure the file.
3. Is generation deterministic? Same prompt, same part — or a slot machine?
4. Does the vendor show failures? A gallery of only successes is a brochure. (Ours shows what came out, including the rough ones.)
5. What does a part cost? If the vendor can't tell you per-generation economics, they haven't done the math that survives this billing era. Ours: about 1¢ per simple prompt, up to ~10¢ per Improve cycle.

Where this actually goes

The skeptics' critique is correct and also temporary in parts. Feature trees, tolerance schemas, and design-for-manufacturing rules are all representable — they're code and constraints, exactly the things language models are getting rapidly better at writing. The mesh camp has a ceiling. The code-and-constraints camp has a roadmap.

But the order matters: honesty about what the tools can't do is what earns the right to be believed about what they can. The category's worst enemy isn't the skeptics — it's the demos.

We'd rather show you the OpenSCAD.

---