Text-to-CAD and the Bearing Pocket Problem

We clamped a block of 6061-T6 aluminum into a Kurt vise on a Haas VF-2 last Tuesday to test a simple prompt across three text-to-CAD platforms. The prompt was straightforward: "Flanged bearing housing for a standard 608 ball bearing, 22mm outer diameter, 7mm width, with a four-hole bolt circle on a 36mm diameter for M4 socket head cap screws, including a 1mm lead-in chamfer and a 0.5mm internal retaining ring groove."

Any second-year mechanical apprentice can draft this in SolidWorks in under four minutes. A CNC programmer will turn it around with standard roughing and boring operations in five. Yet across the current batch of text-to-3D and text-to-CAD tools, this basic component remains an immediate failure point.

Most tools generated geometry that looked convincing in a browser viewport. One gave us a solid cylinder with a polygonal central hole. Another generated a closed surface mesh with floating internal vertices that caused Mastercam to throw topology errors on import. Only the platforms that translate natural language directly into deterministic parametric code produced a model with true cylindrical faces that could actually be machined.

Understanding why this happens explains the current divide in engineering AI. On one side are generative diffusion and neural implicit representation models that treat geometry as visual volume. On the other are code-first engines that use text to drive solid modeling kernels.

The Anatomy of the Bearing Pocket Problem

To understand why natural language struggles with basic machine components, consider what a bearing pocket actually requires. It is not just a hole in a block.

+-------------------------------------------------------------+
|                   Nominal: 22.000 mm                        |
|                   H7 Fit:  +0.021 mm / +0.000 mm            |
|                   k6 Fit:  +0.009 mm / +0.001 mm            |
+-------------------------------------------------------------+
                                 |
                                 v
      [ Generative Mesh / SDF ]      [ Parametric Script / B-Rep ]
      - Faceted polygon rings        - True analytical cylinder
      - Deviation: +/-0.150 mm       - Radius: r = 11.000 + offset
      - Unmachinable directly        - Downstream CAM recognizes bore

When an engineer specifies an interference fit or a light press fit for a 608 bearing, the required bore is not 22.0 mm. For an ISO H7 tolerance, the allowable dimension sits between 22.000 mm and 22.021 mm. For a k6 shaft or transition pocket, you are managing single-digit micrometers.

Beyond the nominal dimension, the bore requires:

1. True circularity and cylindricity so the bearing outer race does not distort under load.
2. A perpendicular bottom shoulder face to locate the bearing axially without cocking the race.
3. A lead-in chamfer (typically 15 to 30 degrees) to prevent broaching the aluminum during insertion.
4. Clearance relief at the internal corner so the bearing radius clears cleanly.
5. Concentricity between the bore and the mounting bolt circle within 0.05 mm.

When you hand these requirements to a generative model trained on 3D meshes (such as synthetic ShapeNet datasets or scraped OBJ repositories), the model generates spatial density fields. It does not know what a cylinder is. It approximates a round shape using thousands of small triangular facets.

If you export that output as an STL or convert the mesh into a boundary representation (B-Rep) STEP file, the cylindrical bore becomes an assembly of flat planar faces. Drop that STEP file into your CAM package, and the software cannot identify a hole feature. You cannot select a center axis for a helical interpolation toolpath or a boring bar cycle. The toolpath generator attempts to surface-mill hundreds of tiny triangular flats. On the machine, the pocket comes out out-of-round, oversized in some axes, and undersized in others.

Testing the Contenders: Zoo, Leo, and Web Generators

Over the past three weeks, we evaluated several tools attempting to solve natural language mechanical design: Zoo (formerly KittyCAD), Leo AI, and a handful of browser-based tools like AdamCAD, SimuTecra, and CADScribe.

Direct Mesh and Neural Surface Generators

Tools that lean on neural volume representations or visual 3D generation can produce impressive conceptual shapes. Prompt them for a robotic gripper finger with organic topology or an ergonomic joystick grip, and they return a visually appealing shape in thirty seconds.

When tasked with mechanical interfaces, they break down immediately:

• Bolt circles drift. A prompt requesting four M4 holes on a 36mm bolt circle often yields holes with centers at irregular radii (e.g., 17.8mm, 18.3mm, 18.0mm, 17.6mm from center). The bolt holes will not align with a mating plate.
• Wall thicknesses vary uncontrollably. Thin walls between the bearing pocket and the outer flange perimeter often neck down to unmachinable knife-edges.
• Thread features do not exist. Hole features are rendered as unthreaded blind or through cavities with irregular depths.

These tools produce visual assets, not engineering models. Exporting them to STEP requires automated reverse-engineering algorithms that attempt to fit planes and cylinders to noisy meshes, adding another layer of dimensional error.

Leo AI and Mechanical Copilots

