Text-to-CAD on the Shop Floor: Meshes Break, Code-First B-Rep Holds Up

Drop an AI-generated 3D file into Mastercam or SolidWorks on a Monday morning, and you immediately find out what the software developers actually value. If the tool spits out an STL or an OBJ wrapped inside an empty STEP container, your CAM software will choke. The canned drilling cycles will not recognize hole centers. The toolpaths will treat every curved surface as hundreds of tiny flat facets. Your machine will stutter through thousands of point-to-point G01 moves instead of smooth G02 and G03 arc interpolations, leaving facet marks all over what was supposed to be a turned bore.

Over the past eighteen months, text-to-3D demos have flooded social feeds. Most of them generate rough organic shapes using signed distance fields (SDFs), neural radiance fields (NeRFs), or diffusion-based point clouds. Those are fine for video game assets, concept art, and rough 3D printing on a hobbyist FDM machine. They are utterly useless for a machine shop, a sheet metal fabricator, or an injection molder.

Production manufacturing does not run on polygons. It runs on Boundary Representation (B-Rep) solids defined by exact mathematical geometry, topological trim curves, and parametric feature histories. A new crop of generative engineering tools, including Zoo.dev with its text-to-CAD engine and Leo AI's engineering copilot, are tackling this problem from a fundamentally different angle. Instead of hallucinating pixels or voxels in 3D space, they are treating mechanical design as a deterministic code-generation problem.

Here is what happens when you put these tools against real shop-floor constraints, where they work, and why the line between code-first CAD and mesh generation determines whether an AI part can actually be manufactured.

The Mesh Fallacy: Why Polygons Die on the Mill

To understand why generative 3D tools fail in production, look at how a CNC mill interprets geometry. When you program a standard 3-axis VMC to mill a 50mm H7 locating bore in a 6061-T6 aluminum plate, your CAM software looks for a true analytic cylinder (CYLINDRICAL_SURFACE in standard STEP AP203/AP214/AP242 definitions).

When CAM finds an analytic cylinder, it does several specific things automatically:

1. It identifies the exact centerline axis of the cylinder.
2. It selects a canned drilling cycle (like a G81 for spot drilling, a G83 for peck drilling, and a boring head or circular interpolation pass for finishing).
3. It extracts the exact nominal diameter (50.000mm) and lets the programmer attach a tolerance band (+0.030/-0.000mm) to drive tool wear compensation.

When you import a polygonal mesh, that cylinder does not exist. It is replaced by a collection of 64, 128, or 256 planar triangular facets. The CAM system sees dozens of tiny flat walls meeting at sharp edges.

[Analytic B-Rep Cylinder]       [Tessellated Mesh Cylinder]
      .---.                            /\- -/\
    /       \                         /  \ /  \
   |    +    |  <-- True Axis        |   + |   |  <-- No true center
    \       /                         \  / \  /
      '---'                            \/- -\/
  (G02/G03 smooth arcs)          (Dozens of G01 line segments)
  (Standard canned cycles)       (Surface milling toolpaths only)

If you try to run a toolpath on that mesh without manually rebuilding the geometry from scratch, the machine attempts to mill each flat facet. The file size balloons from a 40 KB STEP file to a 50 MB G-code program. If your controller is older, the lookahead buffer starves, the feed rate drops, and the end mill chatters against the stock, ruining the surface finish and eating carbide.

Meshes also fail on basic topology checks. AI mesh generators routinely produce non-manifold geometry: self-intersecting faces, zero-thickness walls, inverted surface normals, and unstitched edges. In a rendering engine like Blender or Unreal, an inverted normal just needs a shader tweak. In an injection molding simulation or a 5-axis collision check, a non-manifold edge halts the calculation immediately.

What Code-First B-Rep Engines Are Doing Differently

Zoo.dev and similar code-first platforms approach the problem from the opposite direction. Instead of asking a neural network to predict the 3D surface coordinates of an object directly, they train language models to write CAD code in dedicated domain-specific languages.

Zoo.dev uses KCL (KittyCAD Language), an open-source, text-based programming language built specifically for mechanical geometry. When you give Zoo a prompt like "a 100mm mounting flange with four 6.5mm clearance holes on a 75mm bolt circle," the AI does not draw an object. It writes a deterministic KCL script.

That KCL script looks something like this:

// Define base flange dimensions
const outerDiameter = 100.0
const flangeThickness = 12.0
const boltCircleDiameter = 75.0
const holeDiameter = 6.5

// Sketch base cylinder
const flangeSketch = startSketchOn('XY')
  |> circle([0, 0], outerDiameter / 2)
  |> extrude(flangeThickness)

// Create bolt circle pattern
const holePattern = startSketchOn(flangeSketch, 'START')
  |> circle([0, boltCircleDiameter / 2], holeDiameter / 2)
  |> patternCircular2d(4, 360, [0, 0])
  |> cut(flangeThickness)

