mexaio · 2026-09-12 · 11 min

Text-to-CAD on the Shop Floor: Real B-Rep or Expensive Cleanup?

Can text-to-CAD tools like Zoo and Leo AI output production STEP files, or does rebuilding broken geometry kill your shop's machining ROI?

Comparison of a broken faceted 3D mesh model alongside a clean parametric CAD solid model ready for CNC machining.

You type a prompt into an input box: "Billet 6061-T6 motor mount for a NEMA 23 stepper, 12mm face plate, four M5 clearance holes on a 47.14mm bolt circle, 38.1mm pilot boss, slotted mounting ears for belt tensioning."

Four seconds later, a viewport spins up a clean, shiny 3D model. It looks like a bracket. The mounting ears are there. The pilot hole is centered.

Then you export the file, drag it into your CAM package, and click the central bore to drop a boring cycle on it. Your toolpath generator throws an error. The bore is not a cylindrical surface. It is a tessellated tube composed of 128 flat triangular faces.

You open the file in SolidWorks to fix it. There is no feature tree. There is no base sketch. There are no dimension constraints. The entire part is a dumb imported body with two open surface self-intersections and a non-standard hole pitch that measured 47.112mm instead of 47.14mm.

Fixing that model takes twenty minutes. Modeling the part from scratch on two planes using standard hole wizard callouts takes five minutes.

That is the reality check facing text-to-CAD on the machine shop floor today. While venture capital pours into natural language 3D generation, mechanical engineers, CNC programmers, and sheet metal fabricators are stuck asking a much more practical question: does any of this output cut chips, or are we just buying AI-generated scrap metal?

The Fundamental Divide: Polygons vs Boundary Representation

To understand why most AI 3D generators fail in a manufacturing environment, you have to look at the math underneath the file.

Most generative 3D tools born out of computer vision research generate meshes (STL, OBJ, or GLTF). Meshes represent geometry as an approximation. They stitch together collections of flat polygons (triangles and quads) to fake a curved surface. For a video game asset or an unconstrained 3D print of a miniature figurine, meshes work fine. A rendering engine only cares about light bouncing off normal vectors.

A machine tool does not care about rendering. A 3-axis VMC running an interpolated helical bore needs an exact mathematical definition of a circle: a center point, a radius, a vector, and a continuous cylindrical surface. That is Boundary Representation (B-Rep).

In a B-Rep model (the foundation of STEP, IGES, Parasolid, and ACIS formats), a cylinder is not a collection of flat facets. It is an exact analytic surface bounded by precise mathematical curves (NURBS or analytic primitives). When your CAM software encounters a B-Rep cylinder, it generates an exact arc move (G02/G03 G-code) or a canned drilling cycle. When it encounters an STL mesh, it either refuses to recognize the hole or generates thousands of tiny point-to-point linear moves (G01) that chatter your tool, destroy surface finish, and balloon your cycle times.

Converting a faceted mesh back into a clean B-Rep solid after the fact is notoriously unreliable. Automated mesh-to-BRep tools routinely create micro-surfaces, misaligned axes, and non-tangent junctions that choke downstream operations like draft angle analysis, mold core extraction, and chamfering.

If an AI tool cannot natively output a valid, manifold B-Rep solid, it has zero utility in a production machine shop.

Testing the Current Field: Code-First vs Feature Inference

Over the past year, the market has split into two distinctly different technical approaches to solve the text-to-CAD problem.

1. The Code-First Compilers (Zoo.dev and KCL)

Zoo (formerly KittyCAD) took an engineering-first path that bypasses neural mesh generation entirely. Instead of training a model to hallucinate geometry pixels or points, they built the KittyCAD Design Language (KCL), a deterministic, human-readable programming language for geometry. Their text-to-CAD engine uses large language models to write KCL code, which then compiles down directly to exact B-Rep geometry via their custom geometry engine.

Because the LLM writes code rather than drawing shapes, the output produces real parametric geometry. An extruded circle is an actual analytic cylinder. A sketch line has an explicit coordinate.

In practice, this approach yields actual STEP files you can open in SolidWorks, Inventor, or Rhino without geometry corruption. The catch is complexity. Writing code for a simple rectangular adapter plate with four holes is easy for an LLM. Asking it to generate a complex multi-body assembly with compound angled planes, lofted ducting, and dynamic clearances frequently results in compile errors, broken sketch references, or hallucinated syntax.

2. The Semantic Copilots (Leo AI and Katalyst)

Tools like Leo AI approach the workflow from the top down. Rather than trying to be an autonomous black box that spits out a finished part from a single prompt, they act as an engineering copilot inside existing design workflows.

Leo focuses on capturing mechanical intent, design requirements, and engineering standards before geometry creation begins. You feed it operating loads, spatial envelopes, and manufacturing constraints. It helps iterate system architecture, component selection, and structural layouts before pushing data into parametric CAD formats.

