Text-to-CAD for gears: don't hold your breath

A colleague showed me an AI-generated spur gear last week, spinning it in the viewport like he'd accomplished something. It had teeth. It had a bore. It looked, from three feet away and with one eye closed, like a gear. I asked him what module it was. He didn't know. I measured the tooth profile in Fusion 360. It wasn't an involute curve. It wasn't even close to an involute curve. It was a series of arcs stitched together with the confidence of someone who's seen a picture of gears but never used one. The thing couldn't have meshed with another gear any more than a saw blade could mesh with a comb.

That's the state of text-to-CAD for gears. The AI can produce objects that look like gears. It cannot produce gears.

Why gears are fundamentally different from brackets#

Most of the mechanical parts that text-to-CAD handles decently are what I'd call "shape-first" geometry. A bracket's function comes from its overall form: the leg length, thickness, hole placement. The exact contour of each surface is simple. Flat faces, cylindrical holes, maybe a fillet. The AI can approximate these shapes because there's a lot of room for the geometry to be slightly off and still work.

Gears aren't like that. A gear's function lives in the tooth profile, and that profile is defined by a mathematical curve called an involute. The involute shape is not optional. It's not aesthetic. It's the geometry that allows two gears to transmit motion at a constant velocity ratio with smooth rolling contact. If the tooth profile is wrong, the gears don't mesh properly. They bind, chatter, wear unevenly, or simply don't transfer torque.

The specific involute curve for a given gear depends on the module (or diametral pitch in imperial), the number of teeth, the pressure angle (usually 20 degrees), the addendum, the dedendum, the root fillet radius, and potentially a profile shift coefficient. These are all interrelated by formulas from gear standards like ISO 21771 or AGMA 2001. You can't just eyeball them.

Text-to-CAD tools don't know any of these formulas. They've seen gear shapes in training data, so they can generate something gear-shaped. But gear-shaped and gear-functional are completely different things.

What the AI actually generates#

I tested three prompts across two tools. Simple, specific requests.

First: "Spur gear, module 2, 20 teeth, 14mm bore, 20-degree pressure angle, 10mm face width." This is unambiguous by gear standards. It defines exactly one correct geometry.

Zoo.dev gave me something with 20 teeth. The outer diameter was close, about 43mm versus the correct 44mm. But the tooth profile was wrong. The flanks were straight lines connecting circular arc tips, like a sprocket for a chain, not a gear for meshing. The root form was a simple radius that didn't follow the standard trochoid. And the tooth thickness at the pitch circle, which I measured carefully, was 3.5mm instead of the correct 3.14mm. That's more than 10% off on a dimension that determines whether two gears will mesh without binding.

Second: "Helical gear, module 1.5, 30 teeth, 10mm bore, 20-degree pressure angle, 15-degree helix angle." This is harder, and I expected it to fail. It did. The output had 30 teeth, but they were straight, not helical. The AI ignored the helix angle entirely and gave me a spur gear with incorrect tooth proportions. The bore was 10mm, which was nice. Small victories.

Third: "Bevel gear, 15 teeth, module 3." This one came back as a cone with rectangular protrusions. I stared at it for a while. It looked like a medieval torture device more than a power transmission component. The AI clearly had no training data for bevel gears and improvised badly.

The involute problem#

An involute tooth profile is a precise mathematical curve generated by unwinding a string from a base circle. Every point on the curve has a specific radius that determines the contact mechanics. In real gear design software, the tooth profile is computed from first principles. The software doesn't approximate. It calculates.

Text-to-CAD tools don't calculate. They predict. They generate something that looks statistically probable based on training data. For a bracket, that's fine. For a gear, "roughly" is failure. A tooth profile 0.5mm off at the pitch point produces a gear set that binds, wears prematurely, and generates noise under load. The AI doesn't know what a base circle is, doesn't know the dedendum is 1.25 times the module, and doesn't know the root fillet has to clear the tip of the mating gear.

What you should use instead#

For parametric gears in Fusion 360, add-ins like GF Gear Generator produce accurate involute geometry from standard parameters in about thirty seconds. SolidWorks has a Toolbox with standard gear geometry. For serious gear work, dedicated tools like KISSsoft handle strength calculations, contact analysis, and profile modifications.

The "but I just need a visual" argument#

Some people tell me they don't need an accurate gear. They just need something that looks like a gear for a rendering, a concept assembly, or a presentation. Fine. For that use case, the AI output is acceptable. It has teeth. It's round. It exists in 3D. Put it in a rendering with motion blur and nobody will notice the tooth profile is wrong.

But I'd still argue you're better off using a gear generator even for visuals, because it takes thirty seconds, the result is correct, and you won't have to explain to an engineer six months later why the gear model in the assembly file has the wrong pitch circle when someone tries to use it as a reference.

I've seen "placeholder" geometry survive in project files for years, slowly migrating from "concept only" to "reference geometry" to "I thought this was the real model." Bad gears in a file are like bad wiring in a wall. Eventually someone will assume it's correct and base a decision on it.

Where AI and gears might eventually meet#

The gear problem is a specific case of a broader text-to-CAD limitation: the AI generates geometry by appearance, not by engineering rules. A path forward might involve coupling the AI with a parametric gear kernel, where the text prompt extracts parameters and feeds them to a proper gear calculator. That makes more sense than trying to train a neural network to rediscover the involute.

Until that exists, my advice is simple: don't use text-to-CAD for gears. Use a proper gear tool. The teeth won't mesh, the gears won't run, and the only thing you'll have generated is frustration. For simple mechanical parts like brackets and mounting plates, text-to-CAD is a reasonable starting point. For gears, springs, cams, or anything where the geometry is defined by math rather than by what it looks like, stick with dedicated tools.