Leo AI approaches the problem from a different angle, operating as an engineering copilot focused on design constraints, assembly architecture, and capturing design intent. Instead of just dumping raw geometry, it attempts to reason through the requirements of the mechanical assembly.

When you describe a mechanical assembly to Leo, it helps map out the functional parameters, component spacing, and tribal knowledge rules (such as minimum edge distances for fastener clearance). It functions more like a senior designer reviewing your specification than an automated lathe operator.

Where copilots like this hit current boundaries is in the final geometric synthesis. Translating those reasoned constraints into exact, fully constrained sketches inside an enterprise CAD tree still requires substantial human intervention or deep scripting integration with CAD APIs.

Zoo and the Parametric Code Path

Zoo takes the code-first approach. Rather than predicting 3D voxels or surface points, their text-to-CAD pipeline converts natural language into KCL (KittyCAD Language), a dedicated parametric programming language for mechanical hardware.

When we gave Zoo our bearing housing prompt, the output was not a raw mesh. It was a readable, editable KCL script:

// Bearing Housing for 608 Bearing
const bearingOD = 22.0
const bearingWidth = 7.0
const flangeOD = 48.0
const flangeThickness = 4.0
const totalHeight = 12.0
const boltCircleDia = 36.0
const boltHoleDia = 4.5 // Clearance for M4

// Base Flange Sketch
const partSketch = startSketchOn('XY')
  |> circle([0, 0], flangeOD / 2, %)
  |> extrude(totalHeight, %)

// Main Bearing Pocket Extrusion Cut
const pocket = startSketchOn(partSketch, 'top')
  |> circle([0, 0], bearingOD / 2, %)
  |> extrude(-bearingWidth, %)

// Patterned Mounting Holes
const holePattern = startSketchOn(partSketch, 'top')
  |> patternCircular({
       arcDegrees: 360,
       center: [0, 0],
       instances: 4,
       radius: boltCircleDia / 2
     }, %)

This distinction is critical. Because the output is structured code running against an analytical geometry engine, the resulting shape contains true geometric primitives. The cylinder is a mathematical cylinder, defined by an axis vector and a radius scalar. When exported to STEP, the circular faces are exact analytical surfaces.

If the bore needs to be adjusted by -0.015 mm for a press fit, you do not need to re-prompt a neural network and hope it retains the rest of the geometry. You change const bearingOD = 22.0 to const bearingOD = 21.985 directly in the script. The downstream geometry updates deterministically.

Comparing the Workflows

To see how these approaches compare during a physical build cycle, we timed the process from prompt input to finished CNC machining on our mill.

Direct mesh generators fail on the shop floor because they skip the semantic construction tree. When an engineer builds a part in SolidWorks, Onshape, or Inventor, they build a directed acyclic graph of sketches, extrusions, cuts, and fillets. Each node preserves design intent.

When a tool skips that graph to output raw surface points, it throws away every piece of information that CAM software, coordinate measuring machines (CMMs), and downstream assembly models rely on.

The Machining Constraints Text Models Keep Missing

Even code-generating models still struggle with manufacturing common sense unless explicitly instructed. We ran a series of prompt variations on small brackets, motor mounts, and gearbox plates. Several consistent failure modes appeared across every platform.

1. Internal Corner Radii and Tool Clearance

Ask an AI to generate an internal pocket 25mm deep with a square profile, and it will give you perfectly sharp 90-degree internal vertical corners.

On a 3D printer, a sharp internal corner is printable (though it creates a severe stress concentration). On a three-axis milling machine, you cannot machine a sharp internal vertical corner with a rotating round endmill. You must have a corner radius equal to or greater than the cutting tool radius. If you need a square mating part to sit flush, you must add corner relief (dogbones or undercuts).

None of the text-to-CAD tools we tested added corner radii or tool relief unless we explicitly typed: "Add 3.5mm radius fillets to all internal vertical pocket corners for 1/4-inch endmill clearance." The models lack the embedded manufacturing context that an experienced machinist applies automatically.

2. Standard Fastener Clearance and Counterbores

When you ask for an "M4 clearance hole," human designers reach for standard tables: a close fit hole is 4.3mm, a standard fit is 4.5mm, and a loose fit is 4.8mm. Counterbore depths must account for the standard height of a DIN 912 socket head cap screw head (4.0mm for an M4 screw) plus washer thickness.

Generative prompts frequently returned 4.0mm nominal holes for M4 fasteners. If you machine a 4.0mm hole in steel or aluminum, an M4 screw will not drop through without binding. The model understands the semantic label "M4" as a single scalar diameter rather than a clearance standard.

AI-Generated Hole (Nominal 4.0 mm):    Fastener binds immediately
[ Aluminum Wall ] | 4.0 mm | [ Aluminum Wall ]
                  | ====== | <- M4 Fastener (3.95-4.0 mm OD)