The strength here is avoiding the dumb mesh problem by keeping the human engineer in the loop. The limitation is that it does not magically eliminate CAD modeling labor. You still have to do the heavy lifting of constraining sketches and building robust parametric trees.

3. Open-Source Programmatic Pipelines (FutureCAD, FreeCAD Wrappers)

Academic efforts, such as the FutureCAD framework, and various open-source Python-to-FreeCAD wrappers attempt to bridge the gap by training models to output native FreeCAD Python scripts or OpenSCAD files.

When these scripts work, they produce fully editable feature trees. You open FreeCAD, see the exact extrusion operations, and can adjust an extrusion depth by double-clicking a value. However, open-source geometric kernels (like OpenCASCADE) are unforgiving. If an LLM miscalculates a coincident constraint by 0.001mm, the boolean cut operation fails, the script crashes, and you are left with an empty viewport.

Tool / Approach Geometry Type Direct STEP Output Feature Tree Usability Production Readiness Primary Failure Mode
Mesh Diffusion (Point-E, Shap-E) Polygonal Mesh (STL/OBJ) No (Faceted conversion only) None Zero (Unusable for CAM) Faceted cylindrical surfaces, unmachinable geometry
Zoo.dev (Text-to-KCL) Parametric B-Rep via Code Yes (Native STEP) Script-based (Editable via KCL) Moderate for basic plates & prisms Geometry engine compile errors on complex lofts
Leo AI Intent / Architecture Copilot Integrates with CAD suites High (Uses native CAD structures) High for concept planning, manual for final CAD Requires human modeling for complex features
LLM-to-Python (FreeCAD scripts) Parametric B-Rep Yes (Native STEP / FCStd) High (Native sketch tree) Low to Moderate Boolean kernel crashes on unconstrained sketches

The Tolerancing and Feature Tree Problem

Even when an AI tool outputs a mathematically valid STEP solid, it still runs headfirst into the reality of manufacturing tolerances and feature hierarchy.

Consider an everyday shop task: a housing pocket for a 608 ball bearing (22mm nominal outer diameter).

No experienced machinist models a bearing bore as an unconstrained 22.000mm hole. Depending on whether it is an interference press fit (for a stationary outer ring) or a slip fit (for thermal expansion), you might model that bore at 21.988mm (+0.000 / -0.013mm) or 22.012mm.

Text prompts fail miserably at this nuance. If you prompt an AI for "a bearing pocket for a 608 bearing with an H7 tolerance", the underlying system almost always places a 22.000mm nominal cylinder in the model. Standard STEP files (AP203/AP214) do not carry geometric dimensioning and tolerancing (GD&T) semantics natively unless exported under STEP AP242 with embedded PMI (Product and Manufacturing Information).

If the AI does not embed explicit PMI annotations or provide a fully parametric feature tree where the sketch diameter is linked to an editable variable, the machinist has to manually step in:

  1. Import the STEP file into CAD.
  2. Run a feature recognition tool (which frequently fails on complex intersections).
  3. Re-cut the bore feature to the correct mean tolerance offset.
  4. Re-export the model to CAM.

The moment an engineer has to rebuild geometry to adjust a tolerance offset for machining, the time savings of using a natural language prompt evaporate entirely.

Threads, Undercuts, and Standard Tooling

Another failure point on the shop floor is tool access and standard hole callouts.

A mechanical designer designing a bracket for CNC milling knows that you cannot mill a sharp 90-degree internal corner. An end mill is round. You must leave an internal fillet radius larger than the tool radius, or design an undercut/dogbone corner.

When an LLM generates a cavity from a generic text prompt, it routinely specifies sharp internal corners in deep pockets. When imported into CAM, the programmer must either manually add corner relief fillets or reject the part back to engineering.

Tapped holes present a similar issue. In standard CAD systems, the Hole Wizard does not model actual helical threads for production parts. It creates a standardized cylindrical hole sized for the tap drill (e.g., 4.2mm for an M5x0.8 thread) and attaches cosmetic thread metadata. This keeps file sizes small and CAM toolpath routines fast.

AI CAD generators often swing to terrible extremes. They either generate a plain 5.0mm hole (destroying the tap drill sizing) or attempt to physically model the 3D helical coil sweep. A physical 3D thread sweep balloons the STEP file from 200 KB to 45 MB, creates thousands of complex NURBS surfaces, and causes CAM toolpath generation to crawl.

At our lab working on Mexaio AI, we deal with these kinematic and fabrication constraints daily. Generative geometry without deterministic mechanical boundary enforcement is just digital clay. Real mechanical software must understand the relationship between tool access, stock sizing, and thread standards before it creates a single vertex.

The Shop Math: When Does AI CAD Actually Pay For Itself?

Let us look at the raw time and labor costs of implementing these tools in a typical prototyping or job shop environment.

Assume a shop billing rate of $100 per hour for design and programming time.

Scenario A: Simple 2.5D Fixture Plate

  • Description: Rectangular tooling plate with 6 locating pin holes, 4 strap clamp slots, and a grid of tapped M6 holes.
  • Manual CAD time: 8 minutes (Parametric sketch, pattern tool, hole wizard).
  • AI Text-to-CAD time: 30 seconds generation + 4 minutes verification and hole resizing in CAD.
  • Net savings: ~3.5 minutes ($5.83 saved).
  • Risk: Low. The geometry is simple enough that geometric errors are visually obvious.

Scenario B: 5-Axis Structural Linkage or Robot Arm Component

  • Description: An angled clevis mount with weight-reduction pockets, internal bearing journals, and tight datum references.
  • Manual CAD time: 45 minutes.
  • AI Text-to-CAD time: 2 minutes prompt and generation + 25 minutes fixing unconstrained sketch references, healing micro-surfaces, adding tool-clearance fillets, and adjusting press-fit dimensions.
  • Net savings: 18 minutes ($30.00 saved).
  • Risk: High. Undetected non-tangent faces or sub-millimeter sketch skew can cause a tool collision on a 5-axis machine or scrap a $400 piece of billet stock.

If the AI output requires more than a 30 percent rebuild in SolidWorks or Onshape, the economic benefit vanishes. It is always faster for a competent mechanical designer to build clean geometry from scratch than to untangle someone else's unconstrained sketch mess. That rule applies whether the bad geometry came from an intern or an AI model.

[ Text Prompt ]
       │
       ▼
[ Generative Model ]
       │
       ├── Output: Mesh (STL/OBJ) ──────► Reject (Unusable for Production CNC)
       │
       └── Output: B-Rep (STEP)
               │
               ├── Check 1: Manifold & Non-Intersecting Solid? ──► [Fail: 20 min Repair]
               │
               ├── Check 2: Standard Tool Clearance & Corners? ──► [Fail: 15 min Re-draw]
               │
               ├── Check 3: Exact Fits & Hole Pitch Tolerances? ──► [Fail: Re-cut Features]
               │
               └── All Passed ──► Directly into CAM / Toolpath Generation (True ROI)

Where Text-to-CAD Actually Works Right Now

Despite the clear limitations, text-to-CAD is not completely useless in a production environment. There are three specific areas where it is currently providing positive ROI on the shop floor.

1. 2D Sheet Metal and Gasket Profiling

Tools that translate simple natural language into clean 2D DXF profiles (like SimuTecra or basic KCL scripts) are surprisingly reliable. If you need a quick 5-bolt flange, a non-standard exhaust gasket, or an acrylic laser-cut panel outline, text-to-DXF pipelines work exceptionally well. The geometric space is constrained to flat 2D planes, eliminating the kernel failure points associated with 3D complex booleans and lofting.

2. Rough Volumetric Envelopes for Packaging

In robotics and mechanism design, packaging studies consume immense amounts of time. You often need dummy components to verify clearances: an off-the-shelf brushless motor, a specific planetary gearbox envelope, or a battery pack volume.

Generating these spatial keep-out zones using rapid text-to-CAD saves real time. Because these parts are non-machined reference geometry, exact tolerances, thread classes, and internal fillets do not matter. They only need accurate outer bounding dimensions.

3. Rapid 3D Printing Fixtures and Soft Jaws

For additive manufacturing (FDM/SLA) and quick-turn urethane molding, the geometric strictness of CNC machining is relaxed. If you need to generate a custom fixture cradle or soft vise jaw to hold an oddly shaped casting, prompting a tool to generate a rough negative impression produces usable results. Since 3D slicing software natively processes triangulated meshes, the mesh-to-BRep bottleneck is entirely bypassed.

What to Watch For Next

If you run a design team, machine shop, or fabrication outfit, do not waste money on generic AI tools that output meshes and claim to do CAD. They are rendering toys designed for video games and concept art.

Instead, test tools based on three objective technical criteria:

First, check the output file extension and underlying data. If it outputs an STL or OBJ file, close the tab. You want tools that output native STEP (AP214 or AP242), Parasolid (.x_t), or direct code files (Python/KCL).

Second, test for parametric editing. Open the exported file in your primary CAD system. Can you suppress a fillet? Can you change a hole diameter by double-clicking it? If the model imports as an uneditable dumb solid, factor in the cost of manual feature editing before calculating your workflow savings.

Third, run an automated geometry check. Run import diagnostics in SolidWorks, Inventor, or Rhino. Check for faulty faces, zero-thickness geometry, and edge gaps. If an engine consistently produces self-intersecting surfaces, it will cost you more in broken CAM toolpaths and scrapped material than any time saved at the prompt box.

Text-to-CAD is moving rapidly from an academic curiosity into functional engineering software. But until the underlying systems respect the rigid realities of B-Rep geometry, tool access, and standard mechanical tolerances, keep your calipers handy and your CAD licenses active.

Sources

CADMachiningGenerative AIManufacturingRobotics