The script is executed by an underlying geometry engine written in Rust. The engine evaluates the mathematical sketch curves, extrudes the profile, executes the boolean subtraction for the holes, and builds a genuine B-Rep solid with valid topology. When you export that model to STEP format, the holes are actual analytic cylinders, the top and bottom are planar faces, and the edges are clean mathematical intersections.

This architecture solves the two biggest problems with early generative CAD:

First, the output is editable. If the generated flange is 12mm thick but your stock plate is 0.500 inches (12.7mm), you do not have to sculpt a mesh or perform messy direct-editing push-pull operations on dumb solids. You open the code, change flangeThickness = 12.0 to 12.7, and recompile. The downstream features update without breaking the model.

Second, the output is verifiable. A geometry engine either compiles the code or it throws a syntax or topological error. If an extrusion self-intersects or a boolean cut misses the body entirely, the system knows immediately during generation. In Zoo's Zookeeper engine, the agent inspects and debugs the geometry in a closed loop before presenting the final STEP file to the user.

Leo AI takes a complementary copilot approach, focusing on translating higher-level engineering requirements, design rules, and tribal design knowledge into parametric CAD features and assemblies inside established engineering workflows. By grounding the generative process in parametric CAD relationships rather than freeform spatial estimation, these platforms avoid the structural nonsense that plagued early text-to-3D experiments.

The Benchmark: Prompting an Actual Locating Bracket

To test how these systems hold up under real machining constraints, we tested a common shop fixture requirement across multiple text-to-CAD workflows:

Prompt: "L-bracket, 120mm long, 60mm wide, 15mm wall thickness, 6061 aluminum. The horizontal leg has two counterbored holes for M8 socket head cap screws spaced 40mm apart on center. The vertical leg has a 25mm diameter locating bore with an internal 2mm retaining ring groove."

Here is how different approaches handle this prompt on the shop floor:

The standard text-to-3D tools fail immediately at the retaining ring groove. A standard retaining ring groove (for an external or internal circlip like a DIN 472 or ANSI standard) requires sharp 90-degree internal corners, a tightly controlled groove width (for example, 1.30mm +0.14/-0.00mm for a 25mm bore), and a precise groove depth. A diffusion model smooths those corners into a soft trough. If you tried to seat a snap ring in that groove, it would pop out under the slightest axial load.

The code-first engine, however, treats the groove as a secondary sketch revolved around the bore axis or an offset boolean sweep. Because it compiles to standard CAD primitives, the groove walls are flat, perpendicular surfaces, and the internal diameter is an exact mathematical value that a shop can turn on a lathe using a standard internal grooving tool.

At Mexaio AI, our work on kinematic assemblies and generative mechanical design reinforces this exact principle every day: mechanical engineering is fundamentally a discipline of constraints, not artistic approximations. When an algorithm designs a mechanism, it must calculate load paths, pin clearances, and backlash limits in mathematical coordinates before a single line of G-code is posted.

The Elephant in the Inspection Room: Tolerances and PMI

Even when text-to-CAD tools successfully output valid STEP geometry, there is still a massive missing link between a solid model and a manufactured part: Product and Manufacturing Information (PMI) and Geometric Dimensioning and Tolerancing (GD&T).

When a machinist looks at a 25mm bore in a 3D model, the model geometry only gives the nominal size (25.000mm). The CAD file alone does not tell the machinist:

• Is this bore a loose clearance hole for a fluid line (+0.20/-0.00mm)?
• Is it a press fit for a needle roller bearing (+0.000/-0.012mm)?
• Is it a slip fit for a dowel pin (H7: +0.021/-0.000mm)?
• What is the perpendicularity requirement relative to the base datum?
• What is the required surface finish (Ra 0.8 vs Ra 3.2)?

  [ AI Prompt ]  -->  "L-bracket with 25mm bore"
                            |
                            v
  [ Current State ] --> Nominal STEP Model (25.000mm)
                            |
                            v  <-- THE SHOP FLOOR GAP
  [ Missing Data ]  --> 1. Tolerance Class (e.g. H7: +0.021 / -0.000)
                        2. Datum References (Datum A, B, C)
                        3. Surface Roughness (Ra 0.8 micrometers)
                        4. Geometric Controls (Perpendicularity to [A] within 0.02)

Right now, no AI tool on the market generates fully articulated GD&T schemes directly from natural language prompts without heavy human intervention. When an engineer prompts a tool for "a precision bearing housing," the model creates the nominal geometry, but the engineer still has to pull that model into a tool like SolidWorks, Inventor, or Onshape, create a 2D drawing or 3D PMI annotations, and manually apply the datums, runout tolerances, and fit classes.