Standard Clearance (4.5 mm H13):      Fastener clears freely
[ Aluminum Wall ] |  4.5 mm  | [ Aluminum Wall ]
                  |  ======  |

3. Wall Thickness and Tool Deflection

In light weighting exercises, text-driven models love to generate thin vertical ribs. We observed several bracket designs where structural ribs were generated with 0.6mm or 0.8mm wall thicknesses extending 35mm high.

On a CNC mill, machining a 0.8mm thick wall that is 35mm tall is an invitation to severe chatter and tool deflection. The wall will scream, vibrate, and push away from the cutter, leaving a tapered, out-of-spec surface. A human designer knows that unless the part is an investment casting or an additive build, aluminum structural walls should rarely drop below 2.5mm to 3.0mm without specialized tooling setups.

Why Parametric Code Is the Only Practical Interlingua

These experiments make one conclusion hard to avoid. Natural language will never be precise enough on its own to drive production manufacturing. Language is inherently fuzzy. Manufacturing tolerances are brutally binary.

If you tell an AI, "Make the pocket tight enough that the bearing does not slip, but loose enough that I can press it in with an arbor press," that sentence cannot be mapped directly to a numeric value without knowing the thermal environment, the housing material, the bearing grade, and the surface finish.

Natural language is useful for initialization, not execution. It is fantastic for standing up the first 70% of a parametric model: setting up the basic shapes, applying the rough dimensions, and creating the parameter names.

Once that script exists, the engineer must interact directly with the code or the parametric tree. That is why code-first platforms like Zoo's KCL, OpenSCAD-based generators, and platforms like Mexaio AI that bridge natural language with strict kinematic and parametric constraint solvers represent the real future of design automation.

When text generates code, the pipeline looks like this:

1. Natural Language Translation: An LLM converts a functional description into structured parametric code containing named variables, standard mathematical primitives, and geometric constraints.
2. Constraint and Geometry Compilation: A solid modeling kernel executes the code, evaluating constraints, solving sketches, and constructing exact B-Rep boundary surfaces.
3. Deterministic Human Review: The engineer inspects the parameter table. If the shop floor needs 0.02mm extra clearance for powder coating, they change a single numeric variable.
4. Downstream CAM/CMM Integration: The kernel exports an analytical STEP file where faces, axes, and holes are preserved as native engineering entities.

[ Natural Language Prompt ]
           |
           v
[ LLM Code Generation ] --------> Generates Parametric Script (KCL / Python)
           |
           v
[ Solid Modeling Kernel ] ------> Evaluates Geometry & Solves Constraints
           |
           v
[ Deterministic Inspection ] ---> Engineer adjusts exact tolerance variables
           |
           v
[ Native STEP File Output ] ----> Machine-ready analytical primitives

This architecture keeps the speed of natural language drafting while keeping the rigor of conventional CAD.

Practical Recommendations for the Shop Floor

If you run a machine shop, robotics lab, or prototyping department and want to integrate text-to-CAD tools into your actual workflow today, here is how to avoid wasting stock and cutter time:

• Do not send mesh-derived STEP files to CAM. If a tool generates an OBJ or STL and then converts it to STEP via surface-fitting, do not use it for machined parts with tight mating fits. The cylindrical and planar surfaces will have spatial noise that ruins your toolpaths.
• Use text-to-CAD strictly for initial script generation. Treat generative tools as code-starters. Have the model write the KCL, OpenSCAD, or Python CAD script, then pull that code into your local editor to verify hole sizes, add standard chamfers, and dial in tolerances.
• Specify standards explicitly in your prompts. Never prompt for "holes for bolts." Prompt for "clearance holes for M5 socket head cap screws with 5.5mm diameter through holes and 10mm diameter counterbores 5.4mm deep."
• Check internal pocket corners before posting code. Always inspect generative models for razor-sharp internal vertical corners. Add your tool radius offsets manually in the generated code before generating toolpaths.
• Keep your tolerance parameters at the top of the file. When using code-generating tools, insist that the model declare all fit-critical dimensions as top-level variables. That way, when your bore gauge tells you the first article is 0.015mm tight, you update a single line of code and re-post.

Natural language CAD is finally moving out of the demo phase, but its value is not in creating magical one-click finished parts. Its value is in eliminating the repetitive sketch-and-extrude setup work, leaving mechanical designers free to focus on what actually matters: fits, clearances, stress paths, and making sure the part can be built cleanly on the shop floor.

Sources

• Zoo.dev Text-to-CAD Machine Learning Generator
• Leo AI Mechanical Design Assistant and Comparison Guides
• Xometry: Testing Text-to-CAD Platforms for Practical Engineering
• SimuTecra AI CAD Generation Workflows