This is why claims that text-to-CAD will immediately replace mechanical design engineers miss the mark. Drafting the basic 3D shape is often the fastest part of the job. The tedious, critical engineering work is calculating thermal expansion, defining tolerance stack-ups across five mating parts, choosing the right chamfers for automated assembly, and ensuring the part can be held in a standard 6-inch Kurt vise without custom soft jaws.

The Real Bottleneck: Feature Trees vs Direct Modeling

Another structural issue mechanical designers face with AI-generated CAD is the difference between a dumb solid and a feature tree.

If you use a tool that generates a pure STEP file without exposing the underlying code or sketch relations, you get a "dumb solid." If you need to change a hole from an M6 clearance hole to an M8 tapped hole, your CAD software does not have an "Extrusion 4" or a "Hole Wizard Feature" to edit. You have to use direct modeling tools to delete the face, heal the surrounding surface, create a new sketch on the face, project the center, and cut a new hole.

This is where the divergence between code-first CAD (Zoo.dev / KCL) and legacy CAD plugins becomes critical:

1. Parametric Regeneration: In a code-first system, the geometry is regenerated from source text. If you want to change the bolt spacing on a bracket from 40mm to 55mm, you change one variable in the script. The downstream fillets, chamfers, and counterbores follow the change because they reference the variable, not a static spatial coordinate.

2. Version Control for Physical Parts: A script like KCL can live in a standard Git repository. You can run diffs, track pull requests, and review parametric modifications line by line. Tracking changes in binary CAD files (.sldprt, .ipt, .par) has always been notoriously difficult. Code-first CAD brings mechanical version control into the same workflow software developers have used for decades.

3. Automated Design Verification: When the CAD model is code, you can write automated integration tests for physical hardware. You can write a continuous integration (CI) script that checks if a wall thickness ever drops below 3mm, or verifies that the distance between a hole edge and the part boundary satisfies a 1.5x diameter edge-margin rule. If an engineer or an AI prompt breaks a design rule, the build fails before anyone orders aluminum bar stock.

Practical Rules for Using AI CAD in Your Shop Today

If you run a design team, a machine shop, or a robotics startup and want to evaluate text-to-CAD tools without wasting time on dead ends, apply these practical screening rules before adding any AI tool to your production pipeline:

1. Reject pure mesh generators for subtractive manufacturing

If a tool outputs STL, OBJ, PLY, or standard GLTF and does not have an underlying B-Rep engine, do not use it for CNC machining, sheet metal, or injection molding. Use it for styling concepts, industrial design aesthetics, or rapid visual mockups only.

2. Inspect the STEP file entity headers

When an AI tool gives you a STEP file, open it in a basic text editor before loading it into your CAD software. Look at the declared entities. If you see thousands of CARTESIAN_POINT and FACETED_BREP entries representing a dense mesh shell, the tool is faking CAD output. A genuine mechanical STEP file should contain CYLINDRICAL_SURFACE, PLANE, B_SPLINE_CURVE_WITH_KNOTS, and ADVANCED_FACE entities.

3. Check for sketch-level determinism

Test if the tool produces repeatable results for identical parametric inputs. If you prompt the model for a 50mm square block with a 20mm centered hole ten times, does it produce identical, clean sketch constraints every time, or does the hole shift slightly based on probabilistic token sampling? For manufacturing, geometric indeterminacy is a defect.

4. Verify CAM canned cycle recognition

Import the generated STEP file into your CAM package (Fusion 360, Mastercam, SolidCAM, or GibbsCAM). Run an automatic hole-recognition feature. If the CAM system cannot instantly detect the hole diameter, depth, and axis, the file fails the production readiness test.

5. Look for open, human-readable code backends

Prioritize tools that expose the underlying parametric code, whether that is KCL, Python (via CadQuery/OpenSCAD), or native CAD API scripts. If the AI makes a mistake on a complex part, fixing three lines of code is infinitely faster than fighting an AI chat prompt back and forth trying to get it to nudge a boss 2mm to the left.

Text-to-CAD is crossing the threshold from tech demo to shop utility, but only because developers have realized that engineering geometry cannot be treated like digital art. The future of AI in mechanical design is not about guessing pixels in space. It is about generating precise, constraint-driven, executable code that compiles into real mathematical solids your machines can actually cut.

Sources

• https://zoo.dev/zookeeper
• https://www.getleo.ai/blog/open-source-text-to-cad-tools-free
• https://simutecra.com/blogs/text-to-cad-ai-product-design
• https://mikekalil.com/blog/ai-driven-text-to-cad/
• https://www.youtube.com/watch?v=WdhZiE0-Pzs
• https://www.reddit.com/r/Futurology/comments/196wp8c/text_to_3d_cad_is_coming_whos_building